A guide to defending against Kerberoasting and what you can do

Author: Jon O’Reilly, Trustmarque Senior Penetration Tester

This is part two of our Kerberoasting cyber security IT blog. In part one we discussed Understanding Kerberos and cyber security which explained the inner workings of the Kerberos authentication process. In this second instalment, we will explore Kerberoasting, what is it, its exploitation techniques, and effective preventive measures. We will walk you through the steps an attacker takes to carry out a Kerberoasting attack and introduce some commonly used tools for ticket requesting and hash cracking.

What is Kerberoasting?

The Kerberos authentication protocol in Windows environments can be exploited by attackers using a technique known as Kerbroasting. In the world of Kerberoasting, attackers target service accounts that have registered SPNs, because these accounts often hold higher privileges, potentially allowing unauthorised access to sensitive information.

Attackers with access to any domain account can request service tickets for any service in the network, this is made possible through the use of Service Principal Names (SPNs).

In Active Directory, a Service Principal Name (SPN) is a special tag that connects a service (like a database or web server) to a specific account that has permission to run that service. This is crucial for Kerberos authentication, which acts like a secure handshake to confirm the identity of the service account.

So, imagine you’re a user who needs to use a particular service, say, a database. With SPNs, you don’t need to know all the nitty-gritty details about the account that runs this database. You just request the service, and behind the scenes, the Kerberos protocol uses the SPN to find the right account, confirm its identity, and grant you a service ticket, which is like a pass, allowing you to access and use the service.

One common mistake is setting up an MSSQL database service to run with domain administrator privileges. Here’s an example, as seen through Impacket’s GetUserSPNs tool:

This example shows valuable information, such as the SPN set to ‘MSSQLSvc’, the server name where the service is running, and the domain user (administrator) the service has been configured with.

Once the attacker identifies a service account with an SPN, they request a service ticket specifically for that SPN. Importantly, the type of encryption ticket requested, such as RC4 or AES, can significantly impact the ease with which the attacker can proceed.

After obtaining the service ticket, the attacker carries out an offline brute-force attack on the encrypted ticket. This involves testing multiple password combinations until they successfully match the encrypted password hash. This type of attack is particularly effective with weaker encryption algorithms like RC4, while stronger encryption types like AES present a more significant challenge.

How the Kerberoasting vulnerability is exploited

Now that we’ve gained a solid understanding of the Kerberos authentication process and the Kerberoasting technique, exploiting this vulnerability becomes relatively straightforward. As previously mentioned, the only requirement for carrying out a Kerberoasting attack is having a user account that can authenticate to the domain.

With a valid user account, an attacker can perform the following steps to exploit the Kerberoasting vulnerability:

1. Enumerate service accounts with registered SPNs within the domain. This can be done using various tools like PowerView, Impackets GetUserSPNs, LDAP queries, raw PowerShell and Rubeus.
2. Request service tickets for the identified service accounts. Since the Kerberos protocol does not perform access control checks at the time of the ticket request, an attacker can obtain encrypted service tickets for any service account, regardless of their permission level.
3. Perform an offline brute-force attack on the encrypted service tickets to crack the password hash. By using powerful tools like Hashcat or John the Ripper, an attacker can try various password combinations to find the correct one.
4. Once the attacker has cracked the service account’s password hash, they can authenticate as the service account to gain unauthorised access to sensitive resources within the network.

Ticket requesting tools

Requesting a ticket is straightforward, and can be achieved with a number of readily available tools, such as:

Impacket

impacket-GetUserSPNs -dc-ip 10.50.50.50 training.local/joe.smith -request

Crackmapexec

crackmapexec ldap 10.50.50.50 -u joe.smith -p Password1 –kerberoasting kerberoastables.txt –kdcHost 10.50.50.50

Rubeus

Rubeus.exe kerberoast /outfile:kerberoastables.txt

pypykatz

pypykatz kerberos spnroast -e 23 ‘kerberos+password://training\joe.smith:[email protected]’  -l ‘ldap+ntlm-password://training.lan\joe.smith:[email protected]’

Cracking the hashes

The hashes can then be cracked offline by using either Hashcat or JohnTheRipper, it is advisable to use a wordlist with rules, for example, rockyou.txt from rockyou.txt.tar.gz found at  https://github.com/danielmiessler/SecLists/tree/master/Passwords/Leaked-Databases/ with oneruletorulethemallstill. https://github.com/stealthsploit/OneRuleToRuleThemStill.

• hashcat -m13100txt $wordlist
• john –format=krb5tgs –wordlist=$wordlisttxt

How to prevent Kerberoasting

To reduce the risks associated with Kerberoasting, consider the following recommendations:

• Adopt a robust password policy for service accounts, incorporating long, intricate, and unique passwords. This will make the cracking of ticket-granting service (TGS) hashes, which attackers may obtain via Kerberoasting, considerably more challenging.
• Conduct periodic reviews and audits of service accounts, ensuring they are properly set up and only possess necessary permissions. Any service accounts that are redundant or underused should be promptly removed.
• Incorporate a least-privilege model, constraining the permissions and privileges of service accounts to what is strictly necessary for their specific roles. This minimises the potential fallout of a successful Kerberoasting attack.
• Enforce strong encryption types such as AES128 and AES256 for Kerberos, effectively eliminating the usage of weak encryption algorithms like RC4 in your environment.

Establish Kerberos logging on all domain controllers, which may not be activated by default. This will help in monitoring and analysing Kerberos logs. The logs generated, including Windows Event IDs 4768 and 4769, can reveal who is requesting Active Directory credentials and tickets. Regular examination of these logs and the implementation of security monitoring and alert systems can flag abnormal Kerberos activities like an unusually high number of service ticket requests or failed decryption attempts. Swift responses to such alerts can mitigate potential attacks.

What you can do

Kerberoasting is a significant vulnerability that attackers can exploit in Windows environments. By targeting service accounts with registered Service Principal Names (SPNs), attackers can potentially gain unauthorised access to sensitive information. However, there are effective preventive measures that you can take to defend against Kerberoasting.

By taking proactive measures to defend against Kerberoasting, you can significantly reduce the risks associated with this vulnerability and enhance your overall security posture. Protecting service accounts and ensuring the integrity of the Kerberos authentication process is crucial for safeguarding sensitive data and preventing unauthorised access.

About the author: Jon O’Reilly is a Senior Penetration Tester at Trustmarque and currently holds CREST Certified Tester Infrastructure (CCT INF), with CHECK Team Leader status in infrastructure.