An attacker has established a beachhead on your network compromising a low-privilege account. Privilege escalation and lateral movement are key next steps and Kerberoasting can be a low-risk/high-reward technique.

Kerberoasting, mimikatz, golden tickets and silver tickets are all well-covered topics and I’ll not be regurgitating all that if you wish to read up on those here are some links:

Let’s get right into the meat of defending our network with two techniques: hardening and detection

Windows Active Directory Hardening

Going back to basics here, but if you don’t need SPNs get rid of them, there is probably a better way. Also, audit all your accounts with SPNs, you might find you can remove the entire account since it was created 11 years ago for some project and never got cleaned up.

To find all the SPNs you may be able to leverage native tools like SETSPN or powershell, but I find Impacket GetUsersSPN.py to be quick and painless.

 ./GetUserSPNs.py -request -dc-ip 1.2.3.4 contoso/username
Impacket v0.9.17 - Copyright 2002-2018 Core Security Technologies

This will dump all your SPNs, as well as the tickets and since this is basically one step of the attack it may set off some alarm bells, so beware of that. As such, it is a good method to sanity check your logging and detection. Which bring us to…

Logging & Detection

I use Graylog you don’t have to, but if you aren’t logging to some central store and using those logs to monitor your network, it is highly advisable that you start to do so.

First, the Event ID you want to watch for is 4769. You’ll want to make sure your audit logging is configured so that these are getting logged and preferably forwarded to something like Graylog.

This is a noisy Event ID but I will leave noise filtering to a future post. For the sake of argument we’ll just assume you are gathering all these events up centrally.

The query I use to alert me to odd Kerberos activity is:

EventID: (4769) AND TicketEncryptionType:0x17 AND NOT TargetUserName:MYPRINTERS$ AND NOT ServiceName:*$

This keeps the alerts at a reasonably low frequency that it is manageable without inducing alert fatigue. Over time I have worked at further reducing the noise by eliminating unused accounts and removing RC4 encryption by editing the msDS-SupportedEncryptionTypes attribute in Active Directory. I still have one account that produces what is essentially false positives, I may end up altering the query above to ignore those as well, if I can convince myself it would be an acceptable blind-spot.

Give me a shout, let me know what you are doing in your environment to counter this threat.