Kerberoasting Beyond RC4
Hunting AES-encrypted service-ticket extraction and the detection patterns that actually hold up in real AD environments.
The title was chosen deliberately. Most Kerberoasting talks are about the attack. This one started from a different question: what happens after you enforce AES-only encryption across your environment? Many teams assume AES makes them immune. It changes the economics. It does not close the window.
The AES assumption
RC4-based Kerberoasting is fast to crack because hashcat mode 13100 processes hundreds of millions of candidates per second on modest GPU hardware. AES-256 (mode 19700) is around 30x slower. This is real protection for accounts with cryptographically strong passwords. It is not protection for service accounts with dictionary-derivable passwords - even 20-character ones - because dictionaries contain long passwords too.
shell# AES-only environment, 'strong' password $ hashcat -m 19700 svc_ticket.hash company-wordlist.txt Speed.#1.........: 3,840 kH/s Recovered........: 1/1 (100.00%) svc_exchange_prod:Company@2022Quarter3!
Detection that holds up
The second half covered detection. RC4 Kerberoasting generates TGS-REQ events (Event ID 4769) with enc_type 0x17, a well-known signal. For AES-only environments, the discriminating signal is request volume and velocity from a single account. The threshold between legitimate bulk TGS requests and a roasting run is environment-specific, which means if you have not baselined it, you do not have a rule for it.
The Blue Team Village audience had good coverage of the tooling side. The less-rehearsed discussion was about baselining. How many TGS requests per minute is normal for your Tier 0 service accounts? If you cannot answer that, you cannot write a useful rule for this technique.