Golden Tickets, Silver Tickets, and Diamond Tickets: Forged Kerberos and How to Detect Them

Forged Kerberos tickets are one of the most powerful persistence techniques in Active Directory environments because a valid-looking ticket grants access without touching the domain controller after it is created. Golden Tickets specifically, forged TGTs using the krbtgt account hash, have effectively unlimited lifetimes and grant access to any service in the domain. Detection requires understanding what a legitimate ticket looks like versus a forged one, which requires telemetry that most environments do not collect by default.

Golden Tickets

A Golden Ticket is a forged Ticket Granting Ticket (TGT) signed with the krbtgt account’s NTLM hash. Because the KDC (domain controller) trusts its own signature, any ticket correctly signed with the krbtgt hash is accepted as valid. An attacker who has the krbtgt hash (from DCSync or NTDS.DIT extraction) can forge TGTs with any username, any group membership, and any lifetime, typically set to 10 years.

// Golden Ticket creation (Mimikatz - understanding the fields for detection)
// kerberos::golden /user:Administrator /domain:corp.local
// /sid:S-1-5-21-... /krbtgt:[hash] /id:500 /groups:512,519
// /startoffset:0 /endin:600 /renewmax:10080 /ptt

// Fields that differ from legitimate tickets and are detectable:
// 1. Ticket lifetime: legitimate TGTs are 10 hours max, Golden is often 10 years
// 2. The SID in the ticket may not match any real account if using a fake username
// 3. No corresponding AS-REQ/AS-REP event on the DC (ticket was created offline)
// 4. The ticket may contain SID history with privileged SIDs

Golden Ticket detection: the missing AS-REQ

// When a user legitimately authenticates, the DC logs:
// Event 4768: Kerberos authentication service request (AS-REQ/AS-REP)
// Event 4769: Service ticket request (TGS-REQ/TGS-REP)
// Event 4770: Kerberos service ticket renewed

// With a Golden Ticket, there is NO Event 4768 because the TGT was forged offline
// The attacker goes straight to using it (generating Event 4769) without an AS-REQ

// Correlation: find 4769 events with no preceding 4768 in the same session
index=wineventlog EventCode=4769 earliest=-1h
 Account_Name!="*$" // exclude machine accounts
| join type=left max=1 Account_Name [
 search index=wineventlog EventCode=4768 earliest=-1h
 | stats max(_time) AS last_as_req by Account_Name
]
| eval has_as_req = if(isnotnull(last_as_req) AND last_as_req > relative_time(now(), "-4h"),
 "yes", "NO_AS_REQ")
| where has_as_req="NO_AS_REQ"
| table _time, Account_Name, ServiceName, IpAddress, has_as_req

// Golden Ticket detection: impossible ticket lifetime
// Legitimate TGTs have a maximum 10-hour lifetime (configurable, usually 10h)
// Golden Tickets are often forged with 10-year (87,600 hour) lifetimes

// This requires parsing the Kerberos ticket itself, not just the event log
// Microsoft-Windows-Security-Auditing captures ticket expiry in some events

// Sigma rule for anomalous ticket lifetime
title: Kerberos Ticket With Abnormal Lifetime
logsource:
 product: windows
 service: security
detection:
 selection:
 EventID: 4769
 condition: selection
 // Post-processing: extract TransitedServices field
 // Check TicketOptions for unusually long lifetimes
level: medium

Silver Tickets

A Silver Ticket is forged for a specific service rather than the entire domain. It is signed with the service account’s NTLM hash rather than krbtgt. Because Silver Tickets are service-specific, no KDC contact is needed at all when using them, the target service validates the ticket using its own secret. This makes Silver Tickets harder to detect because they generate no DC events.

// Silver Ticket targets common service types
// /target specifies the specific service host
// /service specifies the Kerberos service type (cifs, http, host, mssql, etc.)

// Silver Ticket for file server (CIFS):
// kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-...
// /target:fileserver.corp.local /service:cifs /rc4:[fileserver_computer_hash]

// Silver Ticket for SQL Server:
// /target:sqlserver.corp.local /service:MSSQLSvc

// What makes Silver Tickets detectable:
// 1. No Event 4768 (no TGT request - same as Golden Ticket issue)
// 2. No Event 4769 on the DC either (service ticket created offline)
// 3. The only Kerberos events are on the TARGET SERVICE, not the DC
// 4. Event 4624 logon on the target with Kerberos auth but no corresponding DC events

// Silver Ticket detection: 4624 with Kerberos auth and no DC ticket events
// Look for successful Kerberos logons to services with no DC validation trail

index=wineventlog EventCode=4624 earliest=-1h
 Authentication_Package="Kerberos"
 Logon_Type IN ("3", "10") // Network and RemoteInteractive
| join type=left max=1 Account_Name [
 search index=wineventlog EventCode=4769 earliest=-1h
 | stats count AS tgs_count by Account_Name
]
| where isnull(tgs_count) OR tgs_count=0
// Kerberos logon with no TGS request on the DC = potential Silver Ticket
| table _time, Account_Name, ComputerName, IpAddress, tgs_count

Diamond Tickets: evading Golden Ticket detection

Diamond Tickets address the main Golden Ticket detection gap (missing AS-REQ/AS-REP). Instead of forging a TGT from scratch, the attacker gets a legitimate TGT through normal AS-REQ, then decrypts it with the krbtgt hash, modifies the PAC (Privilege Attribute Certificate) to add privileged group memberships, re-encrypts it, and uses the modified ticket. The DC sees a normal AS-REQ/AS-REP, making the “missing 4768” detection fail.

// Diamond Ticket detection requires different approaches
// because the AS-REQ/AS-REP is present and legitimate

// Detection 1: PAC validation anomalies
// The modified PAC has the wrong PAC signature because it was re-signed
// Windows has PAC validation that can catch this if enabled

// Enable PAC validation on KDCs (Group Policy):
// Computer Configuration > Windows Settings > Security Settings >
// Local Policies > Security Options:
// "Domain controller: LDAP server signing requirements" = Require signing

// Event 4769 with Failure Code 0x1f = PAC verification failure
index=wineventlog EventCode=4769 earliest=-24h
 Failure_Code="0x1f"
| table _time, Account_Name, ServiceName, IpAddress

// Detection 2: Ticket encryption type anomaly
// Diamond tickets may use RC4 when the account normally uses AES
index=wineventlog EventCode=4769 earliest=-24h
 Ticket_Encryption_Type="0x17" // RC4
 Account_Name!="*$"
| join max=1 Account_Name [
 // Known RC4 accounts in your environment - should be empty or very small
 inputlookup rc4_only_accounts.csv | rename account AS Account_Name
]
| where isnull(account) // Account used RC4 but is not in the known-RC4 list
| table _time, Account_Name, ServiceName