Kerberos Authentication

Understanding Kerberos Authentication: Mechanisms, Tickets, and Key Concepts

Hello Learners, You are authorized to know me as Obfuscator!

I’m here with an useful resource for you to dive into in my Active Directory (AD) Attacks chapter. This time, we’re going deep into Kerberos Authentication. Here, I will only include the process how Kerberos handles authentication.

Lets move on skipping its historic story…

As many of you know, Kerberos is a cornerstone of authentication in Windows environments, and understanding how attackers exploit weaknesses in this system is crucial for both red teams and defenders. In this new section, we’ll break down the underlying mechanisms of Kerberos, its ticket-granting tickets (TGTs), Ticket-granting services (TGS) with full process and common terminologies realated to them. Some common attack vectors like Pass-the-Ticket (PTT), Kerberoasting, Golden and Silver tickets and other many more concepts will be discussed in another post. Always stay tuned and updated. Lets begin.

To begin the study, these key terminologies need to be cleared:

1. TGT: Ticket granted by KDC which is used to request TGS tickets.
2. TGS Ticket: Ticket issued by TGS to access specific service
3. Key Distribution Center (KDC): Service installed in Domain Controller which manages authentication in Kerberos network. It consists of two main components: AS and TGS.
4. Authentication Server (AS): Verifies the identity of the user and issues the Ticket Granting Ticket (TGT).
5. Ticket Granting Server (TGS): Issues service tickets to users after validating the TGT.
6. KRBTGT: Special user account used by KDC for its password hash to be used to encrypt TGT.
7. SPN (Service Principle Name): Unique identifier to identify
   service which user requests to access.

Real world Scenario (Level 1 Basic understanding):

Lets consider a user obs1_trail. The purpose is to authenticate the user to the KDC and request a Ticket Granting Ticket. That ticket granting ticket is used to request a Ticket Granting Service, yet another ticket. Using that TGS ticket, the user can request to get acccess to any service that she has privilege to access.

In short: A master ticket, which is used to get service specific ticket. User presents that service specific ticket to get access to that service.

Let’s say obs1_trail is an employee at a company using a Windows AD network. She needs to access a file share on a server. Here’s how Kerberos handles it in a real AD setup.

Get Saksham Baral’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Step 1: Authenticating and Requesting the TGT

• Scenario: Trail sits at her company laptop and logs into Windows with her AD credentials: obs1_trail@company.com and her password.
• Process:
  Her laptop sends a request to the Domain Controller (the KDC) with her username and an encrypted timestamp (using a key from her password’s hash).
  The KDC, running AD’s Kerberos services, verifies her credentials against its database.
• Result: The KDC sends back a Ticket Granting Ticket (TGT) — a master ticket proving she’s authenticated, stored in her laptop’s memory (LSASS process).
• Purpose: This TGT lets her request access to services without re-entering her password.

Step 2: Requesting a TGS for a Service

• Scenario: Trail opens File Explorer and tries to access a shared folder (\\FileServer\Reports) on a company server.
• Process:
  Her laptop uses the TGT to contact the KDC again, sending previously received TGT and request for file server identified by its Service Principal Name (SPN) (e.g. FILE/Fileserver.company.com).
• Result: The TGS is returned to her laptop, encrypted with the file server’s account key (e.g., FileServer$’s password hash).
• Purpose: The TGS is a service-specific ticket for accessing only that file share.

Step 3: Accessing the Service with the TGS

• Scenario: Trail’s laptop connects to FileServer to open the Reports folder.
• Process
  The laptop sends the TGS to the file server.
  The file server decrypts the TGS with its own key, verifies Trail’s identity (obs1_trail), and checks her permissions in AD (e.g., via the TGS’s authorization data).
• Result: If she has access rights, the file server grants her entry to the Reports folder, and she can read or edit files.
• Purpose: The TGS proves she’s authorized, letting her use the service securely.

How it fits together?

• TGT (Master Ticket): Trail gets this when she logs into her laptop, authenticating her to the AD network once.
• TGS (Service Ticket): She uses the TGT to get a TGS for the file server, tailored to that specific resource.
• Service Access: The TGS lets her into the file share without needing to log in again, all handled seamlessly by AD.

Technical Understanding(Level 2)

To understand the whole process that Kerberos implements technically, several steps and procedures are summarized into these four major steps:

1. User authentication and TGT Request

• User sends username (plaintext) and timestamp, encrypted with a key derived from their password, to the Key
  Distribution Center (KDC). Timestamp used in every request is to prevent from replay attacks.
• KDC decrypts the request using the user’s password hash and verifies it.

Note: Use colors and symbols to understand what is encrypted by what and what thing is inside what.

2. TGT issuance by KDC

• After successful authentication in previous step, the KDC sends back a Ticket Granting Ticket (TGT) and a session key.
• Ticket Granting Ticket (TGT) is encrypted with krbtgt’s pasword hash and session key is encrypted with user’s password hash so that intruders can not decrypt (Shown in figure below using key and lock symbol with matching colors)
• The TGT contains User’s identity, timestamp and a copy of session key. Copy of session key is included so that KDC has no need to store the session key as it can recover a copy by decrypting the TGT if needed later.
  Note: User can decrypt the session key using his password hash and use that session key as cryptography key to encrypt further requests. That request can be decrypted by KCD using same session key inside TGT (Only krbtgt password hash can decrypt TGT)

3. Requesting Service Ticket From TGS(KDC) and its Response

• To get the access for specific service, the user sends a request to the Ticket Granting Service (TGS) of KDC including the following components:
  - Encrypted TGT which user previously got
  - Identity(username) and timestamp both encrypted with session key
  - Service Principal Name (SPN) specifying which service to access
• TGS decrypts the TGT using krbtgt password hash to get the session key. It decrypts the encrypted username and timestamp using that session key and validates the timestamp.
• TGS issues a TGS Ticket(Encrypted with service owner’s hash) and a new Servcie Session key (encrypted with previous session key) and sends as a response to user. The TGS Ticket contains User’s identity, timestamp and a copy of service session key.

Note: The following figure visualises the whole process to make it easy to understand.

4. Service ticket validation and secure session establishment

• User sends username and timestamp both encrypted using Service session key and previously issued TGS to that service
• Service decrypts the TGS Ticket using its own account’s password hash and extracts the Service Session Key.
• Service validates the TGS (decrypting and verifying username and timestamp by service session key).
• After validation, a secure communication channel is established between user and that service using service session key. Service session key is the Symmetric Cryptography Key used to encrypt and decrypt further communication data between them.

This much for today.

Dropping comment does not require authentication, feel free . . .

Meet you soon again.