How to detect Golden Ticket attacks

Quick refresher: what makes Golden Tickets special

Kerberos is designed so clients obtain a TGT from the KDC (your domain controller), then use that TGT to request service tickets (TGS) for specific services (file servers, SQL, HTTP SPNs, etc.). If you want the foundations of the protocol clear before you hunt anomalies, review: NTLM and Kerberos authentication protocols explained.

A Golden Ticket breaks the normal trust chain because the attacker can create a valid-looking TGT offline. Once they have it, they can request service tickets and authenticate to services without performing a normal interactive sign-in flow.

Typical prerequisites

• KRBTGT secret exposure (password hash / key material). This usually follows Domain Admin compromise or DC compromise.
• Time (persistence). Attackers often mint long-lived tickets or repeatedly re-mint tickets.
• Operational stealth. Golden Tickets can look like legitimate Kerberos usage unless you collect the right signals.

Detection works best when you combine: (1) domain controller Kerberos logs, (2) server/workstation logon events, and (3) identity threat detection (like Microsoft Defender for Identity) and SIEM correlation.

Step 1: Turn on the right auditing (otherwise you’re blind)

Golden Ticket hunting depends on Kerberos events recorded on domain controllers. At minimum, enable Advanced Audit Policy for:

• Account Logon → Audit Kerberos Authentication Service (TGT issuance: Event ID 4768)
• Account Logon → Audit Kerberos Service Ticket Operations (TGS requests: Event ID 4769)
• Logon/Logoff → Audit Logon (host logons: Event ID 4624; privilege use: 4672)

If you’re building a modern detection pipeline, forward these DC events to a SIEM and keep enough retention to spot low-and-slow abuse. If you’re using Microsoft Defender for Identity (MDI), it can ingest relevant signals directly from DC sensors—see: Event collection with Microsoft Defender for Identity and Microsoft Defender for Identity: a comprehensive overview.

Baseline your Kerberos policy (it becomes your “physics”)

Many Golden Ticket detections rely on “this ticket lived longer than policy allows” or “this encryption type is abnormal.” Make sure you actually know your baseline Kerberos constraints (and don’t forget fine-grained policies or legacy exceptions). A helpful foundation on how policies impact authentication behavior: Active Directory account policy: an introduction.

Step 2: Know the core events and what they mean

Event ID 4768 (TGT requested)

Logged on a DC when the KDC issues a Ticket Granting Ticket. In normal life, users and computers generate these as they authenticate and renew.

Event ID 4769 (service ticket requested)

Logged on a DC when a client requests a service ticket for an SPN (CIFS, HTTP, MSSQLSvc, HOST, etc.). This happens constantly in real environments.

Event ID 4624 + 4672 (host-side confirmation)

4624 on the target server/workstation shows an actual logon session. 4672 (“special privileges assigned”) is a high-signal companion when the principal is (or claims to be) privileged. Golden Tickets often show up as Kerberos logons on many servers within a short window.

If you need to refresh the difference between authentication vs authorization signals (and why forged identity tokens can still authorize), see: User authentication and authorization in AD.

Step 3: High-signal detection patterns for Golden Tickets

1) “4769 without a preceding 4768” correlation

A practical hunt is to look for service ticket requests (4769) where you cannot find a corresponding TGT issuance (4768) for the same user/source within a reasonable lookback window. The reasoning: a client can’t request a TGS without a TGT—but if the TGT was forged offline, the DC never recorded issuing it.

• Best use: spotting forged TGT usage that didn’t originate from a legitimate KDC-issued TGT on your DCs.
• Reality check: this is not perfect. Log gaps, retention windows, DC coverage, and clock issues can create false positives.
• Make it stronger: require multiple 4769 events across multiple SPNs/servers from the same source host.

2) Ticket lifetime anomalies (the “time anomaly” signal)

A classic Golden Ticket move is minting a ticket with an extremely long lifetime (days, months, even years). While attackers can also mint tickets that mimic your policy, lifetime anomalies remain a strong signal in many environments.

• Hunt idea: identify identities using Kerberos where the implied session persists beyond your “Maximum lifetime for user ticket”.
• MDI helps: Defender for Identity has a specific alert family for Suspected Golden Ticket usage, including time anomaly detections.
• Common false positive: clock skew and time sync issues (domain time hierarchy problems) can mimic “time anomaly”.

3) Nonexistent or “impossible” accounts

Forged tickets can claim to be users that don’t exist (or users that were deleted). If you see Kerberos activity from a principal that has no directory object, treat it as a high-severity signal.

• Hunt idea: user appears in 4769/4624, but there is no matching AD object (or it’s disabled/deleted).
• MDI detection: “Suspected Golden Ticket usage (nonexistent account)” is designed for this scenario.

4) Encryption downgrade anomalies (RC4 / weaker cipher suddenly appears)

Golden Tickets are often generated with specific encryption types (especially in mixed/legacy environments). If your estate has largely moved to AES, a sudden RC4 pattern—especially from a host/user that historically uses AES—should light up investigation.

• Hunt idea: alert on unusual “Ticket Encryption Type” values in 4768/4769 compared to the same host/user baseline.
• MDI detection: “Suspected Golden Ticket usage (encryption downgrade)” flags a weaker cipher that deviates from learned behavior.

5) Privilege doesn’t match reality

