An interview candidate is asked how they'd detect Kerberoasting in an Active Directory environment. "You'd look for a spike in TGS requests," they say. The interviewer waits for more. There isn't more. That answer is technically true and completely useless, because in any AD environment with real usage, ticket-granting-service requests are constant, ordinary traffic. Every person opening a mapped drive or hitting a service account generates one. A detection rule built on volume alone either fires on every Tuesday at 9am when everyone logs on and gets muted by the SOC within a week, or misses the attack entirely because a patient attacker requests tickets slowly enough to blend in.
The actual signal isn't how many TGS requests happened, it's what encryption type they asked for. Kerberoasting works because a service account's TGS ticket is encrypted with a key derived from that account's password hash, and if an attacker can get that ticket issued with RC4 encryption instead of AES, they can take it offline and crack the password hash without touching the domain controller again. Most environments configured any time in the last several years support AES for service tickets by default. A domain controller logging Event ID 4769 with ticket encryption type 0x17 (RC4-HMAC) for an account where AES was available is not background noise. That's a client deliberately downgrading the crypto to get a crackable ticket.
That's the rule worth writing: not "a TGS request happened" but "a TGS request for a service account, encryption type RC4, in an environment where AES is the default." Add a second layer, several distinct service tickets requested by the same source in a short window (an attacker enumerating every SPN in the domain rather than requesting the one ticket a normal user needs), and the false-positive rate drops enough that a SOC can actually act on the alert instead of muting it.
Writing that logic once is the easy part. Writing it in the query language your actual SIEM speaks is where most detection engineers spend their week, because the field name for ticket encryption type is not the same in Sigma, Splunk SPL, Sentinel KQL and Elastic EQL, and a rule that fires cleanly against a Splunk lab environment does nothing when it's copied into Sentinel with a mismatched field reference. Nobody notices the gap until the actual attack sails through clean.
Codelivly's Detection Engineering Book walks through this exact rule, and a dozen others like it, written natively in Sigma, Splunk SPL, Sentinel KQL, Elastic EQL and Wazuh side by side, alongside the broader AD attack investigation patterns that Kerberoasting is just one example of. The detection engineering lab on the site gives you real logs to build and test the rule against instead of taking the field names on faith.
Top comments (0)