How to detect Golden Ticket attacks

Threat snapshot

A Golden Ticket is a forged Kerberos Ticket Granting Ticket. It is created offline using the NTLM hash of the domain's krbtgt account, a special account whose sole purpose is to sign every TGT issued in the domain. Because the forged ticket is signed with the real krbtgt hash, every Kerberos-aware service in the domain accepts it as authentic. The attacker can specify any username, any group membership, and any ticket lifetime they choose. Most significantly, they can claim membership in Domain Admins, Enterprise Admins, or any other group in the domain without those groups actually containing the account.

The krbtgt account hash is the master key for the entire Kerberos infrastructure of a domain. Every TGT in the domain derives its validity from this hash. Obtaining it requires domain admin access, but once obtained, the hash can be used to generate new Golden Tickets indefinitely and from any machine, without any further interaction with the domain. A Golden Ticket created today remains valid until the krbtgt password is rotated twice, which by default never happens unless an administrator explicitly forces it.

What makes Golden Tickets particularly dangerous as a persistence mechanism is their invisibility to standard monitoring. A forged TGT presented to the KDC generates standard authentication events that are indistinguishable from legitimate TGT use, because the KDC validates the ticket using the real krbtgt key and finds it cryptographically valid. The anomalies that betray a Golden Ticket are subtle: impossible ticket lifetimes, account names that do not exist in the domain, or TGT requests for accounts from machines those accounts have never previously used.

Golden Ticket attacks, at a glance

How Golden Ticket attacks work

A Golden Ticket attack requires two steps: extracting the krbtgt hash from Active Directory, then using that hash to forge a TGT with arbitrary claims. The diagram below shows both steps and how the forged TGT passes through the normal Kerberos authentication flow undetected.

Step 1: Extracting the krbtgt hash

The krbtgt account's NTLM hash is the signing key for every TGT in the domain. An attacker who has already achieved domain admin access obtains it via one of two methods. DCSync is the most common: Mimikatz's lsadump::dcsync /user:krbtgt command uses legitimate AD replication APIs to request the krbtgt account's password hash directly from a domain controller, generating Event 4662 (replication operation) on the DC rather than Event 4625 or Event 4768. The second method is direct LSASS memory access on a domain controller: since the DC caches the krbtgt hash in LSASS for ticket signing, a memory dump of the DC's LSASS process yields the same hash.

Both methods leave specific forensic traces. DCSync generates Event 4662 on domain controllers with the replication control access rights GUIDs (1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 for DS-Replication-Get-Changes and 1131f6ab-9c07-11d1-f79f-00c04fc2dcd2 for DS-Replication-Get-Changes-All). Direct LSASS access generates Sysmon Event 10 with lsass.exe as the target process. Either event attributable to a non-DC source IP is a high-confidence indicator that krbtgt extraction is in progress.

Step 2: Forging and injecting the Golden Ticket

With the krbtgt hash, the attacker forges a TGT entirely offline using Mimikatz's kerberos::golden command or Rubeus's golden command. The forged ticket contains arbitrary user attributes including group memberships, a chosen username, the domain SID, and an attacker-specified ticket lifetime. Most Golden Tickets are created with a 10-year lifetime to avoid expiry during the operation.

Once forged, the ticket is injected into the current Windows session using kerberos::ptt (pass-the-ticket) or Rubeus's ptt command. From that point, Windows presents the forged TGT to the KDC whenever a TGS for any service is needed. The KDC decrypts the TGT using the real krbtgt key, finds it cryptographically valid, and issues a genuine TGS for the requested service. The result is authenticated access to any Kerberos-enabled service in the domain as the impersonated user.

When the forged TGT is written to disk (for use on another machine or for safekeeping), Mimikatz creates a .kirbi format file. This file creation event is detectable via Sysmon Event 11 and is the earliest endpoint-level artifact of the forging operation.

Post-ticket lateral movement via PowerShell and relay tools

Once a Golden Ticket is active in the session, attackers use additional tooling to enumerate and access services across the domain. PowerShell-based Kerberos ticket requests allow scripted access to multiple services using the forged identity. KrbRelay and KrbRelayUp extend the attack surface by coercing machine authentication and relaying it to Kerberos-enabled services, compounding the access available through the forged TGT. Each of these downstream tools produces its own process creation signature that Log360's rules detect independently.

Real-world campaigns

APT29 and other nation-state actors: Golden Tickets as long-term persistence

Nation-state threat actors including APT29 (Cozy Bear) have been documented using Golden Tickets as their preferred long-term persistence mechanism after achieving domain compromise. The operational logic is straightforward: once the krbtgt hash is extracted, the actor can re-enter the domain at any time using a newly forged ticket, even if every user account password in the domain has been reset. The only remediation that invalidates a Golden Ticket is a double rotation of the krbtgt password, a procedure that most organizations have never performed and that requires careful planning to avoid disrupting legitimate Kerberos authentication. APT29's documented use of Golden Tickets in the SolarWinds intrusion campaign highlighted this technique to a broad audience of defenders and operators alike.