Golden Tickets often impersonate highly privileged users. If you see logons that “look privileged” (4672, admin-only resource access, sudden lateral movement to Tier 0 systems) but the real user is not an admin, or the logon occurs from an unusual workstation, you may be seeing ticket abuse.

• Hunt idea: privileged logon events (4672) from non-PAW endpoints, kiosks, or user laptops.
• Hunt idea: Domain Admin access to many servers in a short time, especially outside maintenance windows.

Step 4: Practical hunts (PowerShell + SIEM-style logic)

PowerShell: pull 4768/4769 from a DC and look for missing TGTs

The following is a simple starting point for lab/triage use (not a production-grade correlation engine). Run on a DC (or against a DC’s Security log) with appropriate permissions.

# Look back 2 hours for Kerberos events
$start = (Get-Date).AddHours(-2)

$ev4768 = Get-WinEvent -FilterHashtable @{
  LogName = 'Security'
  Id      = 4768
  StartTime = $start
} | Select-Object TimeCreated, @{n='User';e={$_.Properties[0].Value}}, @{n='Client';e={$_.Properties[9].Value}}

$ev4769 = Get-WinEvent -FilterHashtable @{
  LogName = 'Security'
  Id      = 4769
  StartTime = $start
} | Select-Object TimeCreated, @{n='User';e={$_.Properties[0].Value}}, @{n='Service';e={$_.Properties[4].Value}}, @{n='Client';e={$_.Properties[8].Value}}

# Naive correlation: 4769 where we can't find a 4768 for the same user+client in the same window
$missingTgt = foreach ($tgs in $ev4769) {
  $hasTgt = $ev4768 | Where-Object { $_.User -eq $tgs.User -and $_.Client -eq $tgs.Client }
  if (-not $hasTgt) { $tgs }
}

$missingTgt | Sort-Object TimeCreated | Format-Table -AutoSize

Notes:

• The event property indexes can vary by OS build and event schema updates. Validate the fields in your environment before operationalizing.
• This logic strengthens when you enrich with host-side 4624 and known admin workstation lists.

SIEM logic idea: “TGS burst from a workstation that never requested a TGT”

In a SIEM, you typically:

1. Normalize 4768 and 4769 from all DCs.
2. Join 4769 to 4768 by (account, source host/IP) with a 1–10 hour window.
3. Flag unmatched 4769 events, then cluster by source host and count distinct SPNs/targets.
4. Escalate when: high privilege is implied, sensitive servers are targeted, or activity occurs outside baselines.

Step 5: Use Defender for Identity signals (if you have it)

Microsoft Defender for Identity includes multiple Golden Ticket detections under the “Suspected Golden Ticket usage” family (for example: time anomaly, nonexistent account, ticket anomaly, and encryption downgrade). When these trigger, treat them as a “pull the thread” moment:

• Identify the source computer (where the forged ticket was used).
• List impacted servers/services (SPNs and targets hit by the service tickets).
• Confirm the account reality (does the user exist, is it privileged, is it a honeytoken/sensitive tag?).
• Check for adjacent signals (credential dumping, replication abuse/DCSync indicators, DC access from unusual hosts).

If you’re still building your identity detection maturity, start with your MDI telemetry fundamentals and coverage: Configure gMSA for Defender for Identity (ensures sensor services run securely and reliably).

Incident response: what to do when you suspect a Golden Ticket

Golden Ticket evidence often implies KRBTGT secret compromise. Treat it as a domain-level incident.

Immediate containment

• Isolate the suspected source host(s) from the network (the system using forged tickets is often compromised).
• Protect Tier 0: restrict access to domain controllers and admin-only management planes while you investigate.
• Increase logging: ensure DC Security logs aren’t rolling over; verify forwarding is functioning.

Eradication and recovery (domain hygiene)

• Reset KRBTGT twice, with replication time between resets, following Microsoft guidance for your environment and change windows.
• Reset passwords/keys for exposed privileged accounts and review privileged group membership changes.
• Hunt for persistence beyond Golden Tickets (new admin accounts, delegation abuse, scheduled tasks, GPO startup scripts, etc.).

Validation

• Continue monitoring for the same unmatched 4769 patterns, time anomalies, and encryption downgrades.
• Confirm no new Golden Ticket alerts trigger after KRBTGT rotations and endpoint remediation.

Common false positives (and how to reduce them)

• Clock skew / time service issues: can create “time anomaly” style alerts. Verify domain time hierarchy and NTP sources.
• Log gaps: if you only ingest some DCs, your “4769 without 4768” correlation will be noisy.
• Legacy crypto pockets: older systems may legitimately request weaker encryption. Track and plan remediation.
• Service accounts and automation: can generate high-volume Kerberos patterns. Baseline by host + account.

Golden Ticket detection checklist

• ✅ Kerberos auditing enabled on all DCs (4768, 4769) and forwarded to SIEM/MDI
• ✅ Host logon auditing available on sensitive servers (4624, 4672)
• ✅ Baselines defined: normal Kerberos encryption types, normal admin workstation sources, normal service ticket volume
• ✅ Correlation hunts: 4769 without 4768 + clustering by source, SPN, target set
• ✅ Alerting for time anomalies, nonexistent accounts, and encryption downgrades
• ✅ IR playbook ready: isolate source hosts, investigate DC exposure, reset KRBTGT twice, validate post-recovery