With the constant headlines of cyberthreats targeting organizations these days, it’s truly hard to keep up. This blog discusses Kerberoasting attacks— a common attack technique where an adversary attempts to crack the password of a service account within Active Directory.
How do these attacks unfold? What are cybercriminals trying to accomplish? And how can you combat them?
We’ll dive into all those details and more in this post.
What is kerberoasting?
Kerberoasting is a brute-force password attack on Kerberos, an authentication and authorization system that is part of Active Directory. A brute-force password attack is one in which an attacker tries many different passwords against an account very quickly in the hopes of finding a match. Brute force attacks can try completely random passwords, or they can make more educated guesses (as with password spraying and credential stuffing).
Brute force techniques are often mitigated by the authentication system to make them a less compelling technique for attackers. Active Directory can temporarily lock out an account that receives too many incorrect password attempts, for instance.
What makes Kerberoasting such a useful technique to attackers is that it’s an “offline” brute force attack. In an offline attack, the password guesses can be made away from the authentication system and potentially off the defender’s network. This means that the authentication system cannot mitigate the attack, and attacks can be very difficult to detect using auditing software.
Understanding Kerberos
In order to fully understand Kerberoasting, its useful to first understand a few things about Kerberos itself. This will hardly be an exhaustive explanation – Kerberos can be a very complex topic. There is a joke heard from @SwiftOnSecurity about Kerberos: “One time I tried to explain Kerberos to someone. Then we both didn’t understand it.”
Kerberos is used by authentication and authorization systems other than Active Directory, but for simplicity’s sake we will be looking at straightforward examples specific to Active Directory.
When a user authenticates to an Active Directory domain controller, a package is encrypted on the client computer through a “credential provider” that contains the user’s password as entered. The domain controller then decrypts the package and compares the user’s password with the password that is stored in Active Directory.
If it’s a match, the domain controller is ready to vouch that the user who is logging in is who they say they are. The domain controller sends back to the client computer two things: a ticket and a session key. Tickets are a way to prove that a domain controller has vouched for the user’s identity, and session keys secure communication between clients and servers. Session keys are encrypted using passwords (remember that!).
Enter Ticket Granting Tickets
The first ticket that the domain controller generates for the client is called the Ticket Granting Ticket (TGT). As you might guess by the name, the TGT used for getting tickets to other services.
After this initial exchange, it is time to use Kerberos to obtain access to something. This “something” is known as the service. It is important not to get confused by the “service” terminology here – “service” in this context is an abstraction and is distinct from a “Windows service.” Although, Windows services often run executables that provide a service.
Examples of services might be an LDAP-based directory such as Active Directory, a web site using Windows integrated authentication, or a file share served by a network attached storage device. These services have names, which are called quite imaginatively “Service Principal Names” (sometimes referred to by their initialism, SPN). An example of an SPN for Quest’s GPOAdmin service is GPOADmin/GPOADminService/example.local.
When a user wants access to the service, the Ticket Granting Ticket is sent to a Ticket Granting Server (which for Active Directory is a domain controller) in order to receive a session ticket that will grant access to the service.
If this has all made your eye glaze over a bit, here is the critical thing to keep in mind: Each of these components is encrypted by a specific account password. The TGT is encrypted using the krbtgt account password. The messages between the user and the Ticket Granting Server are encrypted using the user’s password. And, most importantly, for the purposes of Kerberoasting, the service ticket is encrypted using the password of the service principal.
So, what Active Directory accounts can be associated with a service principal? Computer accounts, Managed Service Accounts and regular user accounts through the Service Principal Name.
Enter Kerberoasting: How these attack works
In Kerberoasting, a user account controlled by an attacker requests a service ticket using the Service Principal Name. That service ticket is encrypted using the password of the associated Active Directory account. The service ticket is then dumped out of memory and taken offline (several bits of software, such as Mimikatz, operating without system privilege can do this). Software (such as hashcat) is used to try millions of different passwords, and the software then knows when there is a password match because the service ticket is able to be decrypted and read. The attacker then knows the password for the account associated with the service principal.
Kerberoasting needs a couple of things to be successful:
Reduce your AD attack surface.
- The password that the account with the service principal is using should be less than 25 characters. This rules out computer accounts and managed service accounts because they each have very long passwords that rotate frequently. It simply wouldn’t be possible to do that much guessing before the password rotates in Active Directory. This leaves only user accounts.
- The attacker needs to be able to request the service ticket using the RC4_HMAC_MD5 encryption type. This encryption type leverages the account password in a way that is insecure compared to stronger encryption types based on AES.
Why attackers love kerberoasting
But even with these limitations, attackers love Kerberoasting for the following reasons:
- It doesn’t take any specific existing privilege to perform the attack – ANY authenticated user can perform a Kerberoasting attack. The mail room intern’s account is just as dangerous as the CTO’s!
- Any authenticated user can figure out accounts that might be vulnerable to Kerberoasting. Any user can see user accounts that have a service principal name associated with them, any user can see the password age of an account.
- Most Active Directory environments have been around for a long time and most organizations are loathe to modify Active Directory in a way that might impact the organization. It is common to find users that are running powerful services whose passwords haven’t changed in a long time.
- Even for Active Directory environments that have RC4 disabled, an attacker can still request a service ticket using RC4_HMAC_MD5!
- Kerberoasting leaves few traces in an environment – the attacker doesn’t have to actually try to access the service, it just needs to request the service ticket from the Ticket Granting Server (the domain controller, remember) which doesn’t follow up with the actual service to see if it is ever used!
- Brute force attacks against service tickets can make use of consumer grade GPU hardware with strong year-over-year performance increases – meaning that more complex passwords can be cracked in less time. A completely random seven-character password with full character complexity can be cracked in a matter of minutes – and seven-character passwords are the default in Active Directory environments.
- Longer, truly random passwords take exponentially longer to crack – for example a 10-character truly random password with full complexity would take years. However, attackers can take advantage of the fact that many passwords that we THINK are random are not actually that random. They can use “masks” and “rainbow tables” to abuse how humans actually create passwords to dramatically reduce that time.
Foiling the Kerberoast: Steps to prevent Kerberoasting attacks
So, given all this, as an Active Directory defender what can you do to prevent attackers from leveraging Kerberoasting to attain the password of a powerful service account?
Here are three best practices:
- Look at your Active Directory environment the way an attacker would. Look for accounts that are susceptible to Kerberoasting by finding the intersection between users that have a Service Principal Name, an older password, and plenty of privilege.
- You can find these particularly vulnerable accounts using PowerShell queries, reporting or vulnerability analysis systems, or even powerful attack path management software like Bloodhound Enterprise.
- When you find these vulnerable accounts, you may choose a few different approaches. If you can, convert the service to use a computer account or a managed service account. If the service does not support either of those two options, consider leveraging a privileged information manager (PIM). These types of systems automate regular cycling of service passwords using long, truly random passwords. And if that is not available to you, manually rotate these passwords on a regular basis using long, complex, truly random passwords – starting with the ones with the oldest passwords and the most privilege.
- Finally, look for and alert on service tickets being generated with the RC4-HMAC encryption type. This may mean that you are being kerberoasted! Domain controllers will include this information in Event 4796, under the field “Ticket Encryption Type. The Hex code for RC4 will be 0x17. You can enable these events by enabling Audit Kerberos Service Ticket Operations in the Advanced Audit Configuration for your domain controllers – but be warned this will generate a very high number of audit events. Plan to use a SIEM or other event log analysis system to return only events for RC4 service tickets.
- Alternatively, consider leveraging change auditing software that combines the ability to audit RC4 encryption types, whitelist-able accounts, and real-time alerting without needed to audit every service ticket and operation.
Conclusion
I hope that you’ve left this blog post with a clearer understanding of Kerberoasting than you had going into it. And, I hope it has given you the tools you need to remove these simple techniques from your attacker’s repertoire.
