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.
Why does this happen?
The reason all users can request tickets for services, even those they don’t have permission to access, is due to the design of the Kerberos authentication protocol. When a client requests a service ticket, the Key Distribution Center (KDC) doesn’t perform an access control check at that stage. Instead, access control is enforced when the client presents the service ticket to the requested service.
Kerberos assumes that the service will handle the access control and determine whether the client should be granted access. This design choice was made to offload some of the access control responsibilities from the KDC to the individual services, making the overall authentication process more efficient.
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:
- 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.
- 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.
- 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.
- 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-GetUserSPNs -dc-ip 10.50.50.50 training.local/joe.smith -request
crackmapexec ldap 10.50.50.50 -u joe.smith -p Password1 –kerberoasting kerberoastables.txt –kdcHost 10.50.50.50
Rubeus.exe kerberoast /outfile:kerberoastables.txt
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.