A Quick Dive Into Kerberos
Before we get into Kerberoasting, we need to get a brief understanding on how the authentication protocol “Kerberos” works in a Windows environment. Let us do this by taking a closer look at a domain user accessing a service.
Note that this is a simplified version.
- A user logs on to a domain joined computer using username and password. The password is converted into a NTLM hash and a Ticket Grating Ticket (TGT) is requested to the Key Distribution Center (KDC, normally the Domain Controller).
- The Domain Controller (KDC) verifies the NTLM hash and sends back a TGT. The TGT is signed and encrypted by the Domain Controller.
- The user sends back the TGT and requests a Ticket Granting Service (TGS) for a specific service. The Domain Controller verifies the TGT by checking the signature and the encryption.
- The TGS is encrypted using the service accounts NTLM password hash and sent back to the user.
- The user sends the TGS to the server hosting the service. The service validates the TGS using its own NTLM hash password and checks if the user is authorized.
An Attacker’s Point of View
Let us assume your organization is breached. A user clicked on a phishing email and installed malware or a threat actor somehow obtained a user’s credentials.
From just being a normal domain user, an attacker can now start to kerberoast the service accounts. By asking the Domain Controller for ALL service accounts with a Service Principal Name (SPN) associated with it, the Domain Controller will now provide the attacker with a TGS for all of those accounts, since a valid TGT was used. Note that the compromised user does not need to have access to these services. The authorization part is being done when the TGS is presented to the server hosting the service, as we can see in step number 5. It also does not matter if the service is installed on a server behind a fancy firewall, since there is no communication with the server, only with the Domain Controller.
The attacker now has a handful of TGSs, and they are all encrypted using the NTLM password hash of the service account. By extracting the hashes, an attacker can now fire up his crack station and run extensive brute-forcing or wordlist attacks. Commonly, at least one of the service accounts uses a weak password and is running with high privileges. This makes it possible for a threat actor to dump the credentials of other logged on users and keep on moving laterally, or even worse, the service account is a member of the Domain Admin group giving them full access to the whole domain.
How to Mitigate Kerberoasting
Detecting Kerberoasting or preventing the TGSs from getting in the hands of a threat actor can be hard to do. However, there are a few steps you can take to mitigate this type of attack.
The first step would be to use built-in accounts instead of domain accounts whenever possible. It would then use the machine account, which has a long and complex password that is being rotated periodically. Commonly, a service does not need to run with a domain account, and therefore it should not. Whenever that is not possible, a long and complex password should be used. Microsoft recommends using Group Managed Service Accounts (gMSA). Not only does it enforce a strong password, you also have the option to automatically rotate the password. This will make it very unlikely for a threat actor to be able to brute force such a long and complex password within a short time.
Furthermore, increasing the encryption level from RC4 to AES-256 is possible. AES encryption is stronger and will take significant longer time to crack. The problem with enabling AES encryption on service account is that a threat actor still has the possibility to downgrade to RC4. However, it is noisier and could allow for closer monitoring of potential kerberoasting activities, by looking at TGS requests with downgraded encryption level. Another solution for this would be to disable the use of RC4 in the whole domain. This would make it impossible to downgrade to RC4. Although, this can cause problems, since a lot of legacy systems rely on RC4 and does not support AES encryption. So be careful with disabling RC4 encryption in a production environment.
Conclusion
Kerberoasting is a relatively stealthy and efficient way of escalating privileges. From just being a normal domain user, without any extra privileges, a threat actor has the possibility to crack service account’s passwords offline. Potentially ending up with high privileges and obtaining sensitive data. However, it is also relatively easy to protect against. By making sure built-in accounts are being used as much as possible. Whenever that is not possible, make sure you use long and complex passwords for all your service accounts, so that they are not easily crackable. Whenever possible, aim for implementing gMSA to easily be able to manage and rotate passwords.
Want to Learn More?
Check out our free webinar Truesec Tech Talks, streaming every Friday (Normally in Swedish). A 30 minute presentation including demos and recommendations on how you can strengthen your IT environment.