Kerberoasting from the blue side: catching service-ticket abuse without drowning in 4769

Every Kerberoasting detection guide says the same thing: alert on event 4769. What most of them leave out is that 4769, the Kerberos service ticket request, is one of the loudest events your domain controllers generate. Every time anyone accesses any Kerberos-authenticated service, that’s a 4769. Turn on a naive “alert on 4769” rule in a real domain and you’ll mute it before lunch. So the problem was never collecting the event. It’s filtering the millions of legitimate ones down to the handful that are an attacker pulling tickets to crack offline.

I want to walk through how I tune this, because the raw event is close to useless and the tuned version is one of the better credential-access detections you can run. Running these notes against a domain at 2016 functional level with the DC security log forwarded, nothing exotic.

What Kerberoasting looks like in the log

The attack, quickly: any authenticated user can request a service ticket for any account that has a Service Principal Name registered, and the ticket comes back encrypted with that service account’s password hash. Take it offline, crack it, you have the service account’s password. It’s MITRE ATT&CK T1558.003. The attacker doesn’t need to be an admin. They need to be anyone.

In the log, that request is a 4769 on the DC, and three fields decide whether it’s interesting:

• Ticket Encryption Type. This is the big one. Attackers ask for RC4 (0x17) because RC4-encrypted tickets crack far faster than AES. If your domain has largely moved to AES, an RC4 request stands out. In a domain that’s still RC4-heavy, it doesn’t, which is its own finding.
• Service Name. Kerberoastable accounts are user accounts with an SPN, so the service name is a user, not a machine account ending in a dollar sign. A 4769 whose service name is a normal user account is worth a second look. A 4769 for a machine account almost never is.
• Account requesting it. One user account requesting tickets for many distinct SPNs in a short window is the velocity signal. Normal users request tickets for the services they use, slowly, over a day. A roasting tool requests a pile of them in seconds.

The tuned rule, and why it still has FPs

So the first-pass rule is: 4769, encryption type 0x17, service name is a user account, ticket options and failure code showing a successful request. That cuts the millions down to something a human can look at.

It still has false positives, and you should know where they come from before you ship it. Old application service accounts that were never migrated off RC4 will generate exactly this pattern as part of their normal operation. (Yes, that means your detection is partly a report on your own technical debt. Fixing the debt fixes the FP.) You tune those known accounts out by name, once, and then the rule is quiet until an account you didn’t expect starts pulling RC4 tickets.

The velocity angle is the more robust half. One principal requesting service tickets for a dozen different user-SPNs inside a minute is hard to explain as legitimate, regardless of encryption type. I tune to that pattern and I care less about the encryption type when the velocity is there.

The honeypot SPN, which skips the noise entirely

Look, the highest-fidelity version of this detection isn’t a filter on 4769 at all. It’s a trap. You create a user account, give it a Service Principal Name that looks tempting (something that reads like a database or admin service), a strong password, and no legitimate purpose. No real process ever requests a ticket for it, because nothing uses it. So any 4769 for that SPN’s service name is, by construction, someone enumerating and roasting SPNs across the domain. The FP rate is close to zero because legitimate traffic for it doesn’t exist.

It costs you one account and five minutes. It’s the single best-value Kerberos detection I know, and I put one in every domain I’m asked to harden. The one caveat: make the honeypot credible, because a decoy account with an obviously fake SPN and a creation date of yesterday gets skipped by anyone paying attention.

Don’t forget the AS-REP variant

While you’re in here, the sibling attack is AS-REP roasting, T1558.004, which targets accounts that have Kerberos pre-authentication disabled. That one shows up as a 4768 (the initial authentication request) rather than a 4769, again with an RC4 encryption type, for an account flagged DONT_REQ_PREAUTH. The better detection there is preventive: query your directory for accounts with pre-auth disabled and fix them, because there are usually only a few and none of them should exist. The 4769 event reference from Microsoft covers the field layout for both if you want to build the parser yourself.

What I’d tune first

If you’re setting this up, the order is: plant the honeypot SPN first, because it’s five minutes and near-zero FP and it’ll catch the noisy roasting runs immediately. Then build the velocity rule, one principal to many user-SPNs in a short window, because it survives the encryption-type debate. Then, last, the RC4-encryption-type filter, tuned against your own list of legacy accounts, because that’s the one that doubles as a to-do list for your AES migration.

This pairs with the Sysmon baseline on the endpoint side. Kerberoasting is quiet on the host, it’s a normal ticket request, so the DC log is where you catch the pull. Where the endpoint earns its keep is the step after, when the cracked service account gets used to log in somewhere it shouldn’t. Watch both ends.