Kerberoasting - Exploiting Kerberos to Compromise Microsoft Active Directory

Blog post 28 November 2019, by Geert Smelt, Security Specialist at Secura

Blog alleen in het Engels beschikbaar

Within a Microsoft Active Directory (AD) environment, penetration testers have many types of attacks at their disposal. A few examples include relaying authentication, cracking password hashes and exploiting vulnerable services. Within an AD-environment, the Domain Controller (DC) governs the domain, imposing a ruleset with respect to aspects such as password strength, execution of programs and access to shared files. Authentication and authorisation is controlled by the DC by means of the Kerberos protocol. This protocol was developed at MIT and Microsoft has implemented and adapted it for use within the AD environment starting with Windows 2000. It is a complex protocol that makes use of cryptographic signatures, strong encryption, one-way hash functions and trust relations. Because of this complexity it has become difficult to implement securely.

In this blog post we shall be detailing several types of attacks that an attacker can perform against the protocol itself, known as Kerberoasting - a term first introduced by Tim Medin of the SANS Institute.

About Kerberos

Since Kerberos is a complex protocol it is important to get a good idea of how it works before describing the weaknesses in it. Before going into detail, a real-world example is given.

Consider the process of booking a flight for instance. You create an account on a web site and log in. You then pay for your tickets and obtain your boarding pass and finally you go to the gate and present the boarding pass.

Using the above scenario, we illustrate accessing a service in an active directory environment, such as a SQL Server database. Kerberos is the protocol that governs the authentication process. Let's say you would like to access a certain record within a SQL Server database. The authentication process for this scenario is as follows (see the schematic overview below). The first step (1) is to authenticate yourself to the Authentication Service (AS) within the Key Distribution Center (KDC) by proving your knowledge of a shared secret, i.e. your user password hash (equivalent to creating an account on the ticket website). This is done by encrypting a timestamp using your password hash. If the password hash is correct the Authentication Service (AS) part of the KDC will be able to decrypt and verify the timestamp it receives. The KDC will subsequently provide you with a ticket (a so-called Ticket Granting Ticket) encrypted with the password hash of the krbtgt account that enables you to request another ticket (2) (equivalent to logging into the ticket website). With this TGT you return to the KDC and specify the service you wish to access (3) (equivalent to booking a flight). The KDC verifies that it is able to decrypt the ticket using the krbtgt account and that it is correct. The KDC then looks up the service account corresponding to the service requested. Using this service account, a ticket is created that should grant access to the service (a so-called Ticket Granting Service). This ticket is encrypted using the password hash for the service account (4) (equivalent to receiving the boarding pass via email). You can now present the TGS to the SQL Server, which should be able to decrypt and verify it since it has knowledge of its own password hash (5) (equivalent to shoing the boarding pass at the gate). Once the SQL Server decrypts the TGS and verifies it, it will grant you access and you can read the requested record from the database (6) (equivalent to being granted entry to the airplane). Note that the actual authorisation is done by the service, not the KDC. The KDC merely verifies that the user is registered with the domain (authentication).

Classic Kerberoasting

Kerberoasting is the technique where service accounts are targeted and their passwords are cracked. A service account is an account for which the Service Principal Name (SPN) is set. This SPN needs to be unique within the domain, but the corresponding service does not need to be available or even exist. Service accounts can be either a computer account or a user account. Users are notoriously bad at choosing secure passwords, so Kerberoasting targets the latter. The general Kerberoasting attack is done as follows.

Identify domain accounts having an SPN set
Filter out any computer accounts, which have machine-generated passwords
Request service tickets for the remaining user accounts
Use Mimikatz to dump the service tickets to disk
Crack service tickets using your preferred hash cracking tool

Creating SPNs for Kerberoasting

A variation of the classic Kerberoasting attack is a special case. If an attacker with a domain user account is able to manipulate another domain user account's properties, then this can be leveraged to forcibly set an SPN on it and request a ticket encrypted with the target user's NTLM hash. In order to be able to perform such an action the GenericAll or GenericWrite permissions need to be granted to the attacker's account, which is by default not the case.

The SPN set by an attacker can be arbitrary; it doesn't have to exist within the domain, as long as it follows the right format (service / host). Once the account or group has their SPN set a ticket can be requested, extracted and cracked in the same way as shown for classic Kerberoasting.

Examples

Over the years many software solutions have been developed that aid an attacker in performing Kerberoasting. In the next sections some examples are shown.

Classic
The original method as discovered by Tim Medin was somewhat more involved. It made use of native Windows software such as setspn.exe and klist.exe, to identify SPNs and request tickets respectively. Additionally Mimikatz was required to carve the tickets from memory before the hash could be cracked. Lastly hash cracking software such as Hashcat and John the Ripper did not yet support this format, meaning cracking was done with a (slow) Python script. Below is a demonstration of the manual steps required to successfully crack the service account's password.

Using setspn.exe it is possible to search a domain and/or forest for accounts that have a Service Principal Name configured.

This query yields several results, of which dbadmin is the most promising. Using klist.exe a service ticket (TGS) is requested from the KDC.

This TGS is now stored in memory. In order to crack the NTLM hash of the dbadmin account, another step needs to be performed. Using Mimikatz the ticket can be carved from memory and dumped onto disk.

