Know your enemy: How “Golden Ticket” attacks target identity systems

Cybersecurity Awareness Month is a fitting time to examine attacks like Golden Ticket, which exploit the trust Kerberos depends on and often go unnoticed until the damage is done. This is part one of a three-part series on the most destructive identity attacks, and how identity and security teams can mitigate their impact. 

Every major ransomware crew in the past decade has been chasing the same target before they touch a single file: your identity infrastructure. APT29 (Cozy Bear) used golden tickets against governments, and Wizard Spider, the Russian crew behind TrickBot and Ryuk, has used the same Kerberos-ticket playbook. State spies and ransomware gangs are reaching for the same key. 
 
That's because Golden Ticket exploit Kerberos trust itself, so they go undetected by most security tooling. By the time a Golden Ticket shows up in an EDR tool, the attacker has likely already compromised the entire Active Directory (AD) domain. However, a Golden Ticket attack is stoppable with the right tools that detect and automatically remediate the privilege escalation. 

This post walks through the real attack chain, why standard logging alone can’t catch it, and how real-time detection on unauthorized privileged group changes can help stop the attack early.

The attack chain

The Kerberos Ticket Granting Ticket (KRBTGT) account signs every Kerberos ticket in the domain. It acts as the trust anchor for AD authentication. If you steal its hash (typically via DCSync, another technique attackers use to impersonate a Domain Controller to pull password data straight from AD), an attacker can forge a Ticket Granting Ticket (TGT, the user authentication token used by AD) offline. Once forged, the ticket is untethered from the original compromised account and can be used as a “master key” by any other compromised accounts the attacker may control or create. Typical remediation tactics like password resets, disabled accounts, endpoint isolation don't work at that point. 

For these reasons, Golden Ticket attacks show up so often as a precursor to major ransomware incidents: they hand attackers persistent, domain-wide access that isn't easily detected.

Most Golden Ticket attacks follow a recognizable sequence:

1. Initial access: The attacker gains access via phishing or a stolen low-privilege credential from data breaches, intercepting network traffic or active session tokens.
2. Privilege escalation: The attacker adds a controlled account to a privileged group (Domain Admins, or any group with replication rights) to unlock the access the next step requires.
3. DCSync/credential extraction: The attacker uses replication privileges to pull the KRBTGT hash without ever touching a domain controller's disk.
4. Golden Ticket forgery: The attacker crafts a TGT offline using the stolen hash, granting persistent, unrestricted domain access.
5. Lateral movement and staging: The attacker moves freely, disables logging or backups, and stages ransomware payloads.
6. Detonation: Ransomware is deployed domain-wide, often encrypting or corrupting AD to block recovery.

By step 4, it’s already too late to remediate using most incident response tools. The forged ticket isn’t caught by logs or other traditional security tooling.

Why traditional security tools can't detect Golden Ticket attacks

Standard detection mechanisms lean on Windows Event Logs and SIEM correlation. The problem is a Golden Ticket doesn't generate a normal authentication trail once it's forged. Attackers routinely disable auditing or tamper with logs before extraction.

Security teams can use some detection heuristics like a TGS-REQ (a Kerberos protocol request) with no matching AS-REQ (a login that the client needs to have already completed before and received a valid TGT), or a ticket lifetime that exceeds domain policy. But at this point the forged ticket already exists, which means the attacker has already cleared step 4.

The real opportunity to intervene is earlier, at step 2: the privileged group join. Stopping the attack chain there denies the attacker the access their intrusion requires.

How Cohesity Identity Resilience thwarts Golden Ticket attacks

Cohesity Identity Resilience sends real-time alerts when an unauthorized privileged group membership change occurs. These are flagged the moment the change hits the directory itself, independent of Windows Event Log. If an attacker adds an account to a group with replication rights, Cohesity Identity Resilience sees the directory-level change directly without dependence on a downstream log entry.

That sits inside a broader capability set: Cohesity Identity Resilience has advanced identity threat detection and response (ITDR) that continuously monitors more than 220+ Indicators of Exposure (IOE) and Indicators of Compromise (IOC) across AD and Entra ID, including Kerberos-specific abuse patterns. The solution captures changes even when audit logging is disabled, or when logs are cleared or tampered with after the fact. This detection happens at the directory layer, which removes a blind spot attackers exploit.

Here’s an example of how Cohesity Identity Resilience can help detect and respond to a Golden Ticket attack*. 

1. An attacker, using a phished low-privilege account, adds a service account to a privileged group with replication rights.
2. Cohesity Identity Resilience flags the unauthorized group membership change in real time, independent of whether audit logging is enabled.
3. The alert routes to the security team with full context: which account, which group, what privilege was gained, and why it's worthy of closer examination (for example, no prior history of privileged access requests).
4. Automated rollback reverts the group membership change without waiting for analyst triage, closing the path to DCSync before the attacker can use it.
5. The security team completes triage, confirms containment, and kicks off a forensic review of the source account and initial access vector.

Compare that to the alternative using commonly deployed tools. Without the detection in Step 2, the same chain reaches Golden Ticket forgery and can compromise your AD infrastructure within hours. After that point, any remediation needs to become a full AD forest recovery, under pressure, as trust in the domain is compromised.

*The timeline above is illustrative, a representative sequence. It is intended to show how advanced ITDR can mitigate the impact of a Golden Ticket attack.

Stop a Golden Ticket attack before it creates a forged ticket

The moment to stop a Golden Ticket attack isn't when the forged ticket shows up. It's at the privileged group join that makes forgery possible in the first place. Catch this directory-level change early and reverse it before an attacker reaches KRBTGT.

Want to see how Cohesity Identity Resilience detects and stops attacks like Golden Ticket in your environment?

Watch the demo:

Learn more: 

• Get a free identity security assessment
• Solution Brief
• Demo  

This is part one of a three-part series on the most destructive identity attacks, and how identity and security teams can mitigate their impact. Stay tuned for next week to see our deep dive into DCShadow attacks.