Kerberoasting: turning a service ticket into a domain password

Kerberoasting is one of those attacks that feels like a bug and is actually a feature. Active Directory will hand any authenticated user a service ticket for any account that has a Service Principal Name registered. That ticket is encrypted with a key derived from the service account's password. Request it, pull it offline, crack it on your own hardware. No special rights, no touching the target service, no account lockout because the guessing happens entirely on your box.

That last part is what makes it dangerous. Online password spraying is loud and trips lockout policies. Kerberoasting moves the brute force off the domain entirely.

Where the crackable material comes from

When you ask a domain controller for a TGS for some SPN, part of the response is encrypted under the long-term key of the account that owns that SPN. For RC4 (etype 23), that key is just the NTLM hash of the password. So the structure you get back is effectively "encrypted blob you can verify by guessing the password." Guess the password, derive the key, the blob decrypts to something well-formed. That is the oracle.

The catch in practice is which accounts have SPNs. Computer accounts have them too, but their passwords are 120 random characters and rotate, so forget those. You want SPNs registered on regular user accounts. Those tend to be service accounts created by a human years ago, often with a password like Sql2017! that has never changed because rotating it might break something nobody documented.

Pulling the tickets

On a Linux attack box, Impacket is the usual path:

GetUserSPNs.py -request -dc-ip 10.0.0.10 contoso.local/lowprivuser:Password1 -outputfile tgs.txt

That enumerates accounts with SPNs and requests a ticket for each, writing them in hashcat format. From Windows, Rubeus does the same and is quieter about it:

Rubeus.exe kerberoast /outfile:tgs.txt

What lands in the file looks like this, and it is what we call a krb5tgs hash:

$krb5tgs$23$*svc_sql$CONTOSO.LOCAL$MSSQLSvc/sql01.contoso.local:1433*$a8f2...

The 23 is the encryption type. Remember it, because it decides everything about whether this is worth your time.

Cracking it

RC4 tickets go to hashcat mode 13100:

hashcat -m 13100 -a 0 tgs.txt rockyou.txt -r /usr/share/hashcat/rules/best64.rule

RC4 Kerberoast hashes are fast. On a single modern GPU you are doing billions of guesses per second, so a service account with a dictionary-plus-rules password falls almost immediately. This is why the technique has such a high hit rate in real environments: the accounts that have SPNs are exactly the accounts whose passwords were set once and forgotten.

John the Ripper handles the same hashes with the krb5tgs format if you would rather autodetect and stay in one tool. The tooling tradeoffs apply as usual.

When you pull etype 17 or 18

Sometimes the ticket comes back as $krb5tgs$18$ instead of $krb5tgs$23$. That is AES256, and the mode is -m 19700 (or 19600 for AES128). The structure looks similar. The cracking experience does not. AES Kerberos uses a deliberately slow string-to-key derivation, so your throughput collapses from billions per second to something more like hundreds of thousands. A password that would fall instantly under RC4 is now effectively out of reach unless it is genuinely weak.

You cannot always force RC4. Modern domains can be configured to only issue AES tickets for an account, and when that is the case, Kerberoasting that account is mostly a dead end. Do not burn a week of GPU time on a single AES ticket hoping for a miracle. Move on to the RC4 ones and the AS-REP roastable accounts.

Reading the result like an attacker, and a defender

A cracked service account is rarely the goal in itself. It is leverage. Service accounts are frequently over-permissioned, sometimes sitting in Domain Admins because that was the fast way to make something work in 2019. So the real value of a krb5tgs crack is what that identity can reach next.

From the defensive side, the uncomfortable truth is that you cannot stop users from requesting tickets, that is Kerberos working as designed. What you can do is remove the prize. Use group managed service accounts so the passwords are 240-bit random and rotate automatically. Audit which user accounts carry SPNs and ask why. And force AES, because turning a 13100 crack into a 19700 crack changes the economics enough that most attackers will not bother.

The password length is the only thing that actually saves you here. A 14-plus character random service account password survives RC4 Kerberoasting fine. Welcome2024! does not, and rules-based wordlists eat it in seconds.