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.
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.
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.
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):
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:
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.
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. Sign up for a free trial of Blumira’s platform to test it out yourself.
Another great way to improve your security is to prevent domain-based attacks before they happen. With the Blumira free Domain Security Assessment, you'll get a detailed report of:
Request your free Domain Security Assessment to identify and remediate security gaps today.