NotPetya and ransomware operators: Golden Tickets for mass lateral movement

The NotPetya wiper used a Golden Ticket implementation (derived from Mimikatz) as part of its lateral propagation mechanism. After extracting the krbtgt hash from an infected DC, it forged tickets enabling authenticated access to every domain-joined machine for encryption and propagation. The speed of domain-wide compromise in NotPetya incidents was significantly enabled by Golden Ticket-based mass authentication, which bypassed the need to crack or guess credentials for individual machines. Subsequent ransomware operators including REvil and BlackMatter have incorporated similar Golden Ticket steps in documented post-compromise playbooks.

Attack reference table

Business impact

• Persistence that outlasts all standard remediation. Resetting every domain user password, rotating every service account, and even performing a full domain admin account rebuild leaves a Golden Ticket untouched. The only actions that invalidate an outstanding Golden Ticket are rotating the krbtgt password twice within the ticket's lifetime. A single missed krbtgt rotation during incident response means the attacker retains access indefinitely, with a valid cryptographic credential that every Kerberos service in the domain will honor.
• Domain-wide access from a single credential. Where a Silver Ticket grants access to one service on one machine, a Golden Ticket grants access to every Kerberos-enabled service across the entire domain. File servers, domain controllers, database servers, mail servers, internal web applications, and remote management endpoints are all reachable using a single forged TGT. The blast radius is the entire domain.
• Impersonation of any user including non-existent ones. The forged TGT specifies a username but the KDC does not verify that the username corresponds to a real account in the directory. An attacker can authenticate as a username that does not exist in AD, making it impossible to trace activity back to a legitimate account and making post-incident attribution significantly harder.
• Invisibility to standard authentication monitoring. Event 4768 (TGT request) and Event 4769 (TGS request) appear normal when a Golden Ticket is used because the KDC validates the forged TGT successfully and issues a genuine TGS. Without specific monitoring for the anomalies listed in the diagram above, the forged authentication is indistinguishable from legitimate Kerberos traffic in standard authentication logs.

Detecting Golden Ticket attacks with Log360

Log360's eight detection rules for Golden Ticket attacks cover three detection layers. The first catches the tooling used to extract the krbtgt hash and forge tickets (Mimikatz execution signatures, .kirbi file creation, Rubeus execution). The second catches downstream Kerberos activity that uses the forged TGT (PowerShell ticket requests, anomalous Kerberos connections). The third catches relay attacks that compound the forged TGT access (KrbRelay, KrbRelayUp). For all endpoint-based rules, Sysmon must be deployed on domain-joined machines with process creation (Event 1) and file creation (Event 11) logging forwarding to Log360.

Hash extraction and ticket forging tool detection

Post-ticket Kerberos activity detection

Kerberos relay tool detection

Attack chain visibility

Golden Ticket attacks follow a consistent chain: krbtgt hash extraction, offline ticket forging, session injection, and domain-wide service access. The sequences below show the log record for the two most common operational variants.

Sequence A: Mimikatz DCSync to Golden Ticket to domain-wide access

Sequence B: Rubeus in-memory Golden Ticket with KrbRelayUp persistence backup

Investigation playbook

Golden Ticket investigations must address two simultaneous objectives: understanding the current scope of access the attacker has obtained via the forged TGT, and executing the krbtgt double rotation that invalidates all outstanding Golden Tickets before the attacker uses them further. These two objectives are in tension because krbtgt rotation, while necessary, can disrupt legitimate Kerberos authentication and requires careful timing.

Step 1: Triage - identify which rule fired and the chain so far

Step 2: Confirm krbtgt hash compromise

• Query Windows Security Event 4662 on all domain controllers for the past 7 days, filtered for the DS-Replication-Get-Changes and DS-Replication-Get-Changes-All access rights GUIDs. Any instance where the source IP is not a domain controller is a DCSync operation targeting AD credentials. If the krbtgt account is referenced in these events, treat it as confirmed compromised.
• Check Sysmon Event 10 (process access) on domain controllers for lsass.exe access from non-Microsoft processes. A direct LSASS memory dump on a DC yields the krbtgt hash without generating Event 4662. Any non-standard process accessing DC LSASS memory should be treated as a credential extraction attempt.
• Query Event 4768 on all DCs for TGT requests with anomalous characteristics: ticket lifetime greater than the domain's configured TGT lifetime (default 10 hours), usernames that do not exist in AD, or encryption type inconsistencies. These are the in-Kerberos indicators of Golden Ticket use.

Step 3: Investigate using the Incident Workbench

• Click on the affected hostname or account in the alert to open the Incident Workbench. Use the Process analytics tab on the machine where Mimikatz or Rubeus ran to view the full process tree. This reveals the prior compromise chain: how the attacker obtained domain admin access before extracting the krbtgt hash, which determines the full scope of the preceding intrusion.
• Use the User analytics tab for any accounts referenced in the Kerberos anomaly events. If the impersonated account has a UEBA baseline, its risk score will spike due to authentication from unexpected machines and access to services outside the normal baseline. If the impersonated account does not exist in AD, the UEBA profile will be absent, which is itself a confirming signal of a forged non-existent account name.
• Use Advanced Threat Analytics on the source IP used for DCSync or for Kerberos authentication post-Golden Ticket to check threat feed context and confirm whether the IP is associated with known attack infrastructure.
• Save the Incident Workbench session to an incident immediately. Golden Ticket incidents require executive notification, and the session documents the evidence chain from krbtgt extraction through service access for those communications.

Step 4: Assess the full scope of Golden Ticket access

• Identify the earliest confirmed evidence of krbtgt hash compromise from DCSync events or LSASS access. Treat every domain service access from the attack source IP after that timestamp as potentially Golden Ticket-based.
• Review Event 4769 (TGS request) on all DCs for TGS requests sourced from the attack IP or from machines where Mimikatz/Rubeus ran. Each TGS request identifies a specific service that was accessed using the forged identity. Enumerate all services reached.
• Check whether any of the services accessed during the Golden Ticket window hold sensitive data: file servers, database servers, mail servers, or code repositories. Those services require their own scope assessment regarding data accessed or exfiltrated during the forged session.
• Check for KrbRelayUp activity and msDS-KeyCredentialLink writes to determine whether shadow credential persistence was established. If so, identifying and removing all shadow credentials must be part of the remediation.

Step 5: Collect evidence and build the timeline

• Export Windows Security Event 4662 from all DCs for the attack window. These records are the primary evidence of krbtgt hash extraction via DCSync and document which account performed the replication operation and from which IP.
• Export Sysmon Event 1 (process creation with full command line) from the compromised host. The Mimikatz or Rubeus command line is the most direct evidence of the forging operation.
• Export Event 4768 and 4769 from all DCs for the attack window. Look for anomalous ticket lifetimes, non-existent account names, and TGS requests for services that are inconsistent with the impersonated account's normal role.
• Export the Incident Workbench session timeline and UEBA risk scores as the compliance record for NIST CSF DE.AE-5 incident analysis and for executive and legal stakeholder reporting.

Response and remediation

Immediate containment

• Isolate the machine where Mimikatz or Rubeus ran. This terminates any active forged sessions using tickets in that machine's Kerberos cache and prevents the attacker from forging additional tickets from the same operational platform.
• Perform a double krbtgt password rotation. This is the only action that invalidates outstanding Golden Tickets. The rotation must be performed twice, with the two rotations separated by the maximum Kerberos ticket lifetime in the domain (default 10 hours), to ensure all outstanding TGTs issued before the first rotation have expired. Single krbtgt rotation is insufficient because Golden Tickets are validated against the previous password hash which remains cached on DCs for one ticket lifetime. Use Microsoft's documented procedure for this operation. Plan the rotation to occur during a low-activity window as it will cause all existing TGTs to be invalidated and all users to need to re-authenticate.
• Remove any shadow credentials (msDS-KeyCredentialLink entries) added via KrbRelayUp or KrbRelay. These provide an independent authentication path that survives krbtgt rotation. Audit the attribute on all high-value AD objects including Domain Controllers, admin accounts, and service accounts.
• Revoke all active sessions for any account names impersonated in confirmed Golden Ticket authentications. While these are forged identities, any legitimate sessions those accounts have open may have been used alongside the forged sessions and should be refreshed.

Response actions by trigger

Hardening

• Implement a regular krbtgt password rotation schedule. Microsoft recommends rotating the krbtgt password every 180 days at minimum. In practice, most organizations never rotate it at all. Establishing a documented rotation procedure and testing it reduces the window of Golden Ticket validity in the event of a future compromise.
• Restrict DCSync rights to domain controller machine accounts only. The DS-Replication-Get-Changes and DS-Replication-Get-Changes-All permissions on the domain object should only be held by DC machine accounts. Any user account with these permissions represents a DCSync risk. Audit these permissions via Get-ADObject and remove any non-DC account grants.
• Deploy Credential Guard on all domain-joined endpoints including servers. Credential Guard prevents Mimikatz from reading LSASS memory directly, blocking the LSASS-based krbtgt hash extraction path. Combined with DCSync right restrictions, it eliminates both primary hash acquisition methods.
• Enable Protected Users security group membership for the krbtgt account (where supported). Protected Users restrictions limit the encryption types and delegation settings available for group members, making certain hash extraction approaches more difficult.
• Monitor Event 4662 for non-DC replication in real time. Any DCSync operation from a non-DC source should trigger an immediate alert regardless of the target account. This event class is one of the clearest signals of domain-level credential theft in progress.

False positive tuning