Understanding Kerberos Authentication and its Attacks

Kerberos is a widely used authentication protocol that ensures secure identity verification within networks. It relies on a trusted third party, the Key Distribution Center (KDC), to facilitate authentication and ticketing mechanisms. While Kerberos enhances security, various attacks can exploit its mechanisms. This blog post explains the Kerberos authentication flow and examines critical attacks such as Golden Ticket, Silver Ticket, Unconstrained Delegation, Constrained Delegation, and Forest Persistence (DCShadow).

Kerberos Authentication Flow

1. Authentication Service Request (AS-REQ)

The client initiates an authentication request to the KDC’s Authentication Server (AS).
This request contains a timestamp encrypted with the NTLM hash of the user's password - AS-REQ

2. Authentication Service Reply (AS-REP)

The KDC responds by providing a Ticket Granting Ticket (TGT) and a session key. The TGT is encrypted, signed, and delivered to the user. Only the krbtgt account (KDC) can decrypt and read the TGT.
An attacker with a valid TGT can authenticate to domain services, but to access a specific service, they need a corresponding TGS. In attacks like Golden Ticket (forging TGT) and Silver Ticket (forging TGS), the attacker can generate fake tickets to bypass authentication and gain unauthorized access.

3. Ticket Granting Service Request (TGS-REQ)

Client sends Ticket Granting Service request (TGS-REQ) to DC. Request consists of

The user’s encrypted TGT
A timestamp encrypted using the session key
The Service Principal Name (SPN) of the requested resource

The KDC decrypts the TGT using the krbtgt hash, validates the session key, and retrieves the username and timestamp.

4. Ticket Granting Service Reply (TGS-REP)

Upon validation, the KDC responds with a TGS (Service Ticket)/TGS-REP, encrypted using the target service's NTLM hash. This response includes:

The SPN
A new session key
A service ticket containing the username, group membership, and the session key

5. Application Request

The client sends the service ticket to the application server. The application server decrypts it using its NTLM hash and extracts the username and session key.

First the client sends an application request to the application server which includes the username and timestamp encrypted with the session key associated with the service ticket along with the service ticket ifself.
The application server decrypts the Service ticket with the service account password hash.
Extracts the username and the session key. it then uses the service key to decrypt the username from the application request.

6. Service Authentication

The application server verifies the username in the service ticket. If it matches, access is granted based on group membership and assigned permissions.

Kerberos Attacks

1. Golden Ticket Attack

In a Golden Ticket attack, the attacker forges a TGT using the NTLM hash of the krbtgt account. The client then sends this forged TGT to the KDC, which decrypts it and grants a valid TGS for any service without verifying its authenticity against other domain controllers

A Golden Ticket attack exploits Kerberos' reliance on krbtgt account validation.

The KDC only verifies if the TGT is decryptable.
If an attacker obtains the krbtgt hash, they can forge a TGT.
Since the forged TGT is encrypted with a valid krbtgt hash, it is considered legitimate by the KDC.
Golden ticket is a signed and encrypted by the hash of krbtgt account which makes its a valid tgt ticket.

A Golden Ticket allows attackers to maintain persistence and access any resource within the domain.

2. Silver Ticket Attack

In a Silver Ticket attack, the attacker forges a TGS using the NTLM hash of a service account. The client then sends this forged TGS to the application server, which decrypts it and grants access without validating it against the KDC.

A Silver Ticket attack targets service-specific authentication.

Instead of the krbtgt hash, attackers extract the NTLM hash of a service account.
They then forge a TGS ticket signed with this hash, enabling access to the service.
Silver Tickets work because most services do not validate the Privilege Attribute Certificate (PAC).
Unlike Golden Tickets, Silver Tickets are only valid for the targeted service.
Reasonable Persistence period (Default 30days for computer accounts)
In a Silver Ticket attack, the attacker does not interact with the KDC at all.

3. Unconstrained Delegation

Unconstrained delegation allows a server to reuse user Kerberos credentials to access other resources on their behalf.

When a user logs into a web server, the web server needs to authenticate to a database server as the user (not as its own service/machine account). This creates a double-hop scenario (User → Web Server → Database).
To enable this, Kerberos delegation is introduced, allowing the web server's service account to be trusted for delegation so it can request access as the user.
Once enabled, the web server can authenticate as the user and request access to any service on any computer within the domain.

How it works:

A user logs into a web server.
The web server must authenticate to a database server as the user.
The web server's service account is trusted for delegation.
The web server can impersonate the user and request access to any resource.

In Simple Terms:

User provides credentials to the domain controller
DC returns TGT
the user requests a TGS for the web service on the Web Server
The DC provides a TGS
the user sends the TGT and TGS to the web server
The Web Server service account uses the user's TGT to request a TGS for the database server from the DC
The web server service account connects to the Database server as the user.

Since the web server can act on behalf of users, an attacker who compromises it can escalate privileges across the domain.

4. Constrained Delegation

Constrained delegation restricts delegation to specific services. If the user is not using Kerberos authentication to authenticate to the first hop server, windows offers protocol transition to transition the request to Kerberos.

How it works:

A web server makes requests to a database server on behalf of a user.
If the user does not authenticate with Kerberos, Windows allows Protocol Transition.
The Service for User (S4U) extension enables impersonation.

Two key components of S4U:

Service for User to Self (S4Uself) - Allows a service to obtain a forwardable TGS to itself on behalf of a user with just the user principal name without supplying a password. The service must have the TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION -T2A4D UserAccountControl attribute.
Service for User to Proxy (S4U2proxy) - Allows a service to obtain a TGS to a another service on behalf of a user. This is controlled by msDS-AllowedToDelegateTo attribute. the attribute contains a list of SPNs to which the user token can be forwarded.

Attackers can exploit S4U to impersonate users and gain unauthorized access.

5. Forest Persistence – DCShadow Attack

A DCShadow attack enables attackers to modify Active Directory (AD) data without logs. DCShadow temporarily registers a new domain controller in the target domain and uses it to "push" attributes like SIDHistory, SPNs etc. on specified objects without leaving the change logs for modified object.

How it works:

A rogue domain controller is registered in AD.
The attacker modifies the Configuration Container and SPNs of an existing computer object and couple of RPC services.
Since changes originate from a "domain controller," no directory change logs are created on the Legitimate DC for the target object.
Requires Domain Admin privileges and root domain access to perform DCShadow Attack.

DCShadow enables attackers to push changes such as adding users to privileged groups without detection.

Conclusion

Kerberos is a robust authentication protocol, but it is not impervious to attacks. Understanding its workflow helps identify potential security gaps and mitigate threats like Golden and Silver Ticket attacks, delegation exploits, and DCShadow. Organizations should enforce security best practices such as monitoring ticket requests, restricting delegation, and protecting high-value credentials to safeguard their environments from Kerberos-based attacks.