The Incident That Started It All
I'm sitting in a war room with a CISO and their incident response team. The attacker has been evicted, the compromised accounts reset, but the question hangs in the air: How did they get to Domain Admin in under two hours?
The answer was sitting right in plain sight - a service account with a password that hadn't changed since 2019, an SPN registered to it, and a direct path to Domain Admin through group membership. The attacker didn't brute force anything against the domain. They requested a service ticket and cracked it offline.
That's Kerberoasting - and if your service accounts have weak passwords, it's trivial. I see it in roughly half of the identity-based intrusions I work these days. This post is for defenders, so I'll keep the attack conceptual and spend the time on detection and remediation.
What Kerberoasting Actually Is
Kerberoasting exploits the Kerberos service ticket (TGS) request process. Conceptually:
- The attacker identifies an account with a Service Principal Name (SPN) registered.
- They request a service ticket for that SPN. Any authenticated domain user can do this - it's normal Kerberos behavior.
- Part of that ticket is encrypted with a key derived from the service account's password.
- The attacker takes the ticket offline and tests password guesses against it, entirely off the domain controller, until one works.
The key point for defenders: because the guessing happens offline, the domain never sees the cracking. Your only on-domain signal is the ticket request itself. Everything after that is invisible to you.
A common misconception is that computer accounts are safe because they use "a shared secret" and user SPN accounts don't. That's not the distinction. Both computer accounts and user service accounts have their tickets encrypted with a key derived from their own password. Computer accounts are safe for a different reason: their passwords are machine-generated, 120+ characters, random, and rotate automatically (every 30 days by default). You can Kerberoast a computer account, but you will not crack the result. The problem is human-set service-account passwords, not the account type.
How Attackers Find Targets - and How You Should Too
Finding accounts with SPNs isn't exotic; it's a standard LDAP query that any authenticated user can run, which is exactly why you should be running it yourself as an audit. Enumerate your own Kerberoastable surface:
Every enabled user account this returns is a potential target. Pay special attention to any that are in privileged groups or have a path to Domain Admin - one high-privilege account with an SPN and a weak password is all an attacker needs.
Why Password Strength Is the Whole Game
The success of this attack depends almost entirely on password strength. Offline cracking is a race between the attacker's hardware and the entropy of the password. Length and complexity are exactly what determine whether a captured ticket ever gets cracked - a short or dictionary-based password falls in seconds, while a long random one is not worth the attacker's time.
I've seen service accounts protected by passwords like ServiceAccount2019! or SQLService$123. These follow predictable patterns and fall to a wordlist almost immediately.
The real issue isn't the technique. It's that organizations treat service accounts as "not real users" - weak passwords, never rotated, more privilege than they need. A Kerberoastable account with a weak password is often more valuable than a normal user, because:
- Service accounts frequently have elevated rights (local admin on many servers, database roles, and so on).
- They're rarely monitored for anomalous behavior.
- Their passwords change infrequently, if ever.
- They're often placed in privileged groups for operational convenience.
Detection: What You Should Be Looking For
Your primary signal is Event ID 4769 - a Kerberos service ticket was requested. The trick is separating roasting from the enormous volume of legitimate 4769 traffic. Focus on these:
| Field | Normal | Suspicious |
|---|---|---|
| Ticket Encryption Type | 0x12 (AES256) | 0x17 (RC4), especially in an AES-standardized domain |
| Requesting Account | Accounts requesting services they normally use | One account requesting tickets for many distinct SPNs in a short burst |
| Target SPN | Service-specific (e.g. HTTP/webapp.corp.local) | Requests sweeping across many service accounts at once |
The highest-value pattern is a single account requesting RC4 (0x17) service tickets for many different SPNs in quick succession. That shape - one requester, many targets, RC4, short window - is far more reliable than any single field.
When you build these rules, exclude the noise that will otherwise drown you:
- Exclude service names ending in
$- those are computer accounts, whose tickets can't be cracked anyway. - Exclude the krbtgt service - every TGT request touches it; it is not a roasting signal.
- Don't treat domain controller SPNs as a signal - DCs are computer accounts, and requests for their services are routine, not an indicator of roasting.
You can also proactively flag accounts with SPNs whose passwords haven't changed in 180+ days - those are your crackable inventory regardless of whether an attack is in progress.
The highest-fidelity detection is a honeypot SPN. Create a decoy account, give it an enticing name (something that looks like a privileged service account), register an SPN on it, give it a long random password, and grant it no real access. No legitimate process will ever request a service ticket for it. So any 4769 targeting that SPN is, by definition, someone enumerating and roasting - a near-zero-false-positive alert. This single control catches roasting activity that volume-based rules miss.
Remediation: Stop the Attack at the Source
You can't "detect your way out" of Kerberoasting. You make the cracked ticket worthless. Here's what actually works.
1. Use Group Managed Service Accounts (gMSA)
This is the real fix for new service accounts. gMSAs:
- Use automatically generated, random passwords of about 120 characters.
- Rotate that password automatically (every 30 days by default).
- Store the password in AD, retrievable only by the hosts you explicitly authorize.
A gMSA can still be Kerberoasted - it has an SPN like any service account - but the resulting ticket cannot be cracked, because the password is long and random. That's the point. Note the prerequisite: gMSAs require a KDS root key in the forest before you can create them (created once, then allow for propagation before use).
2. Enforce AES Encryption for SPN Accounts
RC4 tickets are the easiest to crack. AES tickets are slower to crack - not immune. Forcing AES raises the cost, but it is not a substitute for a strong password; a weak password behind AES will still eventually fall. Do both.
Set msDS-SupportedEncryptionTypes to 24 to enable AES128 + AES256 (that's 8 for AES128 plus 16 for AES256). Setting it to 8 alone enables only AES128.
Test before rolling this out broadly - an account or client that genuinely can't do AES will break authentication when RC4 is removed. And if an account's password is very old, reset it after making the change: accounts whose password predates the domain's AES support may not have AES keys until the password is set again.
3. Remove Unnecessary SPNs
Every SPN you register adds attack surface. Audit regularly:
- Remove SPNs from accounts that don't need them.
- Consolidate service accounts where you can.
- Use host-specific SPNs (HTTP/webserver1.corp.local) rather than generic ones.
4. Rotate and Strengthen Legacy Account Passwords
Where gMSA isn't an option (legacy or third-party apps), the password itself has to carry the weight:
- Use 25+ character passwords with full character variety - length is what defeats offline cracking.
- Rotate on a defined schedule.
- Store credentials in a vault, not in scripts or documentation.
One more piece of hygiene worth getting right: review SPN accounts that are enabled but show no recent authentication activity at all. A service account that never actually authenticates may be an orphan left behind by a decommissioned app - dead weight that's still fully crackable. Confirm what it's for; if nothing uses it, disable it.
The Bottom Line
Kerberoasting works because we treat service accounts as second-class citizens - weak passwords, accumulated privilege, forgotten - until an attacker uses one as a skeleton key.
Stop treating service accounts as non-user accounts. Any account with a human-set password and an SPN is a target. Prioritize the ones whose passwords haven't changed in over a year. Move new services to gMSA, enforce AES on existing SPN accounts, remove SPNs you don't need, and stand up a honeypot SPN for detection.
The attack is trivial only if you let it be. With strong passwords behind those SPNs, it stops being worth an attacker's time - and they move on to someone else.