Roasting the Three Headed Dog – Kerberoasting

Explaining and roasting the kerberos protocol

When users access computer systems, they do so by entering a password. The challenge with this authentication method is that if someone maliciously obtains the password, he can take on the user’s identity and gain access to an organization’s network. Organizations need a better way to protect their systems and users. This is where the Kerberos protocol comes into play, as it’s designed to provide secure authentication over a network.

How Does Kerberos Authentication Work?

Kerberos uses symmetric key cryptography and a key distribution center (KDC) to authenticate and verify user identities.  

KDC contains the following components:

  • An Authentication server (AS) that performs the initial authentication and issues ticket-granting tickets (TGT) for users.
  • The Ticket Granting server (TGS) that issues service tickets that are based on the initial TGT.

Kerberos flow:

  1. Client by logging in send a request to Authentication server for server access. The request is encrypt with clients password
  2. The Authenticator server retrieves the clients password from the Database based on clients ID and use his password to decrypt the request and then if the user is verified it sends a TGT encrypted with a key which is shared between the Authenticator and the Ticket-granting server (TGS).
  3. The client send the TGT to the Ticket-granting server to request access to the server
  4. The TGS  decrypt the TGT and sends a kerberos token to the client
  5. Client sends request using the kerberos token to the server
  6. finally  the server allows access to the client

When performing Internal Penetration Testing or a Red Team Assessment after the initial compromise, one of the most common and well documented attacks a Pentester will try is Kerberoasting.
Below we are going to explain how this attack works and possible mitigations.

What is Kerberoasting

Kerberoasting abuses traits of the Kerberos protocol to harvest password hashes for Active Directory domain accounts with servicePrincipalName (SPN) values.

Every user of a domain (without administrative rights!) is able to request a ticket-granting ticket (TGT)  for any SPN, and parts of it may be encrypted with the RC4 using the password hash of the service account assigned the requested SPN as the key.

An attacker can extract TGT from memory or by sniffing the network, and extract the service account’s password hash and attempt to crack the offline. By getting the TGT he can decide on which SPN’s the attack could work and which is not worth attacking because they are encrypted with more complex passwords.

Performing the attack

At this point there are many ways that we can list all SPNs in a domain that use user accounts and are therefore suitable for Kerberoasting attacks:

We can use PowerView, GetUserSpn or build an LDAP filter to get the accounts with SPN values registered on the current domain



LDAP Filter

Once the attacker has determined the SPN to be attacked, he can use the following Powershell commands to issue a service ticket:

Now, we have tickets in memory.
We will use Mimikatz to export the tickets from memory.
Running klist shows the new Kerberos service ticket.

The issued ticket can be extracted from the memory using mimikatz :

Now all the extracted Kerberos tickets (with the file extension .kirbi) should be in our directory.
The .kirbi files can be converted into other formats like Hashcat or JohnTheRipper.
We will use the from the Kerberoast project because it can brute-force .kirbi files without converting them.
For a better performance use Hashcat.

Let’s crack the TGS ticket

This brute force attack happens offline, meaning no more communication with Active Directory needs to occur. As a result, this step is undetectable. An attacker may even exfiltrate the list of hashes and use a high-performance system designed just for password cracking. Tools such as hashcat are used to perform the offline brute force attack. Having obtained the plaintext password, the attacker can use the credentials to authenticate to any resources the service account has access to, potentially allowing them to compromise data or escalate privileges.


As we’ve demonstrated, Kerberoasting can lead to the compromise of sensitive service account passwords. However, several mitigations exist that greatly reduce or even eliminate these risks.

  • Service Account Passwords should be hard to guess and have a minimum of 25 characters, and routinely changed. Thats the effective mitigation for this attack.
  • Use where’s possible Managed Service Accounts and Group Manage Service Accounts as it automates password changing and delegated SPN Management
  • Audit the assignment of servicePrincipalNames to sensitive user accounts. For example, members of Domain Admins should not be used as service accounts (and therefore not have SPNs assigned).

Share on social media

Share on linkedin
Share on facebook
Share on twitter

Get A Service Quote

Stay Connected

Test the effectiveness of your security controls before malicious parties do.
We pride ourselves on being unique and thorough.
We understand the need of your organisation and yours too.​

Social & Contact INFO

Drop us a message