Introduction

Kerberos is a widely used authentication protocol designed to provide secure identity verification in computer networks. Its robust design and ticket-based authentication mechanism make it a cornerstone of many enterprise environments, particularly in Active Directory. In this article, we will dive into the theoretical foundations of Kerberos, explaining its core components, how the authentication process works, and the various vulnerabilities attackers can exploit to compromise its security.

This article is focused on building a solid understanding of the protocol itself and the concepts behind some of the most common attacks, such as AS-REP Roasting, Golden Ticket, Silver Ticket, etc. While we won’t cover how to execute these attacks yet, this theoretical overview will help you understand their concepts.

In future articles, we’ll demonstrate how to exploit these vulnerabilities and provide insights on protecting against them. By the end of this series, you’ll gain both the knowledge and tools to pentest Kerberos-based systems.

What is Active Directory?

Active Directory (AD) is a directory service developed by Microsoft that is used to manage and organize a network's resources, including users, computers, and other devices. It provides centralized authentication, authorization, and configuration management, making it essential for managing security and access in corporate networks. AD operates using a hierarchical structure, which includes domains, trees, and forests, to efficiently organize and maintain networked resources.

What is Kerberos?

Kerberos is a network authentication protocol designed to provide secure communication over an insecure network. It uses a ticket-based system to authenticate users and services, ensuring that both parties are who they claim to be without transmitting sensitive information like passwords over the network. When a user attempts to access a service, Kerberos issues a "ticket" that allows the user to prove their identity to the service without needing to re-enter their credentials. This method of authentication helps prevent eavesdropping, replay attacks, and unauthorized access, making Kerberos a widely adopted protocol for securing network resources, especially in environments like Active Directory.

Kerberos plays a crucial role within Active Directory as the primary authentication protocol. When a user logs into a network, Kerberos ensures secure authentication by using a ticket-based system, allowing users to access network resources without repeatedly entering credentials. This integration of Kerberos into AD provides a secure, efficient, and scalable way to manage user identities and access in large-scale environments.

Kerberos uses either UDP or TCP as its transport protocol, both of which transmit data in cleartext. Therefore, Kerberos itself is responsible for providing encryption to secure the communication.

The protocol operates over ports UDP/88 and TCP/88, which should be open and listening on the Key Distribution Center (KDC).

Kerberos components

Kerberos has several components that work together to provide authentication. Let's briefly describe them and their functions:

Client/User: The client is the entity that initiates the authentication process to access a specific service. This could be a human user logging into a system or an application acting on behalf of the user.

Key Distribution Center (KDC): The KDC is the central authority in Kerberos, responsible for managing authentication and ticket issuance. It typically resides on the Domain Controller (DC) and consists of two critical components: the Authentication Service (AS) and the Ticket Granting Service (TGS). Together, they handle the issuance of different types of tickets.

Authentication Service (AS): The AS is the starting point of the Kerberos process. When the client logs in, it communicates with the AS to prove its identity (usually by using a password or a cryptographic key). Once authenticated, the AS issues a Ticket Granting Ticket (TGT). The TGT is like a "master ticket" that the client uses to request access to other services without needing to authenticate again during its validity period.

Ticket Granting Service (TGS): The TGS processes requests from the client for access to specific services. Using the previously obtained TGT, the client asks the TGS for a Service Ticket (ST). This Service Ticket is then presented to the target service to gain access.

Note: Service Tickets are sometimes informally referred to as "TGS Tickets" because they are issued by the TGS, but the correct term is Service Ticket.

Application Server (AP): The Application Server is the end-point service that the client wants to access, such as a file server, database, or email system. It validates the Service Ticket presented by the client, ensuring it is valid and issued by the KDC. Upon successful validation, the Application Server grants the client access to the requested resource.

Encryption Keys in Kerberos

Kerberos uses several encryption keys to secure its tickets and communications, ensuring that sensitive information remains protected from tampering or interception by unauthorized parties. Below is an explanation of the main keys and their purposes:

KDC/krbtgt Master Key: This key is used to encrypt the Ticket Granting Tickets (TGT) and sign the Privilege Attribute Certificate (PAC), a structure that contains user authorization data (we’ll introduce this in detail later). This key is derived from the NT hash of the krbtgt account in the Active Directory.

User/Client Master Key: This key is used by the user to authenticate to the Authentication Service (AS) when requesting a TGT. It also encrypts specific structures, such as the user's part of the TGT. This key is derived from the user's NT hash.

Service Master Key: This key is used to encrypt the Service Tickets issued by the Ticket Granting Service (TGS). The service key is derived from the NT hash of the account that owns the service, which could be either a user account or a computer account in Active Directory.

NOTE: The NT hash of an account is the password stored in a hashed format. It is created by encoding the plaintext password in UTF-16LE and then hashing it using the MD4 algorithm. This hashed value is used in the NTLM authentication protocol, where it is compared to the stored hash during authentication. Kerberos also uses this format for password-based authentication, although it typically works with different keys and encryption methods.

Session Key: A Session Key is a temporary symmetric key shared between the client and the KDC or a service. It is embedded in the tickets and used to encrypt communication between the client and other parties, such as the Application Server (AP). Each TGT includes a Session Key shared between the client and the KDC's TGS component, ensuring secure communication when requesting Service Tickets.

Service Session Key: This is a specific type of Session Key shared between the client and the service (Application Server) that the client wants to access. The Service Session Key is included in the Service Ticket, encrypted with the Service Key so that only the intended service can decrypt it. The client uses this key to establish secure communication with the service once access is granted.

TGTs and STs

In Kerberos, tickets play a fundamental role in authenticating users to services or the KDC. These tickets ensure secure communication and authorization without transmitting user passwords over the network. As mentioned earlier, there are two main types of tickets: TGTs and STs.

• TGT (Ticket Granting Ticket): The TGT is issued by the Authentication Service (AS) of the KDC and is used by the client to request a Service Ticket (ST) from the Ticket Granting Service (TGS). It essentially allows the user to prove their identity to the TGS without needing to re-enter credentials. The TGT is encrypted with the KDC master key, ensuring only the KDC can decrypt and validate it.

  
  

• ST (Service Ticket): The Service Ticket is issued by the TGS based on a valid TGT and allows the user to authenticate directly to the service they want to access. The ST is encrypted with the Service master key, so only the targeted service can decrypt and validate it.

  
  

Privilege Attribute Certificate (PAC)

The Privilege Attribute Certificate (PAC) is a critical component in Kerberos authentication that contains authorization information about the user. This includes details such as:

• The user's security identifiers (SIDs), representing their account and group memberships.
• Privileges or roles assigned to the user.
• Other relevant attributes required for access control.

The PAC is embedded within Kerberos tickets, specifically the TGT and ST, and helps services determine what actions a user is allowed to perform once authenticated. To ensure its integrity, the PAC is signed by the KDC master key. While services can validate the PAC by verifying its signature with the KDC, this validation is not always enforced. If an attacker manages to tamper with the PAC (e.g., during a Silver Ticket attack) and the service does not verify its integrity, the attacker could impersonate any user or modify their privileges, potentially gaining unauthorized access or elevated permissions.

Kerberos Messages

Kerberos communication involves several types of messages, each serving a specific purpose in the authentication process. The most notable ones include:

• KRB_AS_REQ: Sent by the client to the KDC's Authentication Service (AS) to request a Ticket Granting Ticket (TGT).
• KRB_AS_REP: Sent by the KDC's AS to deliver the requested TGT to the client.
• KRB_TGS_REQ: Sent by the client to the KDC's Ticket Granting Service (TGS) to request a Service Ticket, using the TGT for authentication.
• KRB_TGS_REP: Sent by the KDC's TGS to deliver the requested Service Ticket to the client.
• KRB_AP_REQ: Sent by the client to the service the user wants to access, to authenticate using the Service Ticket.
• KRB_AP_REP: (Optional) Sent by the service to authenticate itself back to the client, ensuring mutual authentication.
• KRB_ERROR: Used to communicate error conditions encountered during the authentication process.

Additionally, while not part of the core Kerberos protocol, the service may optionally send a KERB_VERIFY_PAC_REQUEST message (part of the Microsoft Netlogon Remote Protocol, NRPC) to the KDC. This message contains the PAC signature, allowing the KDC to verify its validity and ensure the PAC has not been tampered with.

Kerberos Authentication Flow

Now that we have a solid understanding of the key concepts behind Kerberos authentication, let's describe the authentication flow. In this section, we'll explain the steps involved in how Kerberos allows a user to connect to a service, i.e., the sequence of messages, starting from a user without tickets and ending with authentication against the desired service.

1. KRB_AS_REQ

Initially, the user who wants to access a service, must obtain a TGT from the AS. It does it so by sending a KRB_AS_REQ message to the KDC.

Let’s break down the key components of the KRB_AS_REQ message:

• Timestamp: The current date and time of the request, encrypted with the user's master key. It verifies the user’s knowledge of their password and protects against replay attacks by rejecting outdated timestamps. A small tolerance is allowed to account for clock differences between the client and KDC.
• Username: Identifies the user requesting the TGT.
• krbtgt SPN: Specifies the service principal name of the KRBTGT account, indicating the ticket's intended purpose.
• User Nonce: A randomly generated value included by the client to ensure freshness and prevent the reuse of KDC responses.

While the KRB_AS_REQ can contain additional fields, these are the most important for understanding its role in the authentication process.

2. KRB_AS_REP

Upon receiving the KRB_AS_REQ message, the KDC processes its content. First, it verifies whether the username exists in the Active Directory. If the user is found, the KDC retrieves the associated NT hash and attempts to decrypt the Timestamp included in the request. If the decryption is successful, it confirms that the Timestamp was encrypted using the correct NT hash, which means the user knows their password—or at least possesses the necessary credentials. Once this verification is complete, the KDC generates a TGT and delivers it to the client within a KRB_AS_REP message.

The KRB_AS_REP message contains the TGT, which is a critical component in the Kerberos authentication process. Let’s explore its content:

• Username: Identifies the user who requested the TGT.
• TGS Session Key/Session Key: A unique session key generated by the KDC for secure communication between the client and the TGS. This key plays a vital role in the next step of the authentication process. When the client later requests a Service Ticket (ST) from the TGS, the Session Key is used to encrypt and validate the Authenticator included in the request. This ensures that the request originates from the user who owns the TGT, further reinforcing authentication security.
• TGT Expiration: Specifies the lifetime of the TGT, including the issue and expiration times. The expiration ensures that tickets are only valid for a limited period, reducing the risk of misuse if intercepted.
• PAC (Privilege Attribute Certificate): Describes the user’s permissions and group memberships. The PAC is signed by the KDC’s master key to protect its integrity. While verifying the PAC signature is optional, it provides a mechanism for ensuring that the PAC has not been tampered with.

