Kerberoasting: how service account passwords get cracked, and how to stop it
Kerberoasting lets any domain user request service tickets and crack them offline for service account passwords. Here is how it works, how to detect it, and the fix that actually holds.
Kerberoasting turns any ordinary domain account into a path to service account passwords, with no elevated rights needed to start.
What it is
Any authenticated domain user can request a Kerberos service ticket (a TGS) for any account that has a Service Principal Name. Part of that ticket is encrypted with the target service account’s password hash. The attacker requests tickets for SPN-bearing accounts, takes them offline, and cracks weak passwords with a tool like Hashcat. Nothing about the request looks abnormal, because requesting service tickets is normal. In ATT&CK terms this is T1558.003.
Why it works
Service accounts often have weak, human-chosen, non-expiring passwords and more privilege than they need. Tickets encrypted with RC4 (etype 23) crack especially fast. One crackable service account with broad rights can hand the attacker lateral movement or escalation.
How to detect it
Look for a spike in Event 4769 (TGS requests), especially RC4 requests, from a single principal asking for many different SPNs in a short window. A honeypot account with an SPN and no legitimate use is a high-fidelity tripwire: nobody should ever request its ticket.
The fix that holds
Move service accounts to group Managed Service Accounts (gMSA), which use long, machine-managed passwords that cannot be cracked in practice. Where gMSA is not possible, enforce 25-plus character passwords. Disable RC4 where you can so tickets use AES. And least-privilege the service accounts, so even a cracked password yields little.
Practice it
We built a Kerberoasting scenario in GraphLattice Range so teams work detection and the gMSA fix end to end.