Kerberos Authentication

Kerberos is the primary authentication protocol used in modern Windows environments. Originally designed by MIT, Kerberos version 5 has been the default authentication mechanism in Windows domains since Windows 2000 and remains fundamental to Active Directory today.

From a red team perspective, understanding Kerberos is critical. Many powerful attacks—such as Kerberoasting, Pass-the-Ticket, and Golden Tickets—exist only because of how this protocol is designed and how trust is delegated inside a domain.

Before Kerberos, Windows relied heavily on NTLM authentication. NTLM is based on a challenge–response model, where the client authenticates directly to the application or service server.

Kerberos changes this model completely.

Instead of proving its identity to each service, the client first authenticates to a trusted third party: the Domain Controller, acting as the Key Distribution Center (KDC).

This design introduces central trust—and from an attacker’s view, a central point of failure.

Every Domain Controller in an Active Directory environment runs the Kerberos KDC service. The KDC is responsible for:

• Verifying user and computer identities
• Issuing session tickets
• Generating temporary session keys

The KDC itself is logically divided into two services:

• Authentication Server (AS)
• Ticket Granting Service (TGS)

Kerberos authentication always begins with the KDC, never with the application server directly.

Let’s walk through the process as it happens in a real Windows domain.

1. Initial Login: AS-REQ

When a user logs into their workstation, the system sends an Authentication Server Request (AS-REQ) to the Domain Controller.

This request includes:

• The username
• A timestamp encrypted using a key derived from the user’s password

At this stage, the password itself is never transmitted.

2. Password Verification on the Domain Controller

The Domain Controller receives the AS-REQ and performs the following actions:

• It retrieves the user’s password hash from the NTDS.dit database.
• It uses this hash to decrypt the timestamp.
• If decryption succeeds and the timestamp is valid and unique, authentication succeeds.

A duplicated timestamp indicates a replay attack, which Kerberos is explicitly designed to detect and block.

3. AS-REP: Issuing the TGT

If authentication is successful, the KDC responds with an Authentication Server Reply (AS-REP) containing:

• A session key, encrypted with the user’s password hash
• A Ticket Granting Ticket (TGT)

The TGT contains:

• Username
• Domain name
• Client IP address
• Timestamp
• The session key

This entire TGT is encrypted using the NTLM hash of the krbtgt account—a secret known only to the KDC.

Because of this:

• The client cannot decrypt or modify the TGT
• Only the KDC can validate it

Once the client receives the TGT, the initial authentication phase is complete. By default, the TGT is valid for 10 hours and can be renewed without re-entering the user’s password.

4. Requesting Access to a Service: TGS-REQ

When the user attempts to access a domain resource—such as a file share or application—the client sends a Ticket Granting Service Request (TGS-REQ) to the KDC.

This request includes:

• The encrypted TGT
• The name of the requested service
• A timestamp encrypted with the session key from the AS-REP

5. TGS Validation and Ticket Issuance

The Ticket Granting Service performs several checks:

1. Decrypts the TGT using the krbtgt secret key
2. Extracts the session key
3. Uses that session key to decrypt the username and timestamp in the request

It then verifies:

• The TGT timestamp is valid
• The username matches the TGT
• The client IP address matches

If everything checks out, the KDC sends a Ticket Granting Service Reply (TGS-REP) containing:

• The service name
• A new session key (for client–service communication)
• A Service Ticket

Service Ticket Encryption

• Part of the ticket is encrypted with the original session key so only the client can read it.
• The entire service ticket is encrypted using the password hash of the service account.

This means:

• Only the service can decrypt its ticket
• The client cannot see service-specific data

From an attacker’s perspective, this is where Kerberoasting becomes possible.

6. Service Authentication: AP-REQ

Now that the client has a service ticket, it can authenticate directly to the application server.

The client sends an Application Request (AP-REQ) containing:

• The service ticket
• A timestamp encrypted with the service session key

7. Application Server Validation and Authorization

The application server:

1. Decrypts the service ticket using its own service account password hash
2. Extracts the username and session key
3. Uses the session key to decrypt the AP-REQ timestamp

If the usernames match, authentication succeeds.

At this point, the server:

• Reads the user’s group memberships from the service ticket
• Applies access controls based on those groups
• Grants or denies access to the requested resource