The entire TGT is encrypted with the KDC’s master key (derived from the KRBTGT account's NT hash). This encryption ensures that the TGT’s contents cannot be read or altered by anyone except the KDC or TGS, which possesses the corresponding decryption key.

Within the KRB_AS_REP message, we find an additional structure containing a copy of the Session Key, the TGT Expiration, and the User Nonce provided in the KRB_AS_REQ. This structure is encrypted using the User Master Key.

Why is this second structure included? As mentioned earlier, the Session Key plays a critical role in securing the communication process. It is used to encrypt the Authenticator, a structure included in subsequent requests to prevent replay attacks. Given that this structure is encrypted using the User Master Key, the user can decrypt it and then extract the Session Key for future usage.

When the TGS receives the request, it decrypts the TGT using the KDC Master Key, extracts the Session Key, and uses it to attempt decryption of the Authenticator. If the Authenticator is successfully decrypted, it confirms that the user possesses the Session Key. Finally, the TGS validates the information within the Authenticator to ensure the integrity of the request.

We'll delve into the Authenticator in the next section.

3. KRB_TGS_REQ

Upon recieving the KRB_AS_REP message, the user now possesses a TGT, which is essential for the next step in order to ask a Service Ticket. Moreover, the user also recieves the second structure which contains the Session Key, as it's encrypted with the User Master Key (i.e, the user NT hash), the user can decrypt it and obtain the Session Key, this session key is crucial for the next step.

Now, it's time to request a Service Ticket to the TGS. This is made through a KRB_TGS_REQ:

Now, let's break down the KRB_TGS_REQ message:

Authenticator: The Authenticator is a unique structure created for every request. It contains:

• Username: Identifies the user making the request.
• Timestamp: Indicates when the request was issued. The timestamp is essential for preventing replay attacks. If an attacker intercepts the request and attempts to resend it, the TGS will reject it if the timestamp falls outside the acceptable time range (usually within a 5-minute tolerance to account for clock drift).
• Optional Nonce: A randomly generated number that can further enhance replay protection by introducing uniqueness to the Authenticator, even if the Timestamp is reused within a valid time range.

The Authenticator is encrypted with the Session Key obtained during the previous KRB_AS_REP phase. This ensures that only a user who knows the Session Key can generate a valid Authenticator. The TGS decrypts the TGT (which also contains the Session Key) and uses it to decrypt the Authenticator. If successful, it validates the timestamp and the information provided.

TGT: The Ticket Granting Ticket (TGT) obtained in the previous step is included in the KRB_TGS_REQ. The TGT enables the user to prove their identity without needing to re-enter their password. Since it is encrypted with the KDC Master Key, it remains tamper-proof and serves as a secure method of identity verification.

Service Principal Name (SPN): The Service Principal Name (SPN) identifies the specific service the user wants to access. SPNs are unique to each service and typically follow a format such as:

• LDAP/dc.domain.local
• HTTP/domain.local

An SPN helps the TGS determine which service ticket to issue, as it specifies the intended recipient of the ticket. Note that some services may have multiple SPNs depending on their configuration.

User Nonce: A User Nonce is included in the KRB_TGS_REQ message as an additional measure to ensure freshness and prevent replay attacks at the level of the ticket exchange. This is not the same as the optional nonce that can be included within the Authenticator, this one has different purposes or at least, a different functionality.

• This User Nonce is a randomly generated number provided by the client.
• It is included in the KRB_TGS_REP response so the client can verify that the response matches its request.
• It also helps synchronize the generation of the session key for the requested service.

4. KRB_TGS_REP

After receiving the KRB_TGS_REQ message, the TGS performs the following steps:

1. Validating the TGT:

   
   
   • The TGS decrypts the embedded TGT using the KDC Master Key.
   • If the decryption is successful, it confirms that the TGT is valid because it was signed with the correct KDC Master Key during its creation.
   • The TGS then extracts the Session Key from the TGT for further validation.
   
   

2. Decrypting and Verifying the Authenticator:

   
   
   • The Authenticator (encrypted with the Session Key) is decrypted using the extracted Session Key.
   • If decryption is successful, it confirms that the user knows the Session Key, which indirectly proves their identity.
   • The TGS also checks the information inside the Authenticator, especially the Timestamp, to ensure the request is recent and prevent replay attacks.
   
   

3. Generating a New Session Key:

   
   
   • If all validations pass, the TGS generates a new Service Session Key.
   • This key will be used for secure communication between the client and the target service.
   
   

4. Creating the Service Ticket (ST):

   
   

   • The TGS creates the Service Ticket (ST), which includes:

     
     
     • Client Information: Such as the username and other details.
     • Service Session Key: The new session key for client-service communication.
     • Expiration Time: The validity period of the ST.
     • PAC: The PAC from the TGT is copied to the ST.
     
     

   • The ST is then encrypted with the Service Master Key.

     
     
     • The Service Master Key is derived from the NT hash of the target service.
     • The TGS identifies the correct service by using the SPN provided in the KRB_TGS_REQ.
     
     
   
   

5. Encrypting the New Session Key for the Client:

   
   
   • A new structure is created containing the Service Session Key, encrypted with the previous Session Key (obtained from the TGT).
   • This ensures that only the user (who knows the previous Session Key) can decrypt it and obtain the Service Session Key.
   
   

6. Finalizing the Response:

   
   
   • The TGS sends back the KRB_TGS_REP message, which contains:
     • The encrypted Service Ticket (ST) for the target service.
     • The encrypted Service Session Key for the client.
     
     
   
   

As observed, the KRB_TGS_REP includes the following information:

• Service Ticket (ST): The Service Ticket generated by the TGS, which will be presented to the target service in the next step for authentication. It contains fields such as the Username, the Service Session Key, the ST Expiration, and the PAC (Privilege Attribute Certificate), which describes the user’s privileges and groups. The entire ST is encrypted with the Service Master Key, ensuring that only the target service can decrypt and validate it.

  
  

• Service Session Key: The generated Service Session Key, which will be used in the next step to securely communicate with the service. This key is included in two forms:

  
  
  1. Embedded in the Service Ticket (encrypted with the Service Master Key).
  2. Encrypted with the previous Session Key obtained from the KRB_AS_REP, allowing the user to extract it securely.
  
  

• Username: The identity of the user requesting the Service Ticket. This is included for consistency and to help the target service identify the user.

  
  

• User Nonce: The User Nonce sent by the client in the KRB_TGS_REQ is echoed back in this response. This confirms that the response is fresh and directly related to the specific request made by the client, preventing replay attacks.

  
  

As observed, the process is similar to the previous steps, in this case changes the type of ticket, but the steps that takes the user is the same.

5. KRB_AP_REQ

After receiving the KRB_TGS_REP, the user extracts and decrypts the Service Session Key included in the response using the previously established Session Key. The decrypted Service Session Key is then saved for secure communication with the target service. The next step involves the user attempting to access the service by sending a KRB_AP_REQ message.

This step is very similar to the KRB_TGS_REQ process, as it uses the combination of a ticket and an authenticator to prove the user's identity and establish trust. However, in this case, the interaction is between the client and the service (not the TGS).

Let's break down the KRB_AP_REQ contents:

1. Service Ticket (ST):

• The ST obtained from the KRB_TGS_REP is included in this request.
• This ticket, encrypted with the Service Master Key, serves as proof that the user has been authenticated by the KDC and is authorized to access the target service.

2. Authenticator:

• The user generates a new Authenticator specifically for this request. Its role is to confirm the user's identity and prove possession of the Service Session Key.


• The Authenticator includes:
  
  
  • User information: Identifies the client making the request.
  • Timestamp: Prevents replay attacks by ensuring that the request is recent.
  • Optional Nonce: An optional nonce can be included to add an extra layer of security.
  
  
• The Authenticator is encrypted with the Service Session Key, ensuring that only the user who possesses the correct key can create a valid authenticator.

Once the service (Application Server) receives the KRB_AP_REQ message, it attempts to decrypt the Service Ticket (ST) using its own Service master key, which is the service's owner NT hash. If the decryption is successful, it indicates that the ST is valid and confirms that it was issued specifically to this particular service.

After successfully decrypting the ST, the AP extracts the Service Session Key from it. The service then attempts to decrypt the Authenticator with this Service Session Key. If the Authenticator decrypts correctly, it confirms that the user knows the correct Service Session Key associated with the ST, which acts as another layer of validation for the user's identity.

Once the Authenticator is decrypted, the service verifies whether the Timestamp is valid. If the timestamp is valid, the service proceeds to grant access to the user. For instance, if the service is a File Server, it might grant the user privileges to read files, list directories, or even write, depending on the permissions specified in the PAC embedded within the Service Ticket.

Additionally, if necessary (though less common), the PAC embedded within the TGT can be validated. This process involves sending a KERB_VERIFY_PAC_REQUEST to the KDC. The KDC re-signs the PAC using the KDC Master Key and checks if the generated signature matches the one provided in the request. This ensures the integrity and authenticity of the PAC data, confirming that it was correctly signed during its creation.

Optionally, if the service requires, it will also send a KRB_AP_REP message. This message serves as a way for the service to prove its identity to the client, completing mutual authentication. It is particularly useful in scenarios where the client must ensure that it is communicating with the legitimate service and not an impersonator. The KRB_AP_REP contains the Service Session Key, encrypted with the same key that was used to encrypt the Authenticator. By successfully decrypting this response, the client verifies that the service possesses the correct Service Session Key, which could only have been obtained by decrypting the Service Ticket using the appropriate Service Master Key.

This step enhances security by ensuring that both parties—client and service—can authenticate each other, which is especially critical in sensitive environments where man-in-the-middle attacks or service impersonation could pose a significant risk.

Ticket cache

When we mention the user extracting tickets and session keys during the Kerberos authentication process, what actually happens is that these structures are stored in a ticket cache, often in the form of ccache files. For instance, upon receiving the KRB_AS_REP message, the user extracts the TGT, decrypts the Session Key using their NT hash, and stores both the TGT and the Session Key in a ccache file. This enables the user to reuse the TGT (as long as it remains valid) when requesting additional Service Tickets (STs).

A similar process occurs with the KRB_TGS_REP message. The user stores the ST and the corresponding Service Session Key in the cache, allowing for the reuse of these structures when accessing the associated service.

By storing these elements in a ticket cache, users can efficiently manage their authentication credentials without needing to repeatedly authenticate with the KDC for every service request, streamlining the authentication process.

Introduction to Kerberos Exploitation

Now that we have a solid understanding of how the Kerberos authentication process works, let’s explore some common attacks that target its mechanisms. In this article, we’ll focus on the theoretical aspects of these attacks, laying the groundwork for a follow-up article where we’ll demonstrate their exploitation in practice.

Kerberos Bruteforce (User Enumeration)

This attack involves sending authentication requests with guessed usernames and observing the responses. Kerberos provides different error messages for valid and invalid usernames. Remember when we were discussing the process the AS does before sending a KRB_AS_REP. Firstly, when recieving the KRB_AS_REQ, we said that it first verifies whether the specified user exists. If it doesn't exist, the KDC_ERR_C_PRINCIPAL_UNKNOWN is sent. So this message is helpful for the attacker when is trying to guess usernames.

AS-REP Roasting

This attack targets users who do not have Kerberos pre-authentication enabled, meaning their account has the UF_DONT_REQUIRE_PREAUTH attribute set.

When an AS-REQ is sent for such a user, the KDC responds with a KRB_AS_REP, which contains the user’s encrypted data (a structure that includes the first Session Key). This data is encrypted using the user’s NT hash and can be brute-forced offline with a large password list to recover the hash—and potentially the password. Essentially, the attacker attempts to decrypt the structure containing the Session Key. If successful, it means the correct user password has been obtained.

Kerberoasting

This attack is similar to AS-REP Roasting, but instead of exploiting the KRB_AS_REP response and the UF_DONT_REQUIRE_PREAUTH attribute, it targets the KRB_TGS_REP response.

To recap, the KRB_TGS_REP contains a Service Ticket, which is encrypted using the Service Master Key (the NT hash of the service owner's account). This attack involves obtaining a Service Ticket and attempting to decrypt it through a password brute-force attack. If the decryption is successful, it indicates that the password for the service owner's account has been compromised.

However, exploiting this is not straightforward. Typically, the owners of services are the machines on which these services run. Since computer passwords tend to be highly complex, attempting to crack them is usually not effective. The same applies to the krbtgt account, which means the TGT (Ticket Granting Ticket) is also not susceptible to cracking through this method.

Golden Ticket and Silver Ticket Attacks

Golden Ticket and Silver Ticket attacks exploit the Kerberos ticketing system, allowing attackers to forge authentication tickets and gain unauthorized access within an Active Directory environment. While both attacks involve crafting malicious Kerberos tickets, they differ in scope and the credentials required to execute them.

A Golden Ticket attack involves forging a Ticket Granting Ticket (TGT). This requires the NT hash of the krbtgt account, which is responsible for signing all TGTs within the domain. Once the attacker obtains the krbtgt hash, they can create a custom TGT with any user identity and privileges, including domain administrator rights. This TGT remains valid even if the user changes their password. The only way to invalidate a forged TGT is to let it expire naturally or to reset the krbtgt account password, which requires careful coordination in the domain to avoid service disruptions.

A Silver Ticket attack focuses on crafting a Service Ticket (TGS) rather than a TGT. To execute this attack, the attacker must obtain the service account’s NT hash, which is derived from the credentials of the service owner. With this hash, the attacker can forge a TGS that grants access to the targeted service without interacting with the Key Distribution Center (KDC). However, a limitation of this attack lies in the Privilege Attribute Certificate (PAC), a component of Kerberos tickets that contains user authorization data. Without the krbtgt key, the attacker cannot sign the PAC correctly. If the targeted service verifies the PAC against the KDC, the attack will fail.

While a Golden Ticket compromises the entire domain by allowing unrestricted impersonation of any user, a Silver Ticket is more focused, enabling access to specific services. Despite its narrower scope, a Silver Ticket is often stealthier, as it bypasses the KDC and avoids generating logs related to ticket issuance.

OverPass The Hash (also known as Pass The Key)

The OverPass The Hash attack allows an attacker to authenticate to Kerberos services without knowing the user’s plaintext password. Instead, the attacker uses the NT hash (a cryptographic representation of the password) to request a Ticket Granting Ticket (TGT) from the Key Distribution Center (KDC).

How it Works:

When a client sends a KRB_AS_REQ message, it encrypts a Timestamp field using the user's NT hash. This encrypted timestamp acts as proof that the client possesses the user's credentials without transmitting the plaintext password. If the KDC can successfully decrypt the timestamp using the NT hash stored in its database, it issues a TGT.

This process inherently uses "Pass The Hash", even when you provide a plaintext password. The client always converts the password into its corresponding NT hash, as Kerberos does not transmit plaintext passwords over the network.

Not Just NT hashes: Other Key Types

Kerberos also supports other encryption keys, such as AES keys, which provide stronger security. To ensure compatibility, the KRB_AS_REQ includes an EncryptionType (etype) field that specifies the algorithm used to encrypt the timestamp. The KDC uses this field to identify the appropriate key type (e.g., NT hash, AES128, or AES256) and attempts decryption accordingly.

The KDC retrieves the user’s credentials from its database, which may include multiple key types (e.g., NT hash, AES128 key, AES256 key). Based on the etype specified in the KRB_AS_REQ, the KDC selects the corresponding key. The KDC attempts to decrypt the timestamp using the selected key. If decryption succeeds and the timestamp is valid, the KDC issues a TGT.

Conclusion

Kerberos is a powerful and widely used authentication protocol, especially in Active Directory environments. Its ticket-based system and use of encryption make it a strong choice for securing networks. However, as we’ve seen, it’s not immune to attacks. Techniques like OverPass The Hash, Golden Ticket, and Silver Ticket show how attackers can exploit access to critical keys or misconfigurations to bypass authentication and compromise systems.

Understanding these attacks is essential for improving security. Regularly rotating sensitive keys (like the krbtgt key), monitoring ticket activity, and protecting accounts can significantly reduce risks. While Kerberos is effective when properly managed, it requires ongoing attention to maintain its security.

This overview provides a foundation for understanding Kerberos and its vulnerabilities. In future articles, we’ll explore these attacks in more detail, focusing on how they are exploited.

I hope you’ve learned something new from this article. Feel free to share the content if you found it helpful.

Happy Hacking!

Joaquín (AKA elswix).

References

https://learn.microsoft.com/en-us/windows/win32/secauthn/ticket-granting-service-exchange
https://learn.microsoft.com/en-us/windows/win32/secauthn/basic-authentication-concepts
https://learn.microsoft.com/en-us/windows/win32/secauthn/authenticator-messages
https://learn.microsoft.com/en-us/windows/win32/secauthn/key-distribution
https://learn.microsoft.com/en-us/windows/win32/secauthn/session-tickets
https://learn.microsoft.com/en-us/windows/win32/secauthn/ticket-granting-tickets
https://learn.microsoft.com/en-us/windows/win32/secauthn/key-authentication
https://www.researchgate.net/publication/353593170_On_Attacking_Kerberos_Authentication_Protocol_in_Windows_Active_Directory_Services_A_Practical_Survey
https://www.tarlogic.com/blog/how-kerberos-works/