Kerberos

Overview

If a service is accessed using an IP address instead of a hostname, Kerberos cannot be used and NTLM is forced, often causing authentication to fail if NTLM is not supported or allowed.

Kerberos is the default authentication protocol (TCP port 88) in modern Active Directory (AD) environments, replacing NTLM since Windows Server 2000. It operates on a ticket-based model and uses a centralized authority, the Key Distribution Center (KDC). The Domain Controller (DC) acts as the KDC within an AD environment.

The core security-related strengths of Kerberos are:

• Users only need to prove their identity once. Thus, sensitive information, such as passwords, is not continually transmitted across the network, which significantly lowers the risk of interception.

• Uses time-limited, service-specific, and highly-protected tickets. As a result, even if a ticket is compromised, its limited validity window and scope helps minimise potential impact.

Kerberos Flow

The Kerberos authentication process conists of three main entities and has three phases.

# Entities
Client | Service | KDC

# Phases
Authentication Service (AS) --> Ticket Granting Service (TGS) --> Application Request (AP) 

Simplified

The Kerberos process can be imagined as the process of checking into a hotel and subsequently accessing its various services.

Authentication Service

When a guest (domain account) arrives at a hotel, they first report to reception (KDC) and present some form of official ID, for example, a passport (password). The reception (KDC) verify the guest’s ID and confirm their reservation details. Once this verification is successfully completed, the hotel issues a room key (TGT) which serves as proof that the hotel has authenticated the guest.

         Guest Arrives at Hotel (Domain account wants to access AD)
             |
             | Shows official ID (types their password)
             v
      +--------------------+
      | Reception (KDC)    |
      +--------------------+
             |
             | Verifies ID & confirms reservation (Matches the user's hash to its db)
             v
      +--------------------+
      | Room Key (TGT)     |
      +--------------------+

Ticket Granting Service

Let's say that the guest (domain account) wants to access the spa area (MSSQL service). This time, the guest only has to show their room key (TGT) to the reception (KDC), and not their official ID (password). Their room key (TGT) servers as a proof that they have already been verified. The reception (KDC) verify its validity and, if it is confirmed, issue a temporary spa pass (TGS).

          Guest (Account) wants spa access (MSSQL service)
              |
              | Shows Room Key (TGT) (instead of password (password))
              v
      +--------------------+
      | Reception (KDC)    |
      +--------------------+
              |
              | Reception (KDC) verifies Room Key (TGT)'s
              | validity & issues temporary Spa Pass (TGS)
              v
      +--------------------------+
      | Temporary Spa Pass (TGS) |
      +--------------------------+
              |
              | Shows temporary Spa Pass (TGS) 
              | at the spa entrance (MSSQL server)
              | & gets access to the spa area (MSSQL service)

Application Request

The guest (domain account) presents the temporary spa pass (TGS) at the spa entrance (MSSQL service). The latter verifies the authenticity and validity of the pass and, if the pass is valid, grants the guest spa access.

          Guest (User) presents Temporary Spa Pass (TGS)
              |
              v
      +---------------------+
      | Spa (MSSQL Service) |
      +---------------------+
              |
              | Spa staff (MSSQL service) verify the validity & 
              | authenticity of the Temporary Spa Pass (TGS)
              v
      +------------------------------------+
      | Spa Access Granted (MSSQL service) |
      +------------------------------------+

One key point is that the reception (KDC) treats any guest (domain account) presenting a valid temporary pass (TGS) as already having verified their identity.

Detailed

Authentication Service (AS)

1. Authentication Service Request → A user logs in and sends an AS-REQ to KDC. This includes:

   1. Their username.

   2. An authenticator (timestamp) encrypted with a key derived from the user's password.

2. Authentication Service Reply → The KDC retrieves the user’s password hash from its database (ntds.dit) and attempts to decrypt the authenticator. If successful and the timestamp is valid (a duplicate timestamp may indicate a replay attack), the KDC replies with an AS-REP. This contains:

   1. A user-KDC session key encrypted with the user’s key.

   2. A TGT (user information + user-KDC session key) encrypted with a key derived from krbtgt's password.

The user decrypts the user-KDC session key and stores the TGT. The latter is typically valid for 10 hours and can be renewed.

+------------------------------------------------------------------+
|                    AUTHENTICATION SERVICE (AS)                   |
+------------------------------------------------------------------+

  AS-REQ  (Client → KDC)
  -----------------------------------------
  Username
  Authenticator (Timestamp encrypted with a key derived from user's password)


  AS-REP  (KDC → Client)
  -----------------------------------------
  1) User-KDC Session Key (Encrypted with a key derived from user's password)

  2) TGT (Encrypted with a key derived from krbtgt's password)
     ---------------------------------
     User information
     User-KDC Session Key
     ---------------------------------

Ticket Granting Service

1. Ticket Granting Service Request → When the user tries to access a service, the client sends a TGS-REQ to KDC. This includes:

   1. The target service (SPN)

   2. The TGT

   3. An authenticator (timestamp) encrypted with the user-KDC session key.

2. Ticket Granting Service Reply → The KDC decrypts and validates the TGT, and then extracts the user-KDC session key (checks the timestamp by decrypting the authenticator). If everything checks out, it sends a TGS-REP, which includes:

   1. A user-service session key encrypted with the user-KDC session key.

   2. A TGS (SPN + user information + user-service session key) encrypted with a key derived from the service's password.

+------------------------------------------------------------------+
|                  TICKET GRANTING SERVICE (TGS)                   |
+------------------------------------------------------------------+

  TGS-REQ  (Client → KDC)
  -----------------------------------------
  Target Service (SPN)
  TGT
  Authenticator (Timestamp encrypted with user-KDC session key)


  TGS-REP  (KDC → Client)
  -----------------------------------------
  1) User-Service Session Key (Encrypted with user-KDC session key)

  2) Service Ticket (TGS) (Encrypted with a key derived from service's password)
     ---------------------------------
     SPN
     User information
     User-Service Session Key
     ---------------------------------

Application Request

1. Application Request → The user decrypts and extracts the user-service key and TGS. They then send to the service an AP-REQ which consists of:

   1. The TGS

   2. An authenticator encrypted with the user-service session key.

2. Application Replay → The service decrypts the TGS and extracts the service-session key and user info. Then it uses the service-session key to decrypt the authenticator and verifies the timestamp. If valid, it checks group membership information from the ticket and grants access accordingly by sending an AP-REP to the user which includes:

   1. A timestamp encrypted with the user-service session key.

+------------------------------------------------------------------+
|                        APPLICATION PHASE (AP)                    |
+------------------------------------------------------------------+

  AP-REQ  (Client → Service)
  -----------------------------------------
  Service Ticket (TGS)
  Authenticator (Timestamp encrypted with user-service session key)


  Service Processing
  -----------------------------------------
  Decrypt TGS with Service Account Hash
  Extract User-Service Session Key
  Decrypt Authenticator
  Validate timestamp


  AP-REP (Optional)
  -----------------------------------------
  Timestamp encrypted with user-service session key

Kerberos Attacks

Ticket Roasting Attacks

Practical implementation of AS-REPRoasting and Kerberoasting.

Both TGTs and TGSs in Kerberos can be targeted by attackers:

• AS-REP Roasting occurs when an attacker requests a TGT for a user account that has pre-authentication disabled. In this case, the KDC responds with an AS-REP containing data derived from the user’s password, which can then be subjected to offline brute-force or dictionary attacks to recover the credential.

• Kerberoasting involves an attacker who already possesses a valid TGT requesting a TGS for a specific service. The KDC returns a TGS-REP encrypted with the service account’s password hash, allowing the attacker to perform offline cracking to obtain the service account credentials.

Ticket Forging Attacks

Practical implementation of the Golden and Silver ticket attack.

Ticket forging attacks occur when the encryption keys protecting Kerberos tickets are compromised:

• TGTs are encrypted using the KDC's secret key. If this key is compromised, an attacker can forge TGTs (Golden Tickets) which allow them to impersonate any user and obtain unrestricted access across the domain.

• TGSs are encrypted with the target service account’s key. If this key is exposed, an attacker can generate forged service tickets (Silver Tickets), which grant unauthorised access to the specific service associated with that account.

Delegation Attacks

Practical implementation of delegation attacks.

Delegation attacks exploit Kerberos delegation, a feature that allows a service to impersonate a user when accessing other resources on their behalf. When delegation is misconfigured or overly permissive, attackers can abuse it to escalate privileges and move laterally across multiple services within the domain.

Password Spray Attacks

Password spraying attacks are based on the KDC’s responses to authentication requests in Kerberos. By requesting a TGT for specific usernames, an attacker can sometimes determine whether an account exists. They can then try a small number of common passwords across many users, rather than multiple attempts against a single account which avoids account lockouts while increasing the chances of identifying weak or reused credentials.