Roasting the Three-headed Guard of Active Directory — Kerberoasting

8 min readApr 1, 2021

This attack targets the Kerberos Authentication Protocol in an Active Directory environment, and attempts to retrieve the service accounts’ passwords or tickets that can then be cracked offline to reveal cleartext credentials. Kerberoasting has been listed in the MITRE ATT&CK framework as an Enterprise Attack Vector, bearing the ID T1208.

In a nutshell, Kerberoasting has the following steps:

Identify Active Directory accounts with Service Principal Names (SPNs) set.
Request service tickets for the service accounts using SPN values.
Use mimikatz or some other credential dumping tool to get the service tickets.
Crack the service tickets for clear text credentials.

In this blog, we’ll first discuss the basics of the Kerberos Authentication Protocol, and how Active Directory uses SPNs to identify service accounts, where the vulnerability actually lies and then have both theoretical and practical demonstration of the attack vector.

Kerberos Authentication Protocol

Developed by MIT, Kerberos Authentication Protocol is the default authentication mechanism for Microsoft Active Directory. It is named after the three-headed dog (Cerberus) found in the Greek mythology, because the protocol involves three major steps in the entire authentication process. By default, kerberos runs on UDP port 88.

It is a network authentication protocol that works on a client-server model, and uses secret-key cryptography. It works on the principle of granting and requesting tickets to and from different nodes connected on the network to identify themselves.

Components of the Kerberos Authentication Protocol

Kerberos is a third-party authentication scheme consisting of the following two entities. Both of these are collectively called as the Key Distribution Centre (or KDC):

The Authentication Server (AS) which is responsible for the initial authentication of users to access the desired service. It grants the users the tickets that they can use to further authenticate themselves with Active Directory to use the desired service.
The Ticket Granting Server (TGS) which is responsible for the secondary authentication phase and grants access to the user after verification of the ticket, that was issued by the AS.

Authentication Phases of Kerberos Authentication Protocol

The Kerberos Authentication Protocol follows two authentication phases.

Initial Authentication

The user logs onto his workstation, and enters his user ID and password into the client application for the service he desires to access. The application encrypts a timestamp with the user’s password and sends it to the AS, along with the UID. The AS looks for the password in its principal database that matches the UID and decrypts the received encrypted timestamp using the password. It then generates a Ticket Granting Ticket (TGT) and encrypts it using the user’s password, and sends it back to the user’s workstation. The encrypted TGT consists of the actual TGT and the session key. The client application upon receiving, decrypts it using the user’s password. The user now has the TGT, and he can further authenticate himself with the TGS and get access to the desired service.

Secondary Authentication

After receiving the TGT, the client application sends the TGT over to the TGS along with the Service Principal Name (SPN) for the service that the user wants to access, to get the Service Granting Ticket (ST). The TGS verifies the TGT with the AS for active sessions , and after verification sends the ST to the client application. The client application then sends the ST to the service application running on the server, the server verifies the ST with the TGS and after verification grants access to the user to access the desired service.

Service Principal Names (SPNs)

“A service principal name (SPN) is a unique identifier of a service instance. SPNs are used by Kerberos authentication to associate a service instance with a service logon account. This allows a client application to request that the service authenticate an account even if the client does not have the account name.”

In an Active Directory environment, a service is anything that is shared and can be accessed and used by the nodes of the AD. It can be a network file share, a printing service, a web server etc. The same service can be run on multiple hosts within the AD, but each service must have a specific and unique identifier for its host. This unique identifier is called a Service Principal Name or an SPN. When a user wants to connect to and use a service, he must first provide the SPN at the time of authentication.

Naming Conventions for SPNs

An SPN must be unique in the forest in which it is registered, otherwise the authentication might fail. The syntax for an SPN consists of the following four attributes:

Service_class which identifies the general class of the service
Hostname: hostname of the computer object on which the service is installed, can be a fully qualified DNS name or a NetBIOS name
Port: the port on which the service is running, if the service is running on some port other than the default port, or if the service is a replicable service
Service_name: a name that uniquely identifies the service in case of replicable services.

Generally, the usual syntax for an SPN is as follows:

<service_class>/<hostname>:<port>/<service_name>

Host-Based Services

For host-based services, the port and service_name are not required as the service_class coupled with the hostname is enough to uniquely identify the service. Therefore, the syntax for host-based services is as follows:

<service_class>/<hosname>

Or in case the service uses port other than the default, the syntax becomes:

<service_class>/<hostname>:<port>

Replicable Services

For replicable services, there are multiple instances of the same service, therefore the service_name is also required to uniquely identify the service, so that the client may only connect to the desired instance of the service. Therefore, the syntax becomes:

<service_class>/<hostname>:<port>/<service_name>

Kerberoasting

Where the vulnerability lies?

As discussed above, Kerberos uses shared secrets for authentication, and the user’s password is used to encrypt everything. In a Windows environment, the only available hash format is NTLM, therefore cracking the ticket also becomes relatively easy. Also, from the communication that happens during the authentication phases, it is evident that the KDC does not verify that the user requesting the ST has permissions to access the service or not, therefore if an attacker manages to identify the service accounts, or get the SPNs for the domain user accounts that are also service accounts, he can very easily request the TGT from the AS and then present that AS to the TGS to get the ST which he can crack offline, and get the cleartext password for the service account.

Theoretical and Technical Demonstration

The only prerequisite for successful execution of the attack is a Domain User account in the Active Directory.

Let’s take up on the Assumed Breach methodology and assume that the adversary has compromised the network and has access to a domain user in the AD.

The attacker uses the setspn.exe to identify the user accounts that have SPNs. Similarly, this can also be achieved using PowerSploit’s PowerView.ps1 script, the PowerShell version of Microsoft’s signed Active Directory module and the Impacket-toolkit’s GetUserSPNs.py script etc.

Once the attacker has identified the SPN, he then uses that SPN and requests the KDC for the TGT and then the TGS. Since Kerberos does not take into account the user’s privileges and permissions, this does not create any problems for the attacker. The attacker then uses some credential dumping tool like mimikatz or PowerSploit’s Invoke-Kerberoast.ps1 script to pull the service tickets from the memory and ultimately uses a hash cracking tool like hashcat to crack the service tickets offline on his attacking machine to get the cleartext credentials for the service accounts.

Practical Demonstration

The attacker has compromised the network and has access to a windows machine in the target network. He uses ‘setspn’ to list all the available SPNs in the domain. He gets the SPN of SQL Service.

Then he requests the service tickets from the KDC. Kerberos as usual does not check if the user has permissions to request the ST, but since the attacker has access to the domain user, all goes well, and the ST gets stored in the memory.

The attacker then uses mimikatz to extract the service tickets from the memory.

Following are all the service tickets that mimikatz extracted from the memory.

The attacker then transfers these tickets to his attacking machine, where he can crack these service tickets offline, and off the network.

Using python script ‘kirbi2john’ the attacker first converts these extracted service tickets into a form that his hash cracker John The Ripper can understand. Using John and the rockyou.txt wordlist, he successfully cracked the ST and gets plaintext password for the SQL service account.

This can also be done using the GetUserSPNs.py script from the Impacket-Toolkit, if the password of the compromised Domain User is known.

Similarly, as done previously, this ticket can be cracked off the network.

Detection and Defense

Enabling Audit Kerberos Service Ticket Operations logs TGS requests for service tickets. Specifically Log ID 4769 shows the service access being requested.

To mitigate against the attack, ensure strong and complex password policies, and limit service accounts from higher privileges including adding them into the Administrative groups. Also, consider implementing AES or more complex encryption rather than the conventional RC4 encryption.