How do you detect a golden ticket attack?

Collect Security events from every domain controller and correlate Event 4769 (service ticket request) with Event 4768 (TGT request): a service ticket for an account with no TGT history in your renewal window is the core indicator. Add signals for RC4 (0x17) encryption in an AES-enforced domain, accounts that do not exist in the directory, and ticket lifetimes beyond domain policy, which products such as Defender for Identity expose. Look backwards for DCSync or NTDS.dit access, since the attacker needed the krbtgt hash first. If you confirm a golden ticket, reset the krbtgt password twice with replication time between resets.

Detecting Golden Ticket Attacks: Forged TGTs and Kerberos Anomalies

A golden ticket is a forged Kerberos ticket-granting ticket signed with the krbtgt account’s key. The attacker mints it offline, so the domain controller never records the TGT request that would normally precede it. What the DC does log are the service ticket requests that follow, and those events can look wrong in several ways: no preceding 4768, an RC4 encryption type in an AES domain, an account that does not exist, or a lifetime far beyond policy.

Signals at a Glance

Signal	Where	ATT&CK
Service ticket request (4769) for an account with no TGT request (4768) in the window	Domain controller Security logs	T1558.001
Ticket encryption type 0x17 (RC4) where the account and domain support AES	4769 TicketEncryptionType	T1558.001
Ticket for an account name or SID that does not exist in AD	4769, 4624, 4672 + directory lookup	T1558.001
Ticket lifetime beyond domain policy (default 10 hours, 7-day renewal)	Defender for Identity, klist, EDR	T1558.001
Privileged logon (4672) from a host with no prior authentication trail	Security logs	T1078.002
krbtgt password last set long ago, or DCSync preceding the activity	Directory attributes, 4662	T1003.006

Correlating 4768 and 4769

A normal Kerberos flow produces a 4768 (TGT requested) before any 4769 (service ticket requested) for the same account. A forged TGT skips the first step. The logic is simple, but it only works if you collect events from every domain controller, since the TGT may have been issued by a different DC than the one that serves the 4769. This Splunk search finds accounts with service ticket activity and no TGT request in the same period:

index=wineventlog source="WinEventLog:Security" (EventCode=4768 OR EventCode=4769)
| eval acct=lower(mvindex(split(TargetUserName, "@"), 0))
| where NOT match(acct, "\$$")
| stats count(eval(EventCode=4768)) as tgt_requests
        count(eval(EventCode=4769)) as tgs_requests
        dc(host) as dcs values(IpAddress) as src_ips by acct
| where tgs_requests > 0 AND tgt_requests = 0
| sort - tgs_requests
`comment("tune/validate: needs all DCs in scope; long-lived tickets (renewals up to 7 days) can legitimately outlive a short search window")`

Because renewals and long-lived sessions can produce legitimate 4769 events without a recent 4768, use a window that covers your maximum ticket renewal period, or enrich with a 7-day baseline of accounts seen requesting TGTs.

Encryption Type, Identity and Lifetime

Public golden ticket tooling has historically defaulted to RC4 and to very long lifetimes. In a domain where AES is enforced, a service ticket for a user that is encrypted with RC4 is out of place. Add the encryption type as a second signal:

// KQL: RC4 service tickets for user accounts, and accounts not found in the directory
SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == "0x17"
| where ServiceName !endswith "$" and ServiceName != "krbtgt"
| extend acct = tolower(tostring(split(TargetUserName, "@")[0]))
| join kind=leftanti (
    IdentityInfo
    | summarize arg_max(TimeGenerated, *) by AccountName
    | project acct = tolower(AccountName)
  ) on acct
| project TimeGenerated, Computer, TargetUserName, ServiceName, IpAddress, TicketEncryptionType
// tune/validate: IdentityInfo coverage must be complete; also run the RC4 check without the join for AES-only domains.

Use Microsoft Defender for Identity (or an equivalent ITDR product) for ticket-content checks that Windows events do not expose, such as lifetime and PAC anomalies.
Hunt for the prerequisite. A golden ticket requires the krbtgt hash, so look backwards for DCSync (Event 4662 with replication GUIDs from a non-DC) or NTDS.dit access.
Remediate properly: reset the krbtgt password twice, with enough time between resets for replication and ticket lifetimes to expire, and rotate in a controlled order.
Reduce the opportunity with tiering, restricted DC logon and AES-only encryption policy where compatible.

Vetted sources

Use Microsoft’s Defender for Identity documentation for forged-ticket analytics, the SigmaHQ Kerberos rules, Elastic’s Kerberos detections, Splunk ESCU content, MITRE CAR analytics and Atomic Red Team T1558.001 tests to validate coverage. Baseline your own environment, since service accounts and legacy systems still use RC4 legitimately.

Build Detections That Fire

Mjolnir Security helps blue teams turn threat intelligence into high-fidelity detections across endpoint, network, identity and cloud telemetry.

Detection EngineeringManaged Detection & ResponseThreat HuntingIncident ResponsePurple Teaming

Detection Engineering We build and tune detections mapped to ATT&CK from your own telemetry.
Threat Hunting as a Service Hypothesis-driven hunts for the behaviours on this page.
24/7 Incident Response Containment when a detection fires. Call +1 833 403 5875.

Written by: Mjolnir Threat Research (MTAC)  |  Published: October 12, 2026  |  Last reviewed: October 12, 2026

Signals at a Glance

Correlating 4768 and 4769

Encryption Type, Identity and Lifetime

Build Detections That Fire

Persistence Detection

Detection Hub

DSRM and Skeleton Key Detection