This chapter covers the Kerberos authentication protocol, a cornerstone of network security in Windows Active Directory and many Unix environments. For the SY0-701 exam, you must understand how Kerberos provides secure authentication using tickets and symmetric-key cryptography, and how it prevents replay and eavesdropping attacks. This content maps to Objective 1.2 (General Security Concepts) under authentication protocols. Mastering Kerberos is critical because it is the default authentication mechanism in modern Windows networks and is frequently tested in scenario-based questions.
Jump to a section
Imagine a hotel that uses a key card system for room access, but with a twist: the front desk (KDC) issues a temporary access token (TGT) when you check in. This token proves you are a registered guest. When you want to enter the gym (a service), you present your TGT to the front desk, which then issues a gym-specific key card (service ticket) that only works for the gym and expires in 30 minutes. The gym door doesn't know who you are—it just verifies the key card's signature from the front desk. Now, consider an attacker who steals your TGT. They cannot use it to enter the gym directly; they must first request a service ticket, but the front desk will only issue it if the TGT is valid. However, if the attacker also intercepts the service ticket, they can replay it until it expires. To prevent this, the hotel's key cards include the room number (client identity) encrypted in a way the gym can read, so the gym checks that the card matches the person presenting it. This mirrors Kerberos: the TGT is the initial ticket, the service ticket is the session ticket, and the authenticator proves the client's identity to prevent replay attacks.
What is Kerberos and What Threat Does It Address?
Kerberos is a network authentication protocol designed to provide strong authentication for client-server applications using secret-key cryptography. It was developed by MIT and is defined in RFC 4120. The primary threat Kerberos addresses is the transmission of passwords over insecure networks. Instead of sending a password, Kerberos uses tickets—time-limited, encrypted data structures—to prove identity. This prevents password sniffing and replay attacks. Kerberos also provides mutual authentication, meaning both the client and server verify each other's identity, preventing man-in-the-middle (MITM) attacks.
How Kerberos Works Mechanically – The Step-by-Step Process
Kerberos operates on a trusted third-party model. The trusted third party is the Key Distribution Center (KDC), which consists of two components: the Authentication Service (AS) and the Ticket-Granting Service (TGS). The protocol involves three main exchanges, often summarized as "AS-REQ/AS-REP, TGS-REQ/TGS-REP, AP-REQ/AP-REP." The process uses symmetric encryption with keys derived from passwords.
1. AS Exchange (Authentication Service Request/Response): - The client sends an AS-REQ message to the KDC's AS. This message includes the client's username and a timestamp encrypted with the client's long-term key (derived from the user's password). The KDC looks up the client's key in its database (e.g., Active Directory). - The KDC responds with an AS-REP containing two parts: - Ticket-Granting Ticket (TGT): Encrypted with the KDC's own secret key (krbtgt account in Windows). The TGT includes the client's identity, the TGS service name, a session key (SK1), a timestamp, and an expiration time. - Session Key (SK1): Encrypted with the client's long-term key. The client decrypts this to obtain SK1. - The client now has a TGT (which it cannot decrypt) and a session key SK1.
2. TGS Exchange (Ticket-Granting Service Request/Response): - When the client wants to access a service (e.g., a file server), it sends a TGS-REQ to the KDC's TGS. The request includes:
- The TGT (from step 1). - An authenticator encrypted with SK1 (containing the client's identity and a timestamp). - The service principal name (SPN) of the target service. - The KDC decrypts the TGT using its own key, extracts SK1, and uses SK1 to decrypt the authenticator. It verifies the timestamp to prevent replay (typically allows a 5-minute clock skew). - The KDC responds with a TGS-REP containing: - Service Ticket (ST): Encrypted with the service's long-term key. The ST includes the client's identity, a new session key (SK2), and an expiration time. - Session Key (SK2): Encrypted with SK1. The client decrypts this to obtain SK2.
3. AP Exchange (Client/Server Authentication): - The client sends an AP-REQ to the target service. The request includes:
The service ticket (ST) from step 2.
A new authenticator encrypted with SK2 (client identity and timestamp).
The service decrypts the ST using its own long-term key, extracts SK2, and uses SK2 to decrypt the authenticator. It verifies the timestamp.
Optionally, the service can respond with an AP-REP containing a timestamp encrypted with SK2, providing mutual authentication.
Key Components, Variants, and Standards
- Key Distribution Center (KDC): The trusted third party. In Windows, the KDC runs on domain controllers and uses the krbtgt account. - Ticket-Granting Ticket (TGT): A ticket that proves the client has authenticated to the KDC. It is encrypted with the KDC's key and contains a session key. - Service Ticket (ST): A ticket that proves the client is authorized to access a specific service. It is encrypted with the service's key. - Authenticator: A data structure containing the client's identity and a timestamp, encrypted with the session key. It proves the client possesses the session key and prevents replay. - Session Key: A temporary symmetric key used for encrypting communication between the client and the service. - Principal: A unique identity in the Kerberos realm (e.g., user, service, host). - Realm: The Kerberos administrative domain (equivalent to a Windows domain). - Port Numbers: Kerberos uses UDP/TCP port 88 for KDC traffic. For changing passwords, it uses TCP port 464. - Encryption Types: Kerberos supports various encryption algorithms. Common ones include: - AES256-CTS-HMAC-SHA1-96 (strongest, used in modern Windows) - AES128-CTS-HMAC-SHA1-96 - RC4-HMAC (legacy, weak) - DES-CBC-MD5 (deprecated) - Time Synchronization: Kerberos relies on clock synchronization within a configurable skew (default 5 minutes). If clocks differ beyond this, authentication fails. - RFC 4120: The current standard for Kerberos. - Kerberos in Windows: Active Directory uses Kerberos as the default authentication protocol. The KDC is integrated into domain controllers. The krbtgt account is a disabled account whose password is used to encrypt TGTs.
How Attackers Exploit Kerberos and Defenders' Countermeasures
Attack Techniques: - Golden Ticket Attack: An attacker who gains the krbtgt account's password hash (e.g., via DCSync) can forge TGTs for any user, granting persistent, undetectable access. The attacker can create a TGT with arbitrary user privileges, including domain admin. - Silver Ticket Attack: An attacker who compromises a service's password hash can forge service tickets for that service, allowing unauthorized access without contacting the KDC. - Kerberoasting: An attacker requests service tickets for service accounts (SPNs) and cracks the encrypted portion offline to recover the service account's password. This works because service tickets are encrypted with the service account's NTLM hash. - AS-REP Roasting: For users with "Do not require Kerberos preauthentication" enabled, an attacker can request an AS-REP and crack the encrypted data offline to obtain the user's password. - Pass-the-Ticket: An attacker steals a TGT or service ticket from a compromised host and uses it to authenticate as that user without knowing the password. - Pass-the-Hash (related): While not Kerberos-specific, attackers can use NTLM hashes to request Kerberos tickets.
Defender Countermeasures: - Protect the krbtgt account: Regularly rotate the krbtgt password (especially after a compromise). Use privileged access workstations (PAWs) to limit exposure. - Use strong passwords for service accounts: Service accounts should have long, complex passwords that are resistant to cracking. - Enable Kerberos preauthentication: By default, Windows requires preauthentication. Ensure no accounts have this disabled (check for DONT_REQ_PREAUTH flag). - Monitor for anomalous Kerberos traffic: Use tools like Microsoft Defender for Identity to detect golden ticket attacks (e.g., TGTs with unusual lifetimes or user IDs). - Implement time synchronization: Use NTP to keep clocks within the skew limit. - Use AES encryption: Disable RC4 and DES to prevent weaker encryption attacks. - Audit Kerberos service ticket requests: Enable logging for Kerberos service ticket operations (Event ID 4769) to detect Kerberoasting.
Real Command/Tool Examples
- Requesting a TGT (using kinit on Linux):
kinit user@REALM- Listing cached tickets (klist):
klist- Viewing Kerberos tickets in Windows (klist):
klist tickets- Extracting TGT from memory (Mimikatz):
mimikatz # kerberos::ptt ticket.kirbi- Forcing Kerberos authentication in Windows (setspn):
setspn -A HTTP/webserver.domain.com domain\serviceaccount- Checking Kerberos configuration in Windows (klist -li 0x3e7):
klist -li 0x3e7- Kerberoasting with Impacket:
GetUserSPNs.py -request -dc-ip 10.0.0.1 domain/user- AS-REP Roasting with Impacket:
GetNPUsers.py domain/ -usersfile users.txt -format hashcatClient Requests TGT from AS
The client sends an AS-REQ to the KDC's Authentication Service. This message contains the client's username and a timestamp encrypted with the client's long-term key (derived from the user's password). The KDC looks up the client's key in its database. If preauthentication is enabled, the KDC will only respond if the timestamp is valid and decryptable. The KDC generates a TGT and a session key (SK1). The TGT is encrypted with the KDC's secret key (krbtgt hash), and SK1 is encrypted with the client's key. The AS-REP is sent back to the client. The client decrypts SK1 and stores the TGT for later use. Logs: Windows Event ID 4768 (Kerberos TGT was requested) is generated on the domain controller.
Client Stores TGT and SK1
Upon receiving the AS-REP, the client extracts the TGT (which it cannot decrypt) and the session key SK1. The TGT is cached in memory (in Windows, it is stored in the lsass.exe process). The client now has proof of authentication to the KDC. The TGT includes a lifetime (default 10 hours in Windows) and is renewable. The client can use this TGT for the duration to request service tickets without re-entering the password. The session key SK1 is used to encrypt authenticators in subsequent TGS requests. Logs: No specific event for caching, but the TGT is visible with `klist`.
Client Requests Service Ticket from TGS
When the client needs to access a service (e.g., a file share), it sends a TGS-REQ to the KDC's Ticket-Granting Service. The request includes the TGT, an authenticator encrypted with SK1 (containing the client's identity and a timestamp), and the SPN of the target service. The KDC decrypts the TGT with its own key, extracts SK1, and uses it to decrypt the authenticator. It verifies the timestamp (within 5 minutes). The KDC then generates a service ticket (ST) encrypted with the service's long-term key, and a new session key SK2 encrypted with SK1. The TGS-REP is sent back. Logs: Windows Event ID 4769 (Kerberos service ticket was requested) is generated.
Client Sends Service Ticket to Server
The client extracts the service ticket and SK2. It then sends an AP-REQ to the target service. The AP-REQ contains the service ticket (still encrypted with the service's key) and a new authenticator encrypted with SK2. The service decrypts the service ticket using its own long-term key, extracts SK2, and uses it to decrypt the authenticator. It verifies the timestamp. If mutual authentication is required, the service sends an AP-REP containing a timestamp encrypted with SK2. The client verifies this response. The service now knows the client is authenticated, and a secure session can begin using SK2. Logs: Windows Event ID 4624 (account logon) may be generated on the server.
Session Continues with SK2
Once the AP exchange is complete, the client and server have a shared session key SK2. This key can be used to encrypt further communication between them, providing confidentiality and integrity. The service ticket and SK2 have a limited lifetime (default 10 hours for TGT, but service tickets typically have shorter lifetimes, e.g., 1 hour). When the ticket expires, the client must request a new service ticket from the TGS using the existing TGT (if still valid). If the TGT expires, the client must re-authenticate to the AS. Logs: Continued use of the session is not logged by default, but ticket renewal events may appear (Event ID 4770).
Scenario 1: Detecting a Golden Ticket Attack
A SOC analyst notices a user account generating Kerberos TGTs with an unusually long lifetime (e.g., 10 years) and with a user ID that does not exist in Active Directory. The analyst uses Microsoft Defender for Identity or a SIEM to query for Event ID 4768 with suspicious attributes. The correct response is to immediately reset the krbtgt account password twice (to invalidate all existing TGTs) and investigate the source of the compromise. A common mistake is to ignore the alert because the user appears legitimate, not realizing the TGT was forged.
Scenario 2: Kerberoasting Attack
An attacker uses a tool like Impacket's GetUserSPNs.py to request service tickets for all service accounts in the domain. The SOC detects a high volume of Event ID 4769 from a single source IP for multiple SPNs within a short time. The analyst should correlate with the source machine and check if the requesting user has legitimate reason. The correct response is to disable the compromised account, rotate the service account passwords, and enforce strong passwords. A common mistake is to block the IP without investigating the account, allowing the attacker to continue from another host.
Scenario 3: AS-REP Roasting
An administrator finds that a user account has the 'Do not require Kerberos preauthentication' option enabled. An attacker has already retrieved the AS-REP and is cracking the hash offline. The SOC should immediately disable that option, force a password reset, and audit all accounts for this setting. A common mistake is to assume the setting is harmless because it is rarely used, but attackers actively scan for it.
What SY0-701 Tests on Kerberos
The exam expects you to know: (1) Kerberos is a ticket-based authentication protocol using symmetric encryption. (2) It provides mutual authentication and prevents replay attacks. (3) The KDC consists of AS and TGS. (4) TGT is used to request service tickets. (5) Port 88 is used for Kerberos traffic. (6) Kerberos relies on time synchronization. (7) Common attacks: golden ticket, silver ticket, Kerberoasting, AS-REP roasting, pass-the-ticket.
Common Wrong Answers
"Kerberos uses public-key cryptography." – Wrong. It uses symmetric-key cryptography. Candidates confuse it with PKI.
"The TGT is encrypted with the user's password." – Wrong. It is encrypted with the KDC's secret key (krbtgt hash).
"Kerberos authenticates users by sending the password over the network." – Wrong. Passwords are never sent; tickets are used.
"Kerberos is only used in Windows." – Wrong. It is used in many Unix/Linux environments as well.
Specific Terms and Values - Port: 88 (UDP/TCP) - Default ticket lifetime: 10 hours (Windows) - Clock skew: 5 minutes - Encryption types: AES256, AES128, RC4, DES (deprecated) - RFC 4120 - Components: AS, TGS, KDC, TGT, ST, Authenticator, Session Key
Trick Questions - Questions that ask about "preauthentication" – if an account has it disabled, it is vulnerable to AS-REP roasting. - Questions that mix up TGT and service ticket – TGT is for obtaining other tickets; service ticket is for accessing a service. - Questions that mention "Kerberos" but actually refer to NTLM – remember Kerberos is default in domain environments.
Decision Rule If a scenario mentions "tickets," "mutual authentication," "time stamps," or "port 88," the answer is likely Kerberos. If it mentions "challenge-response" or "hashing," it is likely NTLM. For attacks, if the attacker forges a TGT, it's golden ticket; if they forge a service ticket, it's silver ticket; if they crack service tickets offline, it's Kerberoasting.
Kerberos uses UDP/TCP port 88 for KDC traffic.
The KDC consists of the Authentication Service (AS) and Ticket-Granting Service (TGS).
The TGT is encrypted with the KDC's secret key (krbtgt hash in Windows).
Service tickets are encrypted with the target service's long-term key.
Kerberos relies on time synchronization with a default clock skew of 5 minutes.
Common attacks: Golden Ticket (forged TGT), Silver Ticket (forged service ticket), Kerberoasting (crack service tickets), AS-REP Roasting (crack AS-REP without preauth), Pass-the-Ticket (reuse stolen tickets).
Defenses: Protect krbtgt, use strong service account passwords, enable preauthentication, monitor Event IDs 4768 and 4769, disable RC4 encryption.
These come up on the exam all the time. Here's how to tell them apart.
Kerberos
Uses ticket-based authentication with symmetric keys
Provides mutual authentication (client and server verify each other)
Prevents replay attacks using timestamps and authenticators
Requires a trusted third party (KDC)
Default in modern Windows domains (since Windows 2000)
NTLM
Uses challenge-response with password hashes
Only authenticates the client to the server (not mutual by default)
Vulnerable to relay attacks (e.g., NTLM relay)
Does not require a third party; uses local SAM or domain controller
Legacy protocol, still used for backward compatibility
Mistake
Kerberos uses asymmetric encryption (public/private keys).
Correct
Kerberos uses symmetric encryption. The client and KDC share a secret key derived from the user's password, and session keys are symmetric. There is no public-key infrastructure involved, though Kerberos extensions like PKINIT allow asymmetric authentication.
Mistake
The TGT is encrypted with the user's password.
Correct
The TGT is encrypted with the KDC's secret key (the krbtgt account's password hash in Windows). The user cannot decrypt the TGT; only the KDC can. The user's password is used to encrypt the session key in the AS-REP, not the TGT.
Mistake
Kerberos is only for Windows Active Directory.
Correct
Kerberos is a standard protocol (RFC 4120) used in many operating systems, including Linux, Unix, and macOS. It is the default authentication in Windows domains, but it is also used in other environments like MIT Kerberos and Heimdal.
Mistake
Kerberos eliminates the need for passwords entirely.
Correct
Kerberos still requires a password to initially authenticate. The password is used to derive the long-term key. Once authenticated, tickets are used, but the password is still needed if the TGT expires or if the user logs off.
Mistake
Kerberos tickets never expire.
Correct
Tickets have a limited lifetime (default 10 hours for TGT in Windows) and can be renewed. Expired tickets cannot be used and require re-authentication. This limits the window for replay attacks.
Kerberos uses UDP and TCP port 88 for KDC traffic. For password changes, it uses TCP port 464. The exam expects you to know port 88.
A Ticket-Granting Ticket (TGT) is obtained from the Authentication Service and is used to request service tickets from the Ticket-Granting Service. A service ticket is obtained from the TGS and is presented to a specific service to gain access. The TGT is encrypted with the KDC's key, while the service ticket is encrypted with the service's key.
A Golden Ticket attack occurs when an attacker gains access to the krbtgt account's password hash (e.g., via DCSync). They can then forge TGTs for any user, including domain admins, granting persistent, undetectable access. The forged TGT can have arbitrary lifetimes and user IDs. Defenders must reset the krbtgt password twice to invalidate all existing TGTs.
Kerberoasting is an attack where an attacker requests service tickets for service accounts (identified by SPNs) from the KDC. The service ticket is encrypted with the service account's NTLM hash. The attacker extracts the ticket and cracks the encrypted portion offline to recover the plaintext password. Defenses include using strong, complex passwords for service accounts and monitoring for anomalous TGS requests (Event ID 4769).
The authenticator is a data structure containing the client's identity and a timestamp, encrypted with the session key. It is sent along with the TGT (to TGS) or service ticket (to service). The recipient decrypts the authenticator and verifies the timestamp to ensure the message is recent, preventing replay attacks. The authenticator proves that the client possesses the session key.
Kerberos prevents replay attacks by including a timestamp in the authenticator. The recipient (KDC or service) checks that the timestamp is within a configurable skew (default 5 minutes). If the same authenticator is replayed later, the timestamp will be outside the window and the request is rejected. Additionally, the KDC and services may cache recent authenticators to detect duplicates.
AS-REP roasting targets user accounts that have the 'Do not require Kerberos preauthentication' option enabled. An attacker can send an AS-REQ for such an account without preauthentication, and the KDC will respond with an AS-REP containing encrypted data (including the session key encrypted with the user's key). The attacker can then crack this data offline to recover the user's password. Defenders should ensure preauthentication is enabled for all accounts.
You've just covered Kerberos Authentication Protocol — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.
Done with this chapter?