What a Golden Ticket Attack Is and How to Defend Against One

A golden ticket attack gives a bad actor broad, long-lasting access to your Windows Active Directory (AD) domain. By forging a high-trust access ticket, an attacker can pose as a powerful user and move through your environments while appearing legitimate. Their access can linger for years if not addressed, and the fallout can affect anything tied to identity.

In this article, we’ll explain what a golden ticket attack is, how it works, and how you can defend against one.

What Is a Golden Ticket Attack?

Kerberos in AD works like this: You sign in, and the domain controller issues a ticket-granting ticket (TGT). When you access a resource like a file share, internal web application, SQL database, or server, Kerberos swaps that TGT for a service ticket, so you don't have to retype a password each time.

That’s the trust your users rely on every day, and it’s exactly what a Kerberos golden ticket targets. By forging the initial TGT and signing it with the Kerberos ticket-granting ticket (KRBTGT) secret, an attacker can act as any identity and request fresh service tickets on demand. They can also reach all services and even domain controllers, while passing through routine authentication checks.

That access can linger, enabling privilege escalation and lateral movement long after the initial breach. Think of it as Willy Wonka’s golden ticket pointed right at your domain, giving access to the entire factory—every room and every machine.

These tickets are referred to as “golden” because they grant domain-wide access. In contrast, a silver ticket targets a single service ticket, which limits the attacker’s reach.

Why Golden Ticket Attacks Are Dangerous

Golden tickets co-opt the trust baked into Kerberos authentication. A forged TGT validates just as if your key distribution center issued it, so routine checks accept it as normal. Tickets arrive encrypted and look typical in network traffic. This creates an authentication bypass vulnerability—the forged ticket circumvents normal password validation entirely.

Many teams keep long TGTs in play, delay KRBTGT rotation, or maintain legacy systems that still use new technology LAN manager (NTLM) in older parts of the environment. When you add loose delegation and privileges that outlive their owners, bad actors have plenty of time to blend in and employ techniques that turn footholds into domain reach.

For example, pass the hash lets an attacker reuse a stolen password hash to authenticate without knowing the cleartext password. On a domain-joined host, that access can open the door to DCsync, which uses legitimate directory replication rights to request password data from a domain controller (including the KRBTGT secret). Service accounts with broad reach, trusts that were never reviewed, and missing least privilege controls widen the blast radius further.

How Golden Ticket Attacks Work

An attack usually starts when an attacker accesses a domain-joined machine through phishing, a vulnerable application, or exposed remote access. From that foothold, they chase the secrets Kerberos trusts by:

1. Establishing a foothold and harvesting credentials: Attackers land on workstations or servers, then extract user credentials, access tokens, and existing Kerberos tickets from memory, including the local security authority subsystem service process. With that access, they pivot toward systems that touch AD.
2. Mapping the domain details they need: They enumerate the fully qualified domain name (for example, company.local or corp.acme.com), the domain security identifier (SID), a unique identifier that AD uses to track the domain, and the high-privilege accounts they plan to impersonate.
3. Gaining domain controller access and extracting the KRBTGT hash: Next, they’ll escalate to domain administrator access, reach the domain controller, and dump the KRBTGT account’s secret. That account signs every TGT for the entire domain, so this single secret becomes the signing key for forged tickets.
4. Forging and loading a TGT: Using the KRBTGT secret, attackers use tools like Mimikatz, Rubeus, or the Impacket golden ticket module to mint a TGT with chosen privileges and extended lifetimes. They inject this ticket into memory, so the system treats it as legitimate, just as though the domain controller issued it.
5. Requesting service tickets and moving wherever Kerberos trust applies: With the forged TGT in memory, the attacker can request service tickets using any identity to reach file shares and internal apps. They can return and authenticate as needed without the original compromised credentials.

How to Detect Golden Ticket Attacks

Forged Kerberos tickets pass routine checks, so hunting for failed logons won’t catch them. Effective golden ticket cybersecurity hinges on spotting what forged tickets can’t fully hide.

To detect this activity in your AD environment, you can:

• Spot tickets with abnormal lifetimes: Kerberos defaults to short-lived tickets—often 10 hours. Flags like multi-year TGT lifetimes stand out and often point to a forged ticket meant to persist.
• Check for users or SIDs that don’t exist: A TGT that names a non-existent user or carries an SID that doesn't map to any account in the domain signals that the ticket was forged.
• Monitor ticket validity after KRBTGT rotation: Track which tickets continue working after a password change, and validate them against your rotation timeline. Tickets that use old key versions or persist beyond expected expiration may be forged.
• Hunt for unusual Kerberos use by privileged accounts: Watch for non-admin users accessing high-privilege resources, or domain administrators authenticating in unexpected patterns.
• Correlate reuse and noisy service ticket requests: The same TGT showing up across multiple devices can indicate forgery or replay, as can sudden spikes in service ticket requests without matching ticket requests (Event ID 4769).

How to Prevent and Defend Against Golden Ticket Attacks

You won’t block a golden ticket at the perimeter, so you have to regain the advantage by shortening lifetimes, tightening delegation, enforcing least privilege everywhere, and watching for anomalies that even valid-looking tickets can’t hide. Here’s where to start:

• Reset KRBTGT twice, at planned intervals: Reset KRBTGT two times, spaced apart so existing tickets expire between resets. This invalidates both of the password hashes forged tickets rely on. Test in a non-production environment first.
• Enforce modern Kerberos cryptography: Require advanced encryption standard where possible, and retire RC4 only after thorough validation to avoid breaking legacy authentication.
• Tighten ticket lifetimes and renewals: Shorten TGT and service ticket lifespans, and cap renewals so persistence windows stay small.
• Constrain and audit delegation: Remove unconstrained delegation, and use constrained or resource-based constrained delegation. You can also eliminate service principal names and trusts that grant more access than needed.
• Lock down privileged access: Use privileged access workstations, as well as separate administrator and user identities. You’ll also want to restrict interactive logon on domain controllers, and limit who can replicate directory data.
• Harden service accounts: Move to group managed service accounts where supported, rotate secrets on a schedule, and remove group memberships that grant domain-wide privileges.
• Minimize pathways to domain administrator access: Patch critical services and enforce multi-factor authentication. In addition, train users to recognize phishing that targets admin credentials, since attackers need domain administrator-level access to extract the KRBTGT hash.

Protect Against Golden Ticket Attacks With Legit Security

Golden ticket attacks happen in AD, but initial access and potential escalation often begin elsewhere. Leaked repository secrets, over-scoped service tokens in continuous integration, domain-joined build agents, and deployment jobs with directory permissions give attackers traction.

Legit’s AI-native application security posture management platform continuously monitors your software supply chain to shut down those paths quickly. It detects exposed credentials, flags build and deployment identities with unnecessary AD reach, and surfaces risky settings in infrastructure as code and cloud resources tied to identity access.

Request a demo today to see how Legit eliminates upstream exposure and enforces secure paths from code to production.