Mimikatz writes the ticket to a *.kirbi file, from which the hash can be cracked. Cracking is done with tgsrepcrack.py, a script written by Tim Medin to demonstrate the attack during his talk at DerbyCon 2014.

This concludes the classic Kerberoasting attack path. In the past few years this process has been improved significantly, as shown in the next examples.

PowerView
PowerView is a reconnaissance module that ships with PowerSploit. It is a collection of PowerShell, .NET and WMI methods that allow easy enumeration of a corporate domain. With it also comes the ability to perform Kerberoasting with the Invoke-Kerberoast PowerShell method. This method was developed based on the work of Matan Hart (@machosec) and allows the attacker to carve the Kerberos ticket out of memory from within PowerShell. It therefore is no longer necessary to use Mimikatz and as a result lowers the detection rate.

Above is a screenshot of the use of PowerView to obtain a hash of a service ticket for a Windows SQL Server instance in the domain. This hash can subsequently be cracked (offline) with Hashcat.

Rubeus
Rubeus is a C# toolset for raw Kerberos interaction and abuses. It is heavily adapted from Benjamin Delpy's (@gentilkiwi) Kekeo project and Vincent Le Toux's (@mysmartlogon) MakeMeEnterpriseAdmin project.

Although written in C# instead of PowerShell, Rubeus is equally capable of performing Kerberoasting, and can do many more things with respect to Kerberos, such as forging tickets.

Just like PowerView Rubeus also prints the hash for the service tickets, allowing for (offline) cracking of the corresponding user password.

AS-REP Roasting

A technique that was not discovered until recently is called AS-REP Roasting. This technique is similar in nature to Kerberoasting, but instead of attacking the TGS it targets the TGT supplied by the KDC. This attack is rarely useful in practice, since it requires that domain administrators disable Kerberos preauthentication for accounts - a setting that is enabled by default. There are some edge cases however, such as certain older versions of Cisco VPN software that have trouble integrating with Kerberos otherwise. Another case is when you have GenericWrite / GenericAll privileges over a target user similar to setting SPNs manually. This allows you to forcibly disable Kerberos preauthentication for that particular user.

Should you happen to encounter such a user however, you can use AS-REP Roasting to obtain a TGT on behalf of the target user. Since a portion of a TGT is always encrypted using the password hash of the user, it is possible to crack the ticket and obtain the password for the target account, similar to the original Kerberoasting technique.

Note that this technique is quite similar to first setting an SPN on the target account: both require you to be able to change the properties of your target account. The difference is in the type of Kerberos message that is being targeted.

Currently PowerView does not have an option to perform AS-REP Roasting, but Rubeus does.

After obtaining the hash it can once again be cracked offline using Hashcat. Note that it is a slightly different hash type.

It is therefore possible to crack the password belonging to a domain account without having access to a domain account yourself. Note that this scenario is not very prevalent and is mostly used for some VPN software that has trouble integrating with AD.

Detection

Detection of this type of attack can be very hard. The main reason for this is that requesting tickets from a domain controller for authentication is in itself considered legitimate traffic: it is what a domain user is supposed to do in order to perform tasks related to service accounts. It can be detected however, if an attacker is not careful and requests a large number of tickets at once. Generally you will want to enable auditing of Kerberos service ticket operations to log Kerberos TGS service ticket requests. Particularly investigate irregular patterns of activity (ex: accounts making numerous requests, Event ID 4769, within a small time frame, especially if they also request RC4 encryption. Additionally investigate events 4738 and 5136 for anomalies with respect to the use of ASREP Roasting.

Rubeus

As already demonstrated Rubeus can be used for a variety of Kerberos attacks. Rubeus also takes OPSEC into account, which translates into a number of settings that can be enabled. For example, using research from Benjamin Delpy, Rubeus is able to request only RC4 Kerberos tickets, while at the same time preventing caching of those tickets on the attacker-controlled host. For more information about the OPSEC considerations please see Will Schroeder's (@harmjoy) presentation at DerbyCon 2019.

Detection & Mitigation

Detection of Kerberoasting attacks inside your corporate network is best done by EDR software that searches for the issuance of Kerberos tickets encrypted with RC4, i.e. NTLM hashes. Additionally it is important to monitor for large volumes of tickets being requested in a relatively short time period. Anomalies such as this could indicate an attacker requesting tickets for all SPNs in your corporate network. Finally Kerberoasting can be detected by looking for systems that have an unusually large number of Kerberos tickets stored in memory (although we have seen that some tools take that into account too).

Mitigating Kerberoasting is a low effort high gain step toward a more secure corporate network. The MITRE ATT&CK framework for example shows there are essentially three techniques that can be employed to do so.

Better encryption schemes
Complex password policies
Principle of least privilege

Encrypt Sensitive Information

Enable AES Kerberos encryption (or another stronger encryption algorithm), rather than RC4, where possible. AES is the default since domain functional level 2008 and later.

Policies

Ensure strong password length (ideally 25+ characters) and complexity for service accounts and that these passwords periodically expire. Also consider using Group Managed Service Accounts or another third party product such as password vaulting.

Account Management

Limit service accounts to minimal required privileges, including membership in privileged groups such as Domain Administrators.

Tools

In the examples shown in this article the following tools were used.

Other Kerberoasting tools not shown include: