Golden Ticket Attack

What It Is

• A Golden Ticket is a forged Kerberos Ticket Granting Ticket (TGT) created using the NTLM hash of the KRBTGT account — the root of trust for all Kerberos authentication in an Active Directory domain.
• The technique maps to MITRE ATT&CK T1558.001 (Steal or Forge Kerberos Tickets) for Credential Access and T1098 (Account Manipulation) for Persistence.
• The name comes from Charlie and the Chocolate Factory — except here the prize is unrestricted access to every system in the domain.

How Golden Tickets Work — The Mechanics

Step 1: Steal the KRBTGT Hash

The attacker needs the NTLM hash of the KRBTGT account. To get it, they must compromise a Domain Controller or extract it from a backup.

How attackers get the KRBTGT hash:

Step 2: Forge the TGT

Using the KRBTGT hash, the attacker can create a TGT that Kerberos will trust implicitly. The forged TGT includes:

Step 3: Authenticate with the Forged Ticket

The attacker uses Mimikatz’s kerberos::golden command to create the ticket, then kerberos::ptt (Pass the Ticket) to inject it into their current session:

mimikatz# kerberos::golden /domain:corp.local /sid:S-1-5-21-xxxx /rc4:KRBTGT_HASH /user:Administrator /id:500 /groups:512,513,518,519,520 /ptt

From this point, the attacker can access any resource in the domain as a Domain Admin — without any further authentication. No Event IDs are generated on the target servers because Kerberos validates the TGT against the DC… and the DC trusts the forged ticket.

Detection — No Silver Bullet, But These Signals Help

Golden Ticket attacks are hard to detect because the forged TGT looks valid to Kerberos. But there are specific anomalies that signal a forged ticket is in use.

Detection 1 — Unusual Ticket Lifetime (Event ID 4768)

The most reliable detection signal. Legitimate TGTs have a lifetime of 10 hours (default Windows Kerberos policy). A forged TGT can last up to 10 years.

What to look for: Event ID 4768 (Kerberos Authentication Service — TGT Request) with a TicketOptions field indicating a lifetime longer than 10 hours.

SPL query — detect anomalous TGT lifetime:

index=windows sourcetype="WinEventLog:Security" EventCode=4768
| rex field=Message "Ticket Lifetime: (?<lifetime_hours>\d+)h"
| where lifetime_hours > 10 AND lifetime_hours < 87600 (max ~10 years)
| stats values(TargetUserName) as RequestedUser, values(TicketOptions) as Options, values(lifetime_hours) as Lifetime by ClientAddress, AccountName
| eval alert = "CRITICAL — abnormal TGT lifetime of " . Lifetime . "h from " . ClientAddress . " (normal: 10h)"
| table _time, ClientAddress, AccountName, RequestedUser, Lifetime, alert

Note: Event 4768 is high-volume. Filter by lifetime > 10 hours to reduce noise. Some admin tools may request tickets with slightly different lifetimes — baseline your environment first.

Detection 2 — Impossible Authentication Source

A Golden Ticket does not require the attacker to authenticate to the DC. The ticket is forged offline and injected directly into the Kerberos session. This means:

• Event 4624 (successful logon) on the target server will show the forged user identity
• But there will be no corresponding authentication event (4768) from the attacker’s workstation
• The attacker appears to be “authenticated” without any authentication record

What to look for: A successful logon (4624) for a privileged user (Domain Admin) from a workstation IP that does not have a corresponding TGT request (4768) for that user in the same time window. The user logged in without ever asking for a ticket.

SPL query — detect logon without corresponding TGT request:

index=windows sourcetype="WinEventLog:Security" EventCode=4624
| search TargetUserName="Administrator" OR TargetUserName="krbtgt" OR TargetUserSid="-500" OR TargetUserSid="-519"
| eval time_window = bin(_time, 60)
| join type=left time_window, TargetUserName [search index=windows sourcetype="WinEventLog:Security" EventCode=4768 | eval time_window = bin(_time, 60) | stats values(TargetUserName) as AuthUsers by time_window, TargetUserName]
| where isnull(AuthUsers)
| eval alert = "CRITICAL — possible Golden Ticket: " . TargetUserName . " logged on from " . WorkstationName . " without TGT request"
| table _time, TargetUserName, WorkstationName, IpAddress, alert

Detection 3 — Same KRBTGT Hash, Multiple Domains

In multi-domain forests, the KRBTGT account has a different hash per domain. But some attackers forge tickets across domains using a single KRBTGT hash.

What to look for: Event 4768 for a user in Domain A authenticating to a resource in Domain B, where the KRBTGT hash used in the authentication matches Domain A’s hash but the resource is in Domain B. This is technically normal (cross-domain trust), but if the authentication path is unusual, investigate.

Detection 4 — Anomalous TGS Requests (Event ID 4769)

After the forged TGT is used, the attacker requests TGS tickets for resources. If the forged user suddenly starts accessing resources they have never accessed before, this is anomalous.

What to look for: A user with Domain Admin privileges requesting TGS tickets for dozens of servers they have never accessed in their normal work pattern.

Detection 5 — Privileged User Not Tracked in Jump Box Audit

A Golden Ticket user does not need to log into a jump box or bastion host. If you see privileged access from a workstation that should not have direct admin access to the target, correlate with jump box logs.

Response to Golden Ticket — The Only Fix

A Golden Ticket can only be invalidated by resetting the KRBTGT password twice. This is the only remediation that works:

1. Reset KRBTGT password once — this invalidates existing TGTs that were signed with the old hash. However, because of Kerberos replication delays and ticket renewal windows, a single reset may not fully purge the environment.
2. Wait for replication — allow 10-24 hours for the new hash to replicate to all Domain Controllers.
3. Reset KRBTGT password a second time — ensures all tickets signed with either the original or the first-reset hash are invalidated.

How to perform the KRBTGT reset:

# Reset KRBTGT password (run on a Domain Controller)
Reset-ADAccountPassword -Identity krbtgt -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "NewPassword1" -Force)

# Force replication to all DCs
repadmin /syncall /AdeP

# After 10-24 hours, reset again
Reset-ADAccountPassword -Identity krbtgt -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "NewPassword2" -Force)

Before resetting, verify:

• Are any services using the KRBTGT hash for Kerberos trust relationships? Some trusts rely on the KRBTGT hash. Test trust functionality after the first reset.
• Are all Domain Controllers healthy and replicating? A broken DC will not pick up the new password, leaving old tickets valid on that DC.
• Do you have a rollback plan? Maintain a backup of the current KRBTGT hash (stored securely) in case the reset causes authentication failures.

Prevention

Related

• Kerberoasting — detection and response for T1558.003 techniques
• Pass-the-Hash — detection and response for T1550.002 techniques
• Active Directory Basics — covers the active directory basics concepts
• Credential Theft Incident Response — detection and response for T1558.001, T1003.001, T1134 techniques
• Mimikatz — detection and response for T1003 techniques

Sources

• CrowdStrike — Golden Ticket Attack
• MITRE ATT&CK T1558.001
• MITRE ATT&CK T1098
• Microsoft — KRBTGT Reset
• Microsoft — Kerberos Golden Ticket Detection