Kerberoasting

Any authenticated domain user can request a Kerberos service ticket (TGS) for any account that has a Service Principal Name (SPN) registered — that's how normal Kerberos authentication to a service works. The catch is that the ticket's data is encrypted with a key derived from the service account's own password, not the requester's. That means any domain user can walk away with material they can attack offline, entirely without touching the target account or generating a failed-logon event.

How it works

1. Enumerate domain accounts with an SPN set (service accounts running SQL Server, IIS application pools, custom line-of-business services, etc. — these are frequently older accounts with weak, rarely-rotated passwords).
2. Request a TGS for each SPN using the requester's own valid, unremarkable session — this is completely normal Kerberos traffic from the KDC's point of view.
3. Take the encrypted portion of each returned ticket offline and attempt to crack it, since a correct password guess is the only way to produce a ticket that decrypts to well-formed Kerberos structures.

Tickets requested with the legacy RC4 (etype 0x17) encryption type are far cheaper to crack than AES-encrypted tickets, so tooling that can force or prefer RC4 makes the offline stage dramatically faster.

Detection & analysis

• Volume and encryption type — Windows Security Event ID 4769 (a Kerberos service ticket was requested) with Ticket Encryption Type 0x17 (RC4), especially many such requests in a short window against many different SPN-bearing accounts from one source, is the classic detection signature — legitimate clients rarely request RC4 tickets in an AES-capable domain.
• Honeypot accounts — A deliberately planted SPN-bearing decoy account with a strong, monitored password turns any TGS request against it into an unambiguous alert, since no legitimate service should ever be authenticated to.
• Remediation posture — The only durable fix is password hygiene on service accounts: long, randomly generated passwords (via a Group Managed Service Account where possible) make offline cracking infeasible regardless of how many tickets are harvested.
• Tools — Rubeus and Impacket's GetUserSPNs.py for understanding the request/harvest side, Microsoft Defender for Identity / Event ID 4769 analytics for detection, hashcat mode 13100 for understanding what the offline-cracking stage actually attacks.