A SOC analyst pulls a week-old ticket back up during a slow shift, the kind of "low confidence, auto-closed" alert that gets triaged in ten seconds and forgotten. A single low-privilege user account requested Kerberos service tickets (TGS-REQs, Event ID 4769) for forty different service accounts inside a three-minute window. The SIEM's correlation rule fired on volume, somebody glanced at it, saw the user wasn't an admin and hadn't triggered anything else that week, marked it benign, closed it. Nobody asked the one question that actually mattered: why does a help-desk account need service tickets for forty different services it never logs into?
That volume-in-a-short-window pattern is close to the textbook shape of Kerberoasting, and it's worth knowing cold because it's one of the quieter privilege-escalation techniques in Active Directory: any authenticated domain user, no special rights needed, can request a TGS for any service that has a Service Principal Name registered. The domain controller obliges, because that's what Kerberos is supposed to do. The ticket comes back encrypted with a hash derived from the service account's own password. The attacker doesn't need to touch the DC again after that: they take the ticket offline and crack it at their own pace, on their own hardware, against the service account's password. If that service account was set up five years ago with a static password nobody has rotated since and it holds high privileges, which describes an uncomfortable number of real service accounts, the attacker now has a path to a privileged credential without ever tripping a lockout policy or an obvious anomaly on the DC itself.
Here's the detail that turns "a user requested some tickets" into "someone is Kerberoasting": the encryption type field inside that same Event 4769. Kerberos supports AES (etype 0x11 for AES128, 0x12 for AES256) and the legacy RC4-HMAC (etype 0x17). Modern, correctly hardened environments should be issuing AES tickets almost everywhere. RC4 tickets are what you get from Kerberoasting tools like Rubeus or Impacket's GetUserSPNs.py by default, because RC4-encrypted tickets crack dramatically faster offline than AES ones, and a lot of tooling explicitly downgrades the request to force it. So the actual hunt isn't just "did this account request a lot of TGS tickets." It's "did this account request TGS tickets with etype 0x17, for service accounts it has no legitimate reason to touch, in a burst, from a host that isn't a normal service-ticket-heavy box like a web server."
Baselining matters here more than the raw event does. A file server or an application server legitimately requests TGS tickets constantly as part of normal Kerberos delegation, that's expected traffic and alerting on 4769 volume alone drowns you in noise. What you're hunting for is the same event type on a host and account pair that has no business generating it: an interactive user workstation, or a service account that normally touches two or three specific services, suddenly requesting tickets for a wide, unrelated set, with RC4 where AES is the norm everywhere else in the environment.
The response side matters as much as the detection: an RC4 ticket for a Kerberoastable account isn't itself a breach, it only becomes one if the password cracks. That means the actual fix is upstream of any SIEM rule, service accounts need long random passwords (or better, a group-managed service account with automatic rotation) and AES enforced domain-wide, so a captured ticket is worthless even when the request itself looks completely legitimate to Kerberos.
This is exactly the kind of hypothesis-driven, ATT&CK-mapped hunting (Kerberoasting is T1558.003) the Hands-On Threat Hunting Book walks through across Windows, Linux, network and cloud, not "wait for the SIEM to flag it" but knowing which field inside a routine-looking event actually separates normal delegation traffic from someone quietly harvesting crackable tickets: https://resources.codelivly.com/product/threat-hunter-hands-on-threat-hunting-blue-team-guide/
The free Threat Hunting and MITRE ATT&CK Mapping labs on codelivly.com are good places to practice this exact hypothesis-driven approach hands-on before you need it live: https://codelivly.com/labs/threat-hunting and https://codelivly.com/labs/attack-mapping
