Kerberoasting – attacking the three-headed dog

When people log into computers, they typically do so by entering a password. However, the problem with this method is that if someone gets hold of the password, they can pretend to be that user and access sensitive information. This is a big issue, but there’s a solution. Enter the Kerberos protocol, which provides a secure way to authenticate users and keep your systems safe.

How Kerberos Authentication Works

Kerberos relies on symmetric key cryptography and a key distribution center (KDC) to ensure secure authentication 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) issues service tickets based on the initial TGT.

Kerberos flow:

1. Initial Authentication:
   • The user sends a request to the Authentication Server (AS) to obtain a Ticket Granting Ticket (TGT).
   • The AS verifies the user’s identity by checking the provided credentials against the Kerberos database.
   • If the credentials are valid, the AS issues a TGT encrypted with the Ticket Granting Service (TGS) secret key.
2. Request for Service:
   • The user requests access to a service, such as a file server or an application, by sending the TGT to the TGS.
   • The TGS decrypts the TGT using its secret key and verifies the user’s identity.
3. Service Ticket:
   • When the TGS confirms that the user has permission to access the requested service, it generates a Service Ticket encrypted with the service’s secret key.
   • The Service Ticket holds the user’s identity and a session key, that will be used to grant the user access to the service.
4. Service Authentication:
   • The user presents the Service Ticket to the service server.
   • The service server decrypts the Service Ticket using its secret key and verifies the user’s identity.
   • If the authentication is successful, the service server establishes a secure session with the user using the session key provided in the Service Ticket.
5. Access to the Service:
   • The user can now access the requested service, such as a file server or an application, using the established secure session.
6. Ticket Renewal:
   • Kerberos tickets have a limited lifetime, typically 8-10 hours.
   • The user can renew their tickets by presenting the TGT to the TGS, which will issue new tickets with a new session key.
7. Ticket Expiration:
   • When a ticket expires, the user must re-authenticate with the AS to obtain a new TGT.

This is a high-level overview of the Kerberos authentication flow. Additional steps and details are involved in the process, such as ticket encryption, timestamp verification, and ticket forwarding, but this explanation covers the main steps.

What is Kerberoasting, and how it works

Kerberoasting is an exploitation technique similar to AS-REP Roasting that exploits the Kerberos protocol to steal password hashes for Active Directory domain accounts associated with servicePrincipalName (SPN) values. This attack allows any domain user (even without administrative rights) to request a ticket-granting ticket (TGT) for any SPN.

Part of the TGT may be encrypted with the RC4 algorithm using the service account password hash related to the requested SPN as the key. An attacker can then capture the TGT from memory or sniff the network to extract the service account’s password hash and attempt to crack it offline.

By obtaining the TGT, the attacker can choose which SPNs to target based on their likelihood of successful exploitation. This allows them to focus on SPNs encrypted with simpler passwords, making the attack more efficient.

Executing 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.

GetUserSpn

PowerView

LDAP Filter

Once the attacker has identified the SPN to target, they can utilize the following Powershell commands to generate a service ticket.

We’ve now got tickets stored in memory. We’re going to use Mimikatz to extract the tickets from memory. When we run klist, we’ll see the shiny new Kerberos service ticket.

Extract the issued ticket from memory using mimikatz

Now, we should have a .kirbi file in our directory. This is the extracted ticket from Mimikatz.
Normally, we would convert this file into a Hashcat or JohnTheRipper format for a better and faster cracking. For now, we’ll use the tgsrepcrack.py from the Kerberoast project as it can brute-force .kirbi files directly.

During this brute force attack, no communication with Active Directory is needed as it happens offline. This makes it undetectable, unlike the previous steps which should, in theory, be detectable.

After retrieving the unencrypted password, the attacker can login to any system or access data that the account is authorized to. This could result in unauthorized access to sensitive information or the ability to gain higher levels of authorization.

Mitigations and how to prevent Kerberoasting

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

To guard against the compromise of sensitive service account passwords, make sure to create passwords that are hard to guess, with a minimum of 25 characters, and change them regularly. This is a highly effective way to mitigate the risks associated with this type of attack.

Additionally, consider using Managed Service Accounts and Group Managed Service Accounts wherever possible. These accounts automate the process of changing passwords and managing SPNs, reducing the need for manual intervention.

Lastly, it’s important to audit the assignment of servicePrincipalNames to sensitive user accounts. For instance, avoid using members of Domain Admins as service accounts, as they should not have SPNs assigned to them.