You're three hours into your first Active Directory engagement with nothing but a single low-privilege domain user account, no admin rights anywhere, no credentials worth writing down yet. You run one command, a completely unprivileged Kerberos ticket request against every service account you can enumerate in the domain, and you walk away with a stack of encrypted blobs you can crack offline, on your own hardware, with zero further contact with the domain controller. That's kerberoasting, and the reason it works is worth understanding all the way down, because the vulnerability isn't a bug. It's how Kerberos service tickets were designed to work in 1988, applied to a threat model that didn't exist yet.
Here's the actual mechanic. In Kerberos, when a client wants to talk to a service, say a SQL server running under a domain service account, it asks the Key Distribution Center (the domain controller, in AD) for a Ticket Granting Service (TGS) ticket for that service's Service Principal Name (SPN). The KDC issues that ticket, and here's the part that matters: the ticket is encrypted with a key derived from the service account's own password hash, not the KDC's key, not anything tied to the requesting user. That's by design, it's how the service can decrypt and trust the ticket without a live round trip to the KDC on every request. And critically, any authenticated domain user can request a TGS for any SPN registered in the domain. No special privilege required. It's a completely ordinary, logged-as-normal Kerberos operation.
So the attack is just: enumerate every account in the domain with an SPN set (setspn -Q */*, or the LDAP equivalent), request a TGS for each one, and take the encrypted portion of each ticket off the network entirely. From there it's an offline cracking problem against hashcat -m 13100, no further contact with the domain, no failed-login events, no lockout policy triggered, nothing that looks different from a normal service ticket request in the logs unless someone is specifically watching ticket request volume per user.
The reason this works so well in practice, more than the protocol quirk itself, is what kind of account usually holds an SPN. Service accounts are the accounts nobody thinks about after setup. They run a scheduled task or a database service, they were created once, given a password that satisfied the complexity policy at the time, and then never logged in interactively again, which means they never hit the account lockout or password expiry nudges a human account does. A service account password set five years ago at "just complex enough to pass the policy" is exactly the kind of hash that falls to a wordlist plus rules in an offline cracking session, and once it falls, whatever that service account was quietly over-privileged with (added to a group for one project, in 2019, and never removed) is now yours.
The fix that actually holds is boring and rarely done: managed service accounts (gMSA) with auto-rotated, cryptographically random passwords that were never "just complex enough," and forcing AES-only ticket encryption so what an attacker captures isn't crackable at RC4 speeds even if they capture it. Neither requires ripping anything out. Both require someone to have actually audited which accounts hold an SPN and why, which is exactly the enumeration discipline that catches this before an attacker does.
Kerberoasting is one technique in a much longer chain: enumerate the domain, find what's reachable, escalate through whatever's weakest, move laterally. That whole arc, not just this one trick, is what Codelivly's Internal Network Penetration Testing Book + Labs walks through end to end. If you want to drill the credential side hands-on first, the free Credential Attacks learning path and the Credential Dumping lab cover the same territory before you put money down.
Top comments (0)