Identity Security: Kerberos Authentication & Attack Surface

Note

Executive Summary: Named after the mythical three-headed dog guarding the underworld, Kerberos is the default, ticket-based authentication protocol for Active Directory environments. Its primary design goal is to allow nodes communicating over an insecure network to prove their identity securely, without ever transmitting a plaintext password or an NTLM hash. However, its complex cryptographic architecture introduces a highly specific attack surface. For DFIR analysts, mastering the Kerberos ticket flow is mandatory to detect advanced persistence (Golden Tickets), credential theft (Kerberoasting), and modern relaying techniques.

1. The Three-Headed Dog: Architectural Components

Kerberos relies on a trusted third party known as the Key Distribution Center (KDC), a role fulfilled by the Active Directory Domain Controller (DC). The KDC is logically split into two services:

1. Authentication Service (AS): Verifies the user’s identity and issues the initial “master badge” (the TGT).
2. Ticket Granting Service (TGS): Issues specific access tickets to individual services (like a file share or a SQL database).

The Authentication Dance (6-Step Flow)

The Kerberos flow is a three-act cryptographic exchange.

1. AS-REQ (Authentication Service Request): The client initiates the logon by sending a request to the KDC. This request includes the username and a timestamp encrypted with a key derived from the user’s password.
2. AS-REP (Authentication Service Response): The KDC decrypts the timestamp using the user’s hash from ntds.dit. If successful, the KDC returns a Ticket Granting Ticket (TGT) (encrypted with the krbtgt account’s hash) and a Session Key (encrypted with the user’s hash).
3. TGS-REQ (Ticket Granting Service Request): To access a specific service (e.g., CIFS/fileserver.corp.local), the client sends the TGT, an Authenticator (timestamp encrypted with the Session Key), and the target Service Principal Name (SPN) to the KDC.
4. TGS-REP (Ticket Granting Service Response): The KDC decrypts the TGT and validates the Authenticator. It then issues a Service Ticket encrypted with the target service account’s hash, and sends it back to the client.
5. AP-REQ (Application Request): The client presents the encrypted Service Ticket to the target server.
6. AP-REP (Application Response - Optional): The target server decrypts the Service Ticket using its own hash. If successful, access is granted. Mutual authentication occurs if the server sends back an encrypted confirmation.

2. The Kerberos Attack Surface

While highly secure against sniffing, Kerberos’s reliance on symmetric cryptography and ticketing introduces devastating logical vulnerabilities.

A. Offline Cracking: Kerberoasting

Any authenticated domain user can request a Service Ticket (TGS-REQ) for any service with a registered SPN. The KDC will oblige and return a Service Ticket encrypted with the service account’s password hash.

• The Attack: The adversary extracts this encrypted ticket from memory and uses offline brute-force tools (Hashcat, John the Ripper) to crack the service account’s password.
• DFIR Focus: Look for abnormal spikes in Event ID 4769 for highly privileged service accounts requested by standard user accounts.

B. Complete Domain Domination: Golden & Silver Tickets

If an attacker compromises a Domain Controller, they can extract the ultimate cryptographic secrets from the ntds.dit database or LSASS memory.

• Golden Ticket: The attacker steals the NT Hash of the krbtgt account. With this, they can forge their own TGTs for any user (including Domain Admins) with arbitrary lifespans. This bypasses the AS-REQ phase entirely.
• Silver Ticket: The attacker steals the hash of a specific computer or service account. They can forge Service Tickets to access only that service, bypassing the KDC entirely.

C. Advanced Vector (2025): Reflective Kerberos Relay

For years, NTLM was the primary target for relay attacks, while Kerberos was considered immune due to SPN validation and mutual authentication. However, recent 2025 research by RedTeam Pentesting demonstrated Reflective Kerberos Relay Attacks. If a service lacks strict Extended Protection for Authentication (EPA) or SMB signing, an attacker can coerce a victim into authenticating to an attacker-controlled machine, and “reflect” the Kerberos AP-REQ back to a different service on the victim’s own machine, bypassing traditional relay mitigations.

3. DFIR Telemetry: The Event Log Rosetta Stone

To track Kerberos abuse, DFIR analysts must audit specific Event IDs on the Domain Controllers.

Event ID	Description	Threat Hunting Context
4768	TGT Requested (AS-REQ/REP)	The baseline for a successful login. Missing 4768 events followed by subsequent ticket activity indicate forged tickets.
4769	Service Ticket Requested (TGS-REQ)	Critical for tracking Lateral Movement and Kerberoasting. A sudden spike in 4769 events requesting RC4 encryption (0x17) is highly suspicious.
4771	Pre-Authentication Failed	Generated when the AS-REQ timestamp decryption fails (usually a bad password). A massive storm of 4771 events from a single IP across multiple accounts is the definitive signature of Password Spraying.
4770	Ticket Renewed	TGTs have a lifespan (default 10 hours) and can be renewed. Anomalous renewal requests for highly sensitive accounts outside working hours warrant investigation.
4772	Ticket Request Failed	Generic failure (e.g., severe clock skew between client and DC, or disabled accounts). Useful for diagnosing IT issues rather than direct attacks.

4. Threat Hunting Queries

KQL (Golden Ticket Detection)

hunt_golden_ticket_anomalies.kql

// Detects potential Golden Ticket usage by finding TGS requests (4769)
// that lack a preceding TGT request (4768) within a logical timeframe.
let TGT_Requests = SecurityEvent
| where EventID == 4768
| project Account, TargetLogonId, TimeGenerated;

SecurityEvent
| where EventID == 4769
// Filter for administrative or critical service access
| where Account has_any ("admin", "svc_")
// Join to find TGS requests missing a recent TGT
| join kind=leftanti (TGT_Requests) on Account
| project TimeGenerated, Computer, Account, ServiceName, TicketOptions, TicketEncryptionType
| sort by TimeGenerated desc

Splunk (Password Spraying)

hunt_kerberos_password_spray.spl

# Detects Password Spraying campaigns targeting Kerberos pre-authentication (4771)
index=windows sourcetype="WinEventLog:Security" EventCode=4771
# Filter for bad password failure code
| search Status="0x18"
| bucket _time span=5m
| stats dc(TargetUserName) as UniqueAccountsTargeted, count by ClientAddress, _time
# Alert if a single IP targets more than 15 unique accounts in 5 minutes
| where UniqueAccountsTargeted > 15
| sort - _time

5. Mitigation and Hardening

1. Enforce AES Encryption: Disable the legacy RC4 encryption cipher (0x17) across the domain. Modern Kerberos should strictly utilize AES-256 (0x12). Attackers forging tickets often default to RC4 because it requires a simple NTLM hash rather than complex AES keys.
2. Regular krbtgt Rotation: The only way to invalidate a Golden Ticket is to change the krbtgt account password twice (to clear the password history). This should be a routine architectural practice, not just a post-incident reaction.
3. Implement EPA & SMB Signing: To mitigate the emerging Reflective Kerberos Relay attacks, enforce Extended Protection for Authentication (EPA) on IIS/LDAP servers and mandate SMB signing across all endpoints.

---

Sources & References

• SANS Institute: Kerberos & Attacks Cheat Sheet
• Sycope (2025): Golden Ticket Attack: Detecting Kerberos Attacks and Securing Active Directory
• RedTeam Pentesting (2025): Reflective Kerberos Relay Attack (PDF)
• Related Analysis: NTLM Authentication Flaws & Relaying