Rethink Security


security hacking windows

Estimated reading time: 4 minutes

Definition: Kerberos

Kerberos (/ˈkɜːrbərɒs/) is a computer-network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner.1

There is also the MIT version of Kerberos, but it’s slightly different than the Microsoft2 implementation.3

Kerberos is also the three headed dog who guards the entrance to the underworld in greek mythology.4

Kerberos Process

The client authenticates itself (AS_REQ) to the Authentication Server (AS). The AS then forwards the username to the key distribution center (KDC). The KDC issues a ticket-granting ticket (TGT), which is time stamped and encrypted using the ticket-granting service’s (TGS) secret key. The encrypted result is then returned to the client (AS_REP).

When the client needs to communicate with a service on another node/principal, the client sends the TGT to the TGS (TGS_REQ), which usually shares the same host as the KDC. The service needs to be registered with the TGS with a so called Service Principal Name (SPN). The client uses the SPN to request access to this service.

After verifying that the TGT is valid and that the user is permitted to access the requested service, the TGS issues ticket and session keys to the client (TGS_REP). The client then sends the ticket to the service server (SS) along with its service request (SS_REQ).

Process of the kerberos protocol
Procedure: Client requests a ticket for a service

Purpose of Kerberoasting

The purpose of Kerberoasting is simple: Offline cracking of password for service accounts.

The advantages are clear:

  • Passwords can be cracked offline => No failed logins
  • As any user
  • Without being a local administrator


  1. The attacker compromises the account of a domain user. This can be done with various methods like phishing. The user doesn’t need to be a high value target (i.e. account with administrative privileges). With this user the attacker authenticates to the domain.

  2. After authentication, the compromised user will receive a ticket granting ticket (TGT) from the KDC which is signed by its KRBTGT service account in Active Directory (see: Reqesting a ticket).

  3. Now the attacker requests a ticket for the service he wants to compromise. The domain controller will retrieve the permission from the Active Directory database and will create a TGS ticket, which will be encrypted with the password of the service. Since only those two entities share the secret, they are the only ones who can decrypt it.

  4. The user gets the service ticket from the domain controller which is then presented to the service, which will decrypt and determine whether the user has been granted permission to access it or not. At this point, the attacker may extract the ticket from the system memory, and tries to crack it offline.

  5. Offline cracking can be done with tools like john5 and hashcat6. Toolsuites like Impacket7, PowerSploit8 and also Empire9 contain features which to some automation of requesting service tickets and returning the hashes in suitable formats for offline cracking.

Note that advanced attackers are also very careful about the services they choose to attack. Usually they won’t attack targets such as databases or other critical applications. Instead they may only request a handful of tickets to leave as little traces as possible and lowering their chance of detection. The most interesting services are the ones who are old and forgetten, since they’re likle to have weak passwords, which can be cracked easily offline.

Detection and Mitigation

The Kerberos Network Authentication Service (V5) specified in RFC412010 also considered this attack in its security consideration with the following recommendation:

Because a client can request a ticket for any server principal and can attempt a brute force or dictionary attack against the server principal’s key using that ticket, it is strongly encouraged that keys be randomly generated (rather than generated from passwords) for any principals that are usable as the target principal for a KRB_TGS_REQ or KRB_AS_REQ messages.

The best defence against Kerberoasting is to enforce robust password policies for service accounts. Organizations should enforce complicated passwords or as stated above, should be randomly generated. Further information about good passwords can be read in my old post here.

  1. ( ↩︎

  2. ( ↩︎

  3. ( ↩︎

  4. ( ↩︎

  5. ( ↩︎

  6. ( ↩︎

  7. ( ↩︎

  8. ( ↩︎

  9. ( ↩︎

  10. ( ↩︎