Back to BlogDefending Against AD Kerberos Attacks
Much has been written by pentesting and red teams to explain how to leverage attacks against the Kerberos protocol. Using AD kerberoasting to quickly escalate privileges and take over service accounts within Active Directory domains. This post aims to arm defenders with clear instructions on how to detect and prevent Kerberoasting. To muzzle the ferocious three-headed guard dog of Hades, we do this by keeping it simple and answering the following questions.
- What is Kerberoasting?
- How often are Kerberoast attacks seen in the wild?
- How do I detect Kerberoasting?
- How do I prevent Kerberoasting?
What is Kerberoasting?
In Kerberoasting, threat actors abuse valid Kerberos ticket granting tickets to make a request for a ticket granting service from any valid service principal name (SPN) within your Microsoft Active Directory domain. Such ticket granting services can be vulnerable to offline password cracking. This can allow a threat actor to recover the plaintext password of the associated service account mapped by the SPN.
To be effective, an attacker must select a type of encryption which is susceptible to brute-force attacks. In Kerberoasting, this is almost always RC4_HMAC (0x17). See the Kerberos (protocol) Wikipedia landing page for a broad protocol definition.
How Often Are Kerberoast Attacks Seen in the Wild?
Modern malware, especially ransomware, has adapted to leverage what have traditionally been pentester tactics and methods to infect business networks. Last November, the DFIR Report issued an in-depth analysis demonstrating the use of Kerberoasting to aid in spreading ransomware throughout business networks in less than two hours.
The threat research arm of FireEye issued its own report that also linked Kerberoast attacks as the prefered method to rapidly gain access to healthcare agencies for the purpose of deploying ransomware.
To be clear, this method is often observed and should be prioritized as critical risk. When someone says “Kerberoast,” we should be thinking about ransomware.
How Do I Detect Kerberoasting Attacks?
When an attacker attempts to enumerate your Active Directory environment for potentially vulnerable service accounts, this is typically completed via automation, such as PSEmpire, Rubeus, or other tools. Much has been written on how to use these scripts to successfully use Kerberoast to attack an environment. The point is that automation is predictable if we know what to look for.
So what do we see in the logs when someone attempts to attack with this method? Assuming Auditing of Kerberos Service Ticket Operations has been enabled within your domain policy, you will notice the following Kerberos events (see Sean Metcalf’s post on Kerberoasting for a deep dive on this):
- Event ID: 4769
- Encryption type: 0x17
- Ticket options: 0x40810000
- ClientIP: (Where the attack is coming from)
There’s a dirty secret most detection guidance neglects to mention though. If you operate a network with legacy services you likely have domain controller logs full of these events, making detection based solely on this criteria all but impossible.
To overcome this, you can take two approaches:
- The first is to adopt statistical baselining, and if you have a dedicated team to tune specifically for your environment this is a prefered approach. A good example using KSQL can be found here, however, this approach can be quite labor intensive.
- The second approach is to create a honey credential (or honeytoken), which is never used and exists solely to act as a canary. We’ve created a PowerShell script which we are releasing to help you create this token securely, called Dogemira
How Do I Prevent Kerberoasting?
Prevention of Kerberoasting can be accomplished through multiple methods and we recommend investigating each method to improve your Active Directory security hygiene.
Securely configure Kerberos-related domain controller policies and settings.
- Enable AES Kerberos encryption (or another stronger encryption algorithm), rather than RC4, where possible.
- Consider using Group Managed Service Accounts rather than service accounts with static passwords
- Consider upgrading to an Active Directory Domain or forest level which supports advanced Kerberos armoring.
- Ensure all of your service accounts have randomly generated 25+ character passwords
How Blumira Can Help
Blumira’s cloud SIEM offers automated detection and response, helping you identify threats in your environment, and integrating broadly across your full tech stack, including Microsoft environments. Learn more in our Guide to Microsoft Security or sign up for a free trial of Blumira’s platform to test it out yourself.