Kerberoasting lets any authenticated domain user request Kerberos service tickets for accounts that have a Service Principal Name (SPN), then crack those tickets offline to recover the service account's password. It works because the ticket is encrypted with the account's password hash — and service accounts often have weak, non-expiring, over-privileged passwords. Because cracking is offline, there are no failed logons or lockouts to warn defenders. It's a top privilege-escalation path in internal tests. Fix it with long random passwords or gMSA, least privilege, AES over RC4, and monitoring — not a patch, because it exploits configuration, not a bug.
// 01 What Kerberoasting is
Kerberoasting is an Active Directory privilege-escalation technique that abuses how Kerberos issues service tickets. In a domain, any account that runs a service can be assigned a Service Principal Name (SPN). When a user wants to use that service, they ask a Domain Controller for a service ticket, and the Domain Controller returns one encrypted with the service account's password hash. The catch: the Domain Controller will issue that ticket to any authenticated user who asks, and it doesn't check whether they actually intend to use the service. An attacker requests tickets for SPN-bearing accounts, extracts them, and cracks them offline to recover the plaintext password.
// 02 How the attack works, step by step
1. Foothold — any ordinary domain user account (no admin rights needed). → 2. Enumerate SPNs — query the directory for accounts with a Service Principal Name. → 3. Request tickets — ask the Domain Controller for service tickets (TGS) for those SPNs; this is a legitimate request. → 4. Extract — pull the encrypted tickets from memory or the response. → 5. Crack offline — brute-force the ticket encryption with a wordlist or GPU, away from the network. → Recovered password for a service account — often privileged.
The whole sequence uses features exactly as designed. Nothing is exploited in the software sense — which is why there's no CVE and no patch, and why detection is hard: steps 1–3 look like normal Kerberos activity.
// 03 Why it succeeds so often
Kerberoasting keeps working because of the nature of service accounts. Three habits combine to make them the perfect target:
- Weak passwords — service accounts are frequently set with short or dictionary passwords chosen for convenience, and rarely changed.
- Non-expiring passwords — to avoid breaking the service, passwords are set never to expire, giving an attacker unlimited cracking time.
- Excess privilege — service accounts accumulate rights, so a single cracked account can be highly privileged, sometimes domain admin.
Add that the cracking is offline — no failed-logon events, no account lockouts — and you have a stealthy, reliable route to escalation. It's one of the recurring steps on the path to Domain Admin we describe in Active Directory attack paths.
// 04 How testers use it
In an internal penetration test, Kerberoasting is a standard early move once a tester has any domain foothold. They enumerate SPN accounts (with tools like BloodHound to see which are privileged), request the tickets, and attempt to crack them offline. A cracked, privileged service account often unlocks lateral movement and, ultimately, domain compromise. Because it's so reliable, finding Kerberoastable accounts — and how quickly their passwords fall — is one of the clearest signals of Active Directory password hygiene, which is why it features in our Active Directory security assessment.
// 05 How to stop it
| Control | Why it works |
|---|---|
| gMSA (Group Managed Service Accounts) | Long, complex passwords rotated automatically — effectively uncrackable |
| Long random passwords (25+ chars) | Where gMSA isn't possible; makes offline cracking infeasible |
| Least privilege on service accounts | A cracked account reaches little |
| Remove unnecessary SPNs | Shrinks the attack surface |
| Enforce AES, disable RC4 | RC4-encrypted tickets crack far faster than AES |
| Monitor service-ticket requests | Bulk or anomalous TGS requests can indicate roasting |
The single highest-impact move is gMSA or genuinely long random passwords on every service account — it removes the offline-cracking payoff entirely. Validate the fix with a hardening review and a follow-up test.
// 06 Frequently asked questions
What is Kerberoasting?
An Active Directory attack where any authenticated domain user requests Kerberos service tickets for accounts with a Service Principal Name (SPN), then cracks them offline to recover the service account's password. It works because the ticket is encrypted with the account's password hash, and offline cracking triggers no lockouts.
Why does it work?
Any domain user can legitimately request a service ticket for any SPN account, and that ticket is encrypted with the account's password hash. Weak or non-expiring service-account passwords are then cracked offline at the attacker's pace, with no failed logons to alert defenders.
How do you prevent Kerberoasting?
Use long random passwords (25+ chars) or Group Managed Service Accounts (gMSA) that rotate automatically, apply least privilege, remove unnecessary SPNs, enforce AES over RC4, and monitor service-ticket requests. Regular AD assessments find Kerberoastable accounts first.
Is it still relevant in 2026?
Yes — it's one of the most reliable privilege-escalation techniques in internal tests, because weak, over-privileged service accounts remain common. It exploits configuration, not a bug, so no patch fixes it; it persists until service accounts are hardened.
// 07 References
- MITRE ATT&CK — T1558.003 Kerberoasting.
- Microsoft — Group Managed Service Accounts overview.
- Related: Active Directory attack paths and our AD security assessment.