Detecting Golden Ticket Attacks in Kerberos Logs

When to Use

• When KRBTGT account hash may have been compromised via DCSync or NTDS.dit extraction
• When hunting for forged Kerberos tickets used for persistent domain access
• After incident response reveals credential theft at the domain level
• When investigating impossible logon patterns (users logging in from multiple locations simultaneously)
• During post-breach assessment to determine if Golden Tickets are in use

Prerequisites

• Windows Security Event IDs 4768, 4769, 4771 on domain controllers
• Kerberos policy configuration knowledge (max ticket lifetime, encryption types)
• Domain controller audit policy enabling Kerberos Service Ticket Operations
• SIEM with ability to correlate Kerberos events across multiple DCs

Workflow

1. Monitor TGT Requests (Event 4768): Track Kerberos authentication service requests. Golden Tickets bypass the AS-REQ/AS-REP exchange entirely, so the absence of 4768 before 4769 is suspicious.
2. Detect Encryption Type Anomalies: Golden Tickets often use RC4 (0x17) encryption. If your domain enforces AES (0x12), any RC4 TGT is a red flag. Monitor TicketEncryptionType in Event 4769.
3. Check Ticket Lifetime Anomalies: Default Kerberos TGT lifetime is 10 hours with 7-day renewal. Golden Tickets can be forged with 10-year lifetimes. Detect tickets with durations exceeding policy.
4. Hunt for Non-Existent SIDs: Golden Tickets can include arbitrary SIDs (including non-existent accounts or groups). Correlate TGS requests against known AD SID inventory.
5. Detect TGS Without Prior TGT: When a service ticket (4769) appears without a preceding TGT request (4768) from the same IP/account, this may indicate a pre-existing Golden Ticket.
6. Monitor KRBTGT Password Age: Track when KRBTGT was last reset. If KRBTGT hash hasn't changed since a known compromise, Golden Tickets from that period remain valid.
7. Validate PAC Signatures: With KB5008380+ and PAC validation enforcement, domain controllers reject forged PACs. Monitor for Kerberos failures indicating PAC validation errors.

Detection Queries

Splunk -- RC4 Encryption in Kerberos TGS

index=wineventlog EventCode=4769
| where TicketEncryptionType="0x17"
| where ServiceName!="krbtgt"
| stats count by TargetUserName ServiceName IpAddress TicketEncryptionType Computer
| where count > 5
| sort -count

Splunk -- TGS Without Prior TGT

index=wineventlog (EventCode=4768 OR EventCode=4769)
| stats earliest(_time) as first_tgt by TargetUserName IpAddress EventCode
| eventstats earliest(eval(if(EventCode=4768, first_tgt, null()))) as tgt_time by TargetUserName IpAddress
| where EventCode=4769 AND (isnull(tgt_time) OR first_tgt < tgt_time)
| table TargetUserName IpAddress first_tgt tgt_time

KQL -- Golden Ticket Indicators

SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == "0x17"
| where ServiceName != "krbtgt"
| summarize Count=count() by TargetUserName, IpAddress, ServiceName
| where Count > 5

Common Scenarios

1. Post-DCSync Golden Ticket: After extracting KRBTGT hash, attacker forges TGT with Domain Admin SID, valid for months until KRBTGT is rotated twice.
2. RC4 Downgrade: Golden Ticket forged with RC4 encryption in an AES-only environment, detectable by encryption type mismatch.
3. Cross-Domain Golden Ticket: Forged inter-realm TGT used to pivot between AD domains/forests.
4. Persistence After Remediation: Golden Tickets surviving password resets because KRBTGT was only rotated once (both current and previous hashes are valid).

Output Format

Hunt ID: TH-GOLDEN-[DATE]-[SEQ]
Suspected Account: [Account using forged ticket]
Source IP: [Client IP]
Target Service: [SPN accessed]
Encryption Type: [RC4/AES128/AES256]
Anomaly: [No prior TGT/RC4 in AES environment/Extended lifetime]
KRBTGT Last Reset: [Date]
Risk Level: [Critical]

Verification Criteria

Confirm successful execution by validating:

• [ ] All prerequisite tools and access requirements are satisfied
• [ ] Each workflow step completed without errors
• [ ] Output matches expected format and contains expected data
• [ ] No security warnings or misconfigurations detected
• [ ] Results are documented and evidence is preserved for audit

Compliance Framework Mapping

This skill supports compliance evidence collection across multiple frameworks:

• SOC 2: CC7.2 (Anomaly Detection), CC7.3 (Incident Identification)
• ISO 27001: A.12.4 (Logging & Monitoring), A.16.1 (Security Incident Management)
• NIST 800-53: SI-4 (System Monitoring), IR-4 (Incident Handling), RA-5 (Vulnerability Scanning)
• NIST CSF: DE.AE (Anomalies & Events), DE.CM (Continuous Monitoring), DE.DP (Detection Processes)

Claw GRC Tip: When this skill is executed by a registered agent, compliance evidence is automatically captured and mapped to the relevant controls in your active frameworks.

Deploying This Skill with Claw GRC

Agent Execution

Register this skill with your Claw GRC agent for automated execution:

# Install via CLI
npx claw-grc skills add detecting-golden-ticket-attacks-in-kerberos-logs

# Or load dynamically via MCP
grc.load_skill("detecting-golden-ticket-attacks-in-kerberos-logs")

Audit Trail Integration

When executed through Claw GRC, every step of this skill generates tamper-evident audit records:

• SHA-256 chain hashing ensures no step can be modified after execution
• Evidence artifacts (configs, scan results, logs) are automatically attached to relevant controls
• Trust score impact — successful execution increases your agent's trust score

Continuous Compliance

Schedule this skill for recurring execution to maintain continuous compliance posture. Claw GRC monitors for drift and alerts when re-execution is needed.