In the realm of enterprise identity security, few compromises are as devastating and persistent as the golden ticket attack active directory environment. When an attacker achieves this, they effectively become the domain. They can forge their own authentication tickets, access any resource, impersonate any user (including built-in administrators), and maintain stealthy persistence for years—even if you change every user password in the organization.
Also read: Active Directory Security: Hardening Guide and Common Attack Paths (2026)
This guide provides a deep dive into the mechanics of Kerberos, how Golden Tickets are forged, the subtle forensic artifacts required to detect them, and the definitive remediation steps to burn the attacker out of your domain.
To understand the Golden Ticket, you must understand the trust model of Active Directory Kerberos. In a Windows domain, the Key Distribution Center (KDC) runs on every Domain Controller (DC) and relies on a specific, often-overlooked service account: krbtgt.
A golden ticket attack active directory compromise requires the attacker to first obtain Domain Admin privileges (or equivalent) to extract the KRBTGT hash. This is typically done via a DCSync attack or by dumping the LSASS memory on a Domain Controller.
Using tools like Mimikatz, the attacker performs a DCSync to replicate the KRBTGT password hash from the DC.
The attacker now uses the hash, the domain SID, and the target username to forge a TGT offline. They can even add themselves to the "Domain Admins" or "Enterprise Admins" SID history.
Once injected, the attacker can use psexec, wmiexec, or native SMB to access any machine in the domain. The Domain Controller will accept the forged ticket because the cryptographic signature is mathematically valid.
Because the attacker bypasses the initial password authentication phase, standard "failed logon" alerts will not trigger. Detection requires hunting for Kerberos anomalies in Windows Event Logs.
| Event ID | Description | Golden Ticket Anomaly |
|---|---|---|
| 4768 | Kerberos Authentication Ticket (TGT) Requested (AS-REQ) | Missing. A Golden Ticket is forged offline. The DC never sees the initial AS-REQ. |
| 4769 | Kerberos Service Ticket Requested (TGS-REQ) | Present. The attacker uses the forged TGT to request access to services (e.g., CIFS, HOST). |
| 4624 | Successful Logon (Type 3 - Network) | Account logon occurs without a preceding 4768 event on the DC. |
- The Missing 4768: If you see Event 4769 (Service Ticket) for a user, but no corresponding Event 4768 (TGT Request) within the ticket's lifetime, the TGT was likely forged.
- Impossible Ticket Lifetimes: Domain Group Policy dictates TGT lifetimes (usually 10 hours). If a SIEM detects a TGT being used that was issued months ago, it is a Golden Ticket (attackers often set the expiration to 10 years).
- Relative ID (RID) Mismatches: The attacker might forge a ticket for the "Administrator" account (RID 500) but map it to a standard user's SID, or vice versa. Security tools like Microsoft Defender for Identity flag these cryptographic mismatches instantly.
- Non-Existent Users: Attackers sometimes forge tickets for fake usernames (e.g., sysadmin_backup) that don't exist in AD. Because the DC only validates the KRBTGT signature (not the user's existence in the SAM database during TGS-REQ), the ticket is accepted.
If you suspect a Golden Ticket compromise, changing user passwords is useless. You must invalidate the KRBTGT hash. However, Active Directory stores the current and previous password hashes for the KRBTGT account to allow for replication delays and graceful ticket renewal.
You cannot stop a Golden Ticket if the attacker already has Domain Admin rights. Prevention is entirely focused on protecting the KRBTGT hash and the Domain Controllers from initial compromise.
- Implement Tiered Administration (Tier 0/1/2): Domain Admins should ONLY log into Domain Controllers (Tier 0). They should never log into workstations or member servers where their credentials can be scraped from LSASS memory by malware.
- Protected Users Group: Add all Tier 0 administrators to the built-in Protected Users security group. This prevents their credentials from being cached in memory (NTLM/WDigest) and blocks delegation.
- Windows Defender Credential Guard: Enable Credential Guard on all endpoints and servers. This uses virtualization-based security (VBS) to isolate LSASS, preventing Mimikatz and similar tools from reading memory.
- Restrict DCSync Rights: By default, only Domain Admins, Enterprise Admins, and Domain Controllers have the "Replicating Directory Changes" permission. Audit this ACL regularly. Attackers often grant this right to a backdoor service account.
- ✓Isolate suspected compromised Domain Controllers from the network to halt DCSync replication and lateral movement.
- ✓Hunt Event ID 4769 without 4768. Query your SIEM for service ticket requests lacking a preceding TGT request.
- ✓Check for anomalous SID History. Look for standard users suddenly possessing Enterprise Admin (519) or Domain Admin (512) SIDs in their Kerberos tokens.
- ✓Execute the KRBTGT Double-Reset. Reset the password, wait for replication, and reset it again to flush the compromised hash from AD history.
- ✓Reset the passwords of all Tier 0 accounts (Domain Admins, Enterprise Admins, and service accounts with high privileges).
- ✓Audit the "Replicating Directory Changes" ACL. Remove any unauthorized accounts that the attacker may have granted DCSync rights to.
- ✓Move all Domain Admins to the Protected Users group to prevent future LSASS credential scraping.
- ✓Deploy Microsoft Defender for Identity (MDI) or equivalent EDR to automatically detect DCSync attempts and forged ticket anomalies.
- ✓Implement automated KRBTGT password rotation. Use Microsoft's official KRBTGT rotation script or a privileged access management (PAM) solution to rotate the hash every 180 days.
No. This is a common misconception. A Golden Ticket is forged using the krbtgt account hash, not the individual user's password hash. You could change the Domain Admin's password 100 times, and the attacker's forged ticket will still be accepted by the Domain Controller until the krbtgt hash itself is reset twice.
A Golden Ticket forges a Ticket-Granting Ticket (TGT) using the krbtgt hash, granting domain-wide access to any service. A Silver Ticket forges a Service Ticket (TGS) using the NTLM hash of a specific target server's computer account (e.g., SQLSERVER01$). A Silver Ticket only grants access to that specific server and service (like CIFS or MSSQLSvc), but it is much stealthier because it never communicates with the Domain Controller, leaving almost no log artifacts.
Azure AD (Entra ID) does not use Kerberos; it uses modern protocols like OAuth2, SAML, and OpenID Connect. Therefore, a traditional on-premises Golden Ticket cannot directly forge access to cloud resources. However, if your environment uses Azure AD Connect, an attacker with a Golden Ticket can compromise the on-premises AD Connect server, extract the synchronization credentials, and take over the linked cloud tenant.
