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

Kerberos Logo

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.

  1. Identify domain accounts having an SPN set
  2. Filter out any computer accounts, which have machine-generated passwords
  3. Request service tickets for the remaining user accounts
  4. Use Mimikatz to dump the service tickets to disk
  5. 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.


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

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.

Dump tickets

Mimikatz writes the ticket to a *.kirbi file, from which the hash can be cracked. Cracking is done with, 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.