Kerberoasting: Why Service Accounts Are Still the Easiest Way In
The Kerberos TGS-REQ mechanics that make service account password cracking possible, and why it remains effective years after being publicized.
Kerberoasting has been public knowledge since 2014, yet it still shows up in nearly every internal Active Directory assessment. The reason isn’t a lack of awareness — it’s that the fix (strong, rotated service account passwords or managed service accounts) requires operational discipline that’s easy to defer indefinitely.
The mechanic, briefly
Any authenticated domain user can request a Kerberos service ticket (TGS) for any service registered with a Service Principal Name (SPN), by design — that’s how Kerberos authentication is supposed to work. The TGS is encrypted with a key derived from the service account’s password hash.
This means the ticket itself is fair to request. Nothing about asking for a TGS is anomalous — it’s the offline cracking of the returned ticket that constitutes the attack.
Because the encryption key comes from the account’s password, an attacker who captures the ticket can attempt to crack it offline, with no further contact with the domain controller and no lockout risk.
Why service accounts specifically
Service accounts are the common victims because:
- They’re often over-privileged — created once for an application and granted broad rights “to make it work,” then never revisited.
- Their passwords rarely rotate, since rotating them risks breaking whatever service depends on them.
- They’re frequently set with weak or predictable passwords by whoever provisioned them years ago.
Requesting and cracking
Enumeration starts with finding accounts that have an SPN set — these are Kerberoastable by definition:
Get-DomainUser -SPN | Select-Object samaccountname, serviceprincipalname
Requesting the ticket and extracting the crackable hash is a standard part of tooling like Rubeus:
Rubeus.exe kerberoast /outfile:hashes.txt
The output format is compatible with Hashcat’s mode 13100:
hashcat -m 13100 hashes.txt rockyou.txt
Prioritize accounts with adminCount=1 or membership in privileged groups when triaging Kerberoastable
accounts — a cracked low-privilege service account password is far less interesting than a Domain Admin
service account with an SPN.
What actually stops this
- Group Managed Service Accounts (gMSA). Passwords are 240-character random values, rotated automatically, and never known by a human — Kerberoasting a gMSA is computationally infeasible.
- Long passphrases for legacy service accounts where gMSA migration isn’t yet possible. Length matters far more than complexity rules here, since the crack is fully offline.
- AES-only Kerberos encryption. Disabling RC4 (
msDS-SupportedEncryptionTypes) forces AES tickets, which are meaningfully slower to crack, buying time. - Honey accounts. A deliberately Kerberoastable decoy account with a monitored SPN turns an attacker’s reconnaissance into a high-confidence alert.
Detection notes
Event ID 4769 (Kerberos service ticket request) is generated for every TGS-REQ, which makes raw volume too noisy to alert on directly. What’s worth watching:
- 4769 events with encryption type
0x17(RC4) for accounts that should only support AES. - A single account requesting TGS tickets for an unusual number of distinct SPNs in a short window.
- Any TGS-REQ against a honey account’s SPN.
Kerberoasting endures not because it’s technically sophisticated, but because it converts a directory misconfiguration — weak, static service account passwords — into a fully offline cracking problem. Fixing the account hygiene closes it; nothing about the Kerberos protocol itself needs to change.