Kerberoasting Attack — Stealing Service Account Secrets

How Kerberoasting works — at a glance

1. Attacker obtains any valid domain user context (low privilege is enough).
2. Enumerate accounts with an SPN set — these are service accounts.
3. Request a Ticket Granting Service (TGS) ticket for the target SPN from the Key Distribution Center (KDC).
4. Extract the encrypted TGS part (encrypted with the service account hash / key).
5. Perform offline brute‑force or dictionary cracking against the extracted blob to recover the service account password.

Common tools

• Impacket — GetUserSPNs.py: enumerate SPNs and dump TGS hashes for cracking.
• Rubeus: Windows tool that can request TGS tickets from a compromised host and export them.
• Hashcat / John the Ripper: perform offline cracking of extracted TGS hashes.
• Detection tooling: SIEMs, Defender for Identity, or custom correlation for Kerberos anomalies.

Example — enumerate & extract TGS tickets (Impacket)

On a Linux machine with Impacket installed (you have domain credentials):

python3 GetUserSPNs.py DOMAIN/username:Password -dc-ip 10.0.0.5 -outputfile tgs_hashes.txt

This will search Active Directory for accounts with SPNs and request service tickets. The output file contains the encrypted blob that can be cracked offline by Hashcat/John.

Example — Kerberoast on a compromised Windows host (Rubeus)

If you have code execution on a domain-joined Windows host, Rubeus can request TGS tickets directly and export them for cracking:

Rubeus.exe kerberoast /format:hashcat /outfile:hashes.txt

Rubeus has flexible options (request a specific SPN, use an existing TGT, output formats). Use Rubeus.exe kerberoast /? for full syntax.

Cracking the ticket (Hashcat)

Once you have the exported hash, run Hashcat. Kerberos TGS‑REP blobs typically map to Hashcat mode 13100 (Kerberos 5, TGS‑REP etype 23). Example:

hashcat -m 13100 tgs_hashes.txt /path/to/wordlist.txt -o cracked.txt

Use GPUs, large wordlists, and rules to increase success probability. Strong, random passwords dramatically reduce the chance of cracking.

Detection & defensive signals

• Large numbers of TGS requests originating from a single host or user account.
• Requests for TGS with unusual encryption types (RC4) when the environment prefers AES.
• Service accounts suddenly requested by low‑privileged users or non‑service principals.
• Monitor Kerberos event IDs and KDC audit logs; correlate with user and host activity.

Mitigation — practical steps

1. Use strong, unique passwords for service accounts — long (> 20 chars), random, and rotated regularly. Consider managed service accounts (gMSA) where possible.
2. Prefer AES encryption types and disable legacy RC4 where feasible. Monitor tickets encrypted with weak ciphers.
3. Minimize SPNs on user accounts. Run services under managed accounts (gMSA) or computer accounts instead of regular users with SPNs.
4. Monitor and alert on anomalous TGS request patterns and unusual requester accounts.
5. Apply least privilege to service accounts and avoid adding them to privileged groups (Domain Admins, etc.).
6. Rotate the KRBTGT keys only following Microsoft's documented procedures if you suspect ticket/key compromise.

Quick checklist for Blue Teams

• Audit accounts with SPNs: setspn -Q * and inventory them centrally.
• Enforce strong password policies for service accounts.
• Disable RC4 and migrate to AES for Kerberos encryption.
• Alert on mass TGS/ticket requests and RC4 (etype 23) tickets.
• Consider honey tokens / decoy SPNs to detect early reconnaissance.