A kerberoasting attack is a technique for stealing Active Directory service account passwords by abusing a legitimate part of the Kerberos protocol. An attacker with any domain account requests a service ticket, takes it offline, and cracks it with GPU-accelerated password tools, all without ever touching the domain controller again or risking a lockout counter.
It sits in the credential access phase of an intrusion, usually right after initial compromise and right before privilege escalation into real access. Once you understand the mechanics, the defences make a lot more sense.
Why a kerberoasting attack is such a common escalation path
Red teams and real intruders both reach for this technique for the same reason: the entry cost is low and the payoff is often high. A phished marketing account or a leaked low-privilege credential is enough to start the enumeration. The accounts it turns up, database servers, backup jobs, monitoring agents, are frequently over-privileged because someone added them to a broad group during setup and nobody has revisited that decision since.
That is also why a kerberoasting attack shows up so often in penetration test reports and incident write-ups: it does not depend on a specific unpatched CVE, so patching alone will never remove it. It depends on password hygiene and account configuration, both of which drift over time unless someone actively audits them.
The Kerberos quirk that makes it possible
In a Windows domain, services that need network authentication, a SQL Server, a web application, a file share, are registered under a Service Principal Name (SPN) tied to whichever account runs them. A client that wants to use that service presents its ticket-granting ticket to the domain controller. It then asks for a ticket-granting service (TGS) ticket for that specific SPN.
The domain controller encrypts the returned TGS ticket with a key derived from the service account’s own password hash. It does this for any authenticated requester, without first checking whether that requester has any actual right to use the service. That single design choice, issue first, authorise later, is the entire attack surface.
RC4, AES128 and AES256: what the difference actually means
| Encryption type | Ticket prefix | Crack speed | Why it matters |
|---|---|---|---|
| RC4-HMAC (etype 23) | $krb5tgs$23$ |
Fast on consumer GPUs | Default target for most kerberoasting tools |
| AES128 (etype 17) | $krb5tgs$17$ |
Much slower | Raises attacker cost significantly |
| AES256 (etype 18) | $krb5tgs$18$ |
Slowest | Best available Kerberos encryption today |
None of the three prevents the ticket request itself. Any authenticated user can still ask for a ticket to any SPN regardless of encryption type; AES simply makes cracking that ticket computationally expensive rather than impossible. A weak or reused password will eventually fall to AES too, so encryption type changes the attacker’s timeline, not the outcome.
How a Kerberoasting Attack Actually Runs
An attacker who already controls one domain account, often through phishing, exposed credentials or a compromised low-privilege service, queries Active Directory for every account carrying an SPN. Tools built for this are widely available and well documented. Rubeus can enumerate and request tickets in one pass, and Impacket‘s GetUserSPNs.py does the same from a Linux attack box.
For each SPN found, the attacker requests a TGS ticket, then walks away with it. There is no need to stay connected to the domain while cracking; Hashcat or John the Ripper run entirely offline against wordlists, rule sets and, eventually, brute force. CrowdStrike notes the attack lets adversaries “pose as a legitimate user” once a password cracks, moving laterally or escalating privilege using credentials that look entirely genuine to every downstream system.
What detection actually looks like
A kerberoasting attack leaves a trace, just not on the endpoint. Every TGS request is logged as Windows Event ID 4769 on the domain controller that issued it. The first requirement is centralising Security logs from every DC into one place; a single DC’s log is not the whole picture. Netwrix recommends flagging two signals in particular: an abnormal number of distinct SPNs requested by one account in a short period, and any ticket requested with RC4 (0x17) when the target account supports AES.
A well-placed honeypot account sharpens this further. Set up a decoy service account with a fake SPN nothing legitimate ever calls, then treat any 4769 event referencing it as a near-certain sign of reconnaissance. Because there’s no legitimate reason for that ticket to ever be requested, false positives are rare.
Fixing it properly
Microsoft’s 2024 guidance on the technique, published after seeing it used repeatedly in real intrusions, ranks Group Managed Service Accounts (gMSA) as the strongest fix. A gMSA’s password is around 120 characters, randomly generated, and rotated automatically by the domain, so even a captured ticket has nothing practical to crack. Windows Server 2025 extends this with Delegated Managed Service Accounts for services that still need a migration path.
Where a managed account is not yet possible, push service account passwords well past Microsoft’s 14-character minimum and enforce AES128 and AES256. Reset the password immediately after the encryption change so it actually takes effect. Then audit which accounts hold an SPN at all: plenty were configured years ago for software that no longer exists, and each one left standing is a target waiting to be found. MITRE ATT&CK lists this whole family of mitigations under T1558.003, alongside restricting privileged group membership for service accounts so a cracked password buys an attacker as little as possible.
None of this needs to happen all at once. Start by pulling a list of every account with an SPN set and checking password age and group membership; that single audit usually surfaces the worst offenders fast. Migrate the highest-privilege accounts to gMSA first, since those are the ones an attacker would prioritise too, then work down the list. Combined with centralised logging on Event ID 4769, an organisation can go from having no visibility into kerberoasting to actively hunting for it in an afternoon.
Frequently asked questions
Can a normal domain user really request a ticket for any service?
Yes. Kerberos issues TGS tickets to any authenticated user for any SPN in the domain, then relies on the service itself to enforce access control afterward. That gap between issuing and authorising is exactly what kerberoasting abuses.
Is AES256 enough to stop a kerberoasting attack on its own?
No single control is. AES256 makes cracking far slower than RC4, but a weak or short password will still eventually fall. Pair strong encryption with managed, randomly generated service account passwords.
How is this different from a golden ticket attack?
A golden ticket forges a fully valid TGT using a stolen krbtgt account hash, effectively granting unrestricted domain access. Kerberoasting instead cracks a real service account password from a legitimately issued ticket, a narrower but far easier attack to pull off.
What tools do defenders use to hunt for kerberoastable accounts before attackers do?
Many teams run the same enumeration tools attackers use, such as PowerView or Impacket, against their own domain. That surfaces SPN-holding accounts with weak or old passwords so they can be fixed before an intrusion ever starts.
Does multi-factor authentication stop kerberoasting?
Not directly. MFA protects the initial login, but once an attacker already holds a valid domain session, the TGS ticket request a kerberoasting attack relies on does not prompt for MFA again.
Does kerberoasting work against cloud-only identities?
No, it is specific to on-premises Active Directory’s implementation of Kerberos. Azure AD and other cloud identity providers use different protocols for service authentication, so a purely cloud environment has nothing for this particular technique to target. Hybrid environments that still run an on-premises domain controller remain exposed.