Kerberos Attacks Deep Dive

Kerberos Authentication — The Foundation These Attacks Exploit

Kerberos operates on a ticket-based authentication model with three main participants: the client, the service server, and the Key Distribution Center (KDC) running on Domain Controllers.

The standard Kerberos flow:

1. AS-REQ / AS-REP — Client requests a Ticket Granting Ticket (TGT) from the KDC. The KDC responds with a TGT encrypted with the user’s password hash.
2. TGS-REQ / TGS-REP — Client requests a Ticket Granting Service (TGS) ticket for a specific service. The KDC responds with a TGS encrypted with the target service account’s NTLM hash.
3. AP-REQ / AP-REP — Client presents the TGS to the service server, which decrypts it with its own NTLM hash and grants access.

Each of these steps that involves encrypted material is also a potential attack surface. The following sections cover the five major Kerberos attack techniques, from highest to lowest privilege impact.

Golden Ticket Attack — Forging the TGT

A Golden Ticket is a forged TGT created using the NTLM hash of the KRBTGT account — the root signing key for all Kerberos authentication in the domain.

How It Works

The attacker needs the KRBTGT hash, typically obtained via DCSync using Mimikatz (lsadump::dcsync /user:krbtgt). With this hash, they forge a TGT that Kerberos implicitly trusts because the KDC uses the KRBTGT hash to verify all TGTs.

What the attacker controls in a forged TGT:

Key differentiator from Silver Tickets: A Golden Ticket works against any resource in the domain because it is a root trust credential. A Silver Ticket only works against a specific service.

Detection

Primary indicator — Anomalous TGT lifetime (Event ID 4768):

Default Windows TGT lifetime is 10 hours. Golden tickets often have lifetimes of days, months, or years.

index=windows EventCode=4768
| eval ticket_hours = (TicketEndTime - TicketStartTime) / 3600000
| where ticket_hours > 12
| eval alert = "CRITICAL — TGT with lifetime " . round(ticket_hours, 1) . " hours — possible Golden Ticket for " . Account_Name
| table _time, Account_Name, TicketStartTime, TicketEndTime, ticket_hours, alert

Secondary indicator — RC4 encryption in AES-dominant environment:

Modern Windows defaults to AES256. Golden tickets forged with RC4 stand out.

For full details, see the Golden Ticket Attack article.

Silver Ticket Attack — Forging the TGS

A Silver Ticket is a forged TGS ticket for a specific service. Unlike a Golden Ticket, it does not require the KRBTGT hash — only the NTLM hash of the target service account (e.g., the MSSQLSvc account, the CIFS account, or the HOST account).

How It Works

1. Attacker obtains the NTLM hash of a service account (e.g., via LSASS dump, Kerberoasting, or domain compromise)
2. Attacker forges a TGS ticket for the specific service using that hash
3. The target service decrypts the forged TGS and accepts it as legitimate

Key differentiator from Golden Tickets:

Detection

Silver Tickets are harder to detect than Golden Tickets because they do not generate anomalous TGT events. Detection focuses on anomalous logons:

• Event ID 4624 (successful logon) with a service account without a preceding Event ID 4769 (TGS request)
• Kerberos service ticket usage from an unexpected source IP
• Service account logon during unusual hours

Kerberoasting — Cracking Service Account Passwords

Kerberoasting exploits the Kerberos TGS request flow: any domain user can request a TGS for any service account with an SPN, and the TGS is encrypted with the service account’s NTLM hash.

How It Works

1. Enumerate user accounts with SPNs: setspn -Q */*
2. Request TGS tickets for each service account: Rubeus kerberoast
3. Extract the encrypted ticket portion and crack offline with Hashcat: hashcat -m 13100 hashes.txt wordlist.txt
4. Use the cracked password for lateral movement

Detection

Primary — Anomalous TGS request volume (Event ID 4769):

A normal user requests TGS tickets for the services they actually use. Kerberoasting generates a burst of TGS requests for many different SPNs in a short window.

SPL query:

index=windows EventCode=4769
| search ServiceName!="krbtgt/*"
| stats dc(ServiceName) as UniqueServices, count as TotalRequests by AccountName, ClientAddress
| where UniqueServices > 10
| eval alert = "HIGH — possible Kerberoasting: " . AccountName . " requested " . UniqueServices . " TGS tickets"
| sort - UniqueServices

Prevention

• Group Managed Service Accounts (gMSAs) — passwords are 128-bit random and auto-rotated
• Strong service account passwords (30+ characters)
• AES-only Kerberos encryption (disable RC4) — makes cracking 4000x slower

For full details, see the Kerberoasting article.

AS-REP Roasting — Targeting Accounts Without Pre-Authentication

AS-REP Roasting targets user accounts that have Kerberos pre-authentication disabled. Pre-authentication is the step where the client proves knowledge of the password before the KDC issues a TGT. Without it, an attacker can request a TGT for any unprotected account and receive an AS-REP message encrypted with the user’s password hash — crackable offline.

How It Works

1. Enumerate users with DONT_REQ_PREAUTH flag: Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true}
2. Request AS-REP for each unprotected account: Rubeus asreproast or impacket-GetNPUsers
3. Crack the Kerberos AS-REP hash offline: hashcat -m 18200 hashes.txt wordlist.txt

Detection

Primary indicator — Event ID 4768 without pre-authentication:

Modern Windows enables pre-authentication by default. An Event ID 4768 for a user who normally uses pre-auth but suddenly has an AS-REQ without it is suspicious.

SPL query:

index=windows EventCode=4768
| search PreAuthType!="0" (0 = pre-authentication not required)
| eval alert = "HIGH — AS-REP Roasting attempt for " . Account_Name . " — pre-authentication not required"
| table _time, Account_Name, ServiceName, ClientAddress, alert

Note: Some legacy Unix/Linux services may legitimately disable pre-authentication. Baseline your environment before alerting on every event.

Prevention

• Enable Kerberos pre-authentication for all user accounts
• Regular audit of DoesNotRequirePreAuth flag
• Monitor Event ID 4768 for accounts that should have pre-auth enabled

Kerberos Delegation Abuse

Kerberos delegation allows a service to impersonate a user to access another service. This is a legitimate feature used in multi-tier applications, but it can be abused if misconfigured.

Types of Delegation Abuse

Unconstrained Delegation — The Most Dangerous

When a server has unconstrained delegation enabled, any user who authenticates to that server sends their TGT along with the TGS. If that server is compromised, the attacker can extract TGTs of all users who authenticated to it — including Domain Admins authenticating to the server.

Detection — find servers with unconstrained delegation:

Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation, ServicePrincipalName
| select Name, Enabled, ServicePrincipalName

Prevention

• Avoid unconstrained delegation entirely. Use constrained delegation with protocol transition where needed.
• Protect high-value servers (especially DCs) from accepting delegated authentication from unknown services.
• Use Group Policy to disable delegation where not required.

Comprehensive Detection Summary

Related

• Golden Ticket Attack — detection and response for T1558.001 techniques
• Kerberoasting — detection and response for T1558.003 techniques
• Active Directory Basics — covers the active directory basics concepts
• Active Directory Compromise Response — detection and response for T1558 techniques
• Mimikatz — detection and response for T1003 techniques

Sources

• MITRE ATT&CK T1558 — Steal or Forge Kerberos Tickets
• Microsoft — Kerberos Authentication Overview
• Microsoft — Kerberos Delegation
• CrowdStrike — Kerberos Attacks
• Harmj0y — Kerberos Attack and Defense