Kerberoasting is one of the most reliable privilege-escalation techniques in Active Directory, and it works because of a normal, expected feature of Kerberos: any authenticated user can request a service ticket for any service. The catch is that the ticket is encrypted with the service account's password-derived key — so requesting one and cracking it offline recovers that account's password. No exploit, no elevated privilege, just the protocol used from an unintended angle.
The prerequisite: Service Principal Names
A Service Principal Name (SPN) is a string that maps a service to
the account that runs it, e.g. MSSQLSvc/db01.corp.local:1433 owned by
svc_sql. Kerberos needs SPNs so a client can ask for a ticket to a
named service. Any account with an SPN set is, by definition, a candidate for
roasting.
The accounts that carry SPNs are service accounts — the accounts that run SQL, IIS app pools, scheduled jobs, and line-of-business software. Two things make them attractive targets:
- Their passwords are often old, set once at deployment and never rotated, because rotating them risks breaking the service.
- They are frequently over-privileged — granted local admin, or even Domain Admin, "to make it work".
The worst case, and a common one, is a service account that is a member of Domain Admins with a weak password set in 2019. Kerberoasting turns that into full domain compromise from any authenticated user — which is why it is often the fastest path on an engagement.
How the attack works, step by step
| Step | What happens |
|---|---|
| 1. Enumerate SPNs | Query LDAP for accounts with servicePrincipalName=* — the roastable set |
| 2. Request tickets | Send a normal TGS-REQ for each SPN; the KDC returns a service ticket (TGS-REP) |
| 3. Extract the ciphertext | The ticket's encrypted portion is encrypted with the service account's key |
| 4. Crack offline | Guess passwords, derive the key, and test it against the ciphertext — entirely offline |
| 5. Authenticate | On a hit, log in as the service account with the recovered password |
Only step 2 touches the network, and it is indistinguishable from legitimate Kerberos activity — a user requesting a service ticket is the most normal thing on the domain. The cracking in step 4 happens on your own machine and generates no traffic at all.
The tools that perform this — Impacket's GetUserSPNs, Rubeus, and NetExec — all request RC4-encrypted tickets where possible, because RC4 (etype 23) cracks far faster than AES. The full exploitation walkthrough, with commands, is in the Vulns & Misconfigs section under Kerberoasting; this page is the mechanism behind it.
Why the encryption type matters so much
| Ticket etype | Cracking reality |
|---|---|
| RC4 (23) | Fast. Billions of guesses per second on commodity GPUs — a weak or medium password falls quickly |
| AES256 (18) | Far slower due to the key-derivation function; roasting yield drops sharply, and only weak passwords remain practical |
A domain that enforces AES-only Kerberos removes most of the roasting risk — not by stopping the ticket request, but by making the resulting material impractical to crack unless the password is genuinely weak. Attackers still try, because service-account passwords are disproportionately weak.
Targeted Kerberoasting
A variant worth knowing: if you have write access to an account (via an ACL), you can add an SPN to it, roast it, then remove the SPN. This turns any writable account into a roastable one on demand, and it is a common BloodHound-identified path. It is the point where an ACL weakness converts into a crackable credential — the write primitive and the roast primitive meeting on one account.
Detection and defence
| Control | Effect |
|---|---|
| Strong service-account passwords (25+ random chars) | Makes offline cracking infeasible even with RC4 tickets — the single best defence |
| Group Managed Service Accounts (gMSA) | The DC manages a 120+ character password automatically; effectively uncrackable |
| AES-only Kerberos | Removes the fast RC4 cracking path |
| Least privilege for service accounts | Limits the blast radius when one is cracked |
| Monitor event 4769 | A burst of TGS requests, especially for RC4, from one account is the detection signal |
| Honeypot SPN accounts | A decoy account with an SPN and no real use — any ticket request for it is malicious |
The takeaway
Kerberoasting is not a vulnerability in Kerberos; it is the intended behaviour of the TGS exchange meeting the reality of weak, over-privileged, never-rotated service accounts. The request is invisible against normal traffic and the cracking is offline and silent. The defence is entirely on the account side — long random passwords or gMSAs — which is why finding a roastable admin account with a weak password remains one of the highest-value single findings in an internal engagement. The tooling is in theToolkit Vulns & Misconfigs (Impacket, Rubeus, NetExec); the protocol background is on the Kerberos page.