What Is a Golden Ticket Attack? Kerberos Explained

An attacker who already owns a domain controller dumps one specific account from memory: krbtgt. With that single hash they sit on a laptop, run Mimikatz, and forge a Kerberos ticket-granting ticket that claims to be the domain administrator. They never touched the domain admin's password. They never asked the domain controller for permission. They minted their own credential, signed it with the key the entire domain trusts, and walked into every system as anyone they chose. That forged ticket can stay valid for ten years.

That is a golden ticket attack: a post-exploitation technique where an attacker forges Kerberos authentication tickets using the stolen krbtgt account hash, giving them near-unrestricted, durable access across an Active Directory domain. It is not how an attacker breaks in. It is how an attacker who already broke in makes sure they never have to break in again.

This guide covers what a golden ticket attack is, the Kerberos mechanics that make it possible, the exact steps and prerequisites, why it is so hard to detect, and the one mitigation that actually works. It is written for blue teamers who have to defend Active Directory and recognize this attack in their logs.

What is a golden ticket attack?

A golden ticket attack is a post-exploitation technique in which an attacker forges Kerberos ticket-granting tickets (TGTs) using the stolen password hash of the krbtgt account, granting them the ability to authenticate as any user, with any privileges, anywhere in the Active Directory domain. MITRE ATT&CK catalogs it as T1558.001, Golden Ticket, a sub-technique of Steal or Forge Kerberos Tickets (T1558).

The name comes from the golden ticket in Charlie and the Chocolate Factory: a pass that opens every door. The analogy is accurate. A normal Kerberos ticket is issued by the domain controller, scoped to one user, and expires in hours. A golden ticket is forged by the attacker, can claim to be any user with any group membership, and lasts as long as the attacker sets it to last.

The attack does not exploit a vulnerability in Kerberos. It abuses Kerberos working exactly as designed. The protocol trusts any ticket signed with the krbtgt key, because legitimately only the domain controller holds that key. Once an attacker has the krbtgt hash, they hold that same key, and the domain has no way to tell a forged ticket from a real one.

This is why it is a post-exploitation technique and not an entry point. To steal the krbtgt hash, the attacker must already have compromised a domain controller or otherwise obtained domain-level access. The golden ticket is what they do with that access: convert a one-time domain controller compromise into persistent control that survives password resets, account deletions, and remediation that does not specifically target krbtgt.

How Kerberos makes it possible

To see why the krbtgt hash is so dangerous, you have to see what Kerberos trusts.

Kerberos is the default authentication protocol in Active Directory. At the center is the Key Distribution Center (KDC), a service that runs on every domain controller. The KDC has two jobs: an Authentication Service that issues ticket-granting tickets, and a Ticket-Granting Service that exchanges those TGTs for service tickets.

The normal flow runs in three steps. A user authenticates to the Authentication Service and receives a TGT, a sealed credential proving who they are. When the user wants to reach a resource, like a file server, they present the TGT to the Ticket-Granting Service and receive a service ticket for that specific resource. They present the service ticket to the resource, which grants access. The resource trusts the ticket because it was issued by the KDC.

The krbtgt account is what holds it all together. krbtgt is the KDC service account, and its password hash is the key the KDC uses to encrypt and sign every TGT it issues. When a TGT comes back to the Ticket-Granting Service, the service decrypts it with the krbtgt key to confirm it is genuine. The TGT is never validated against the user's current password, their account status, or anything else. It is validated against one thing: was this signed with the krbtgt key?

That is the design flaw an attacker exploits. The krbtgt key is the root of trust for the entire domain, and the KDC does not verify anything beyond a correct signature. An attacker who possesses the krbtgt hash can produce TGTs that are, by the protocol's own rules, perfectly valid. They do not need to authenticate. They do not need the target account's password. They forge the credential offline and present it, and the domain accepts it. Understanding the difference between NTLM and Kerberos authentication is what makes this clear: NTLM hashes let an attacker impersonate one account, but the krbtgt hash lets them impersonate the authority that vouches for every account.

How a golden ticket attack works

A golden ticket attack is the forging step at the end of a longer intrusion. By the time it happens, the attacker has already gained domain-level access and is using the krbtgt hash to lock in permanent control.

The attacker needs four pieces of information to forge a valid ticket:

1. The fully qualified domain name. The name of the target Active Directory domain.
2. The domain SID. The security identifier of the domain, which scopes the forged ticket to it.
3. The krbtgt password hash. The signing key. This is the prize, and getting it is the hard part: it requires domain controller compromise or domain-admin-level access to extract.
4. The username to impersonate. Usually the domain administrator, or a fabricated account name that does not exist at all.

With those four inputs, the forging itself is trivial. The attacker runs a tool, most commonly Mimikatz (the credential-theft tool released in 2011 that first demonstrated the attack), and it produces a ticket-granting ticket signed with the krbtgt key. From the domain's perspective the ticket is indistinguishable from one the KDC issued, because the same key signed both.

What the attacker gains from that ticket is the point. They can set its lifetime to years rather than the default ten hours. They can grant it membership in any group, including Domain Admins, regardless of the impersonated account's real permissions. They can impersonate an account that was deleted, or one that never existed. And because the forged TGT bypasses the Authentication Service entirely, much of the normal logging around initial authentication never fires. The attacker then presents the TGT to the Ticket-Granting Service to obtain service tickets for any resource they want, moving through the domain as a fully trusted administrator.

The durability is what makes it a persistence technique, not just a privilege escalation. A forged ticket survives the impersonated user changing their password, because the TGT was never tied to that password. It survives the account being disabled or deleted. It even survives a single reset of the krbtgt password, because of how Active Directory keeps the previous krbtgt key valid for backward compatibility. The attacker can be evicted from every machine, have every known account reset, and still hold a working master key to the domain.

Why a golden ticket attack is hard to detect

The core problem is that a forged ticket is cryptographically valid. It is signed with the real krbtgt key, so the domain controller accepts it as genuine. There is no failed authentication, no invalid signature, no protocol error to alert on. The attack is invisible to anything that trusts Kerberos to police itself, which is everything.

It also bypasses the obvious controls. The forging happens offline, on the attacker's machine, so there is no network event for it. The TGT skips the Authentication Service, so the logon events defenders usually watch for may never appear. And because the attacker presents a valid administrator ticket, their subsequent activity looks like an administrator doing administrator things. This places golden ticket abuse firmly in the realm of credential theft that hides inside legitimate authentication, where signatures and perimeter defenses are useless.

Detection therefore depends on spotting the artifacts a forged ticket leaves, the small ways it deviates from what the real KDC produces:

• Anomalous ticket lifetimes. Forged TGTs are often set to last for years. A real TGT lasts ten hours by default. A ticket with a multi-year lifetime is a strong tell.
• Tickets for non-existent or mismatched users. A golden ticket can name a user that does not exist in the directory, or claim group memberships the real account never had.
• TGS requests with no preceding TGT request. A forged TGT is injected directly, so the domain controller sees a service-ticket request from a TGT it never issued.
• Unexpected encryption types and malformed fields. Forging tools sometimes default to weaker encryption (RC4) or leave fields that a genuine KDC would populate differently.
• The same ticket reused across many hosts. One forged TGT appearing on multiple machines suggests an attacker spreading it, not normal per-user authentication.

Centralizing Windows authentication events in a SIEM and baselining normal ticket behavior is what turns these subtle deviations into a detection. The unifying skill is the same as for any in-network attack: knowing what normal Kerberos traffic looks like well enough to see the one ticket that does not belong.

How to prevent a golden ticket attack

You cannot patch away a golden ticket attack, because it abuses Kerberos as designed. The defense splits into two parts: keep attackers away from the krbtgt hash, and have a plan to invalidate forged tickets if they get it.

Protect the krbtgt hash by protecting domain controllers. Stealing the krbtgt hash requires domain-level compromise, so everything that keeps an attacker off your domain controllers is a golden ticket control. Enforce tiered administration so workstation and server admin credentials cannot reach a DC. Apply least privilege so few accounts can extract directory secrets. Use multi-factor authentication on privileged logons, and limit where domain admin credentials are ever used, so their hashes are not left in memory to be dumped during the lateral movement that precedes this attack.

Reset the krbtgt password, twice, on a schedule and after any suspected DC compromise. This is the one control specific to golden tickets. Active Directory keeps the current and previous krbtgt password to avoid breaking tickets mid-transition, which is exactly why a single reset does not invalidate a forged ticket: the old key is still trusted. Resetting twice (with enough time between resets for replication to complete) rotates out both the current and previous keys, which invalidates every existing golden ticket. MITRE ATT&CK recommends rotating the krbtgt password on a regular cadence, on the order of every 180 days, so that even an undetected theft has a limited useful life.

Detect the theft upstream. Because the forging step is silent, your best signal is the credential access that comes before it: the domain controller compromise, the directory replication abuse, the credential dumping. Endpoint and identity telemetry that catches a krbtgt hash being extracted stops the attack before a ticket is ever forged. Hardening Active Directory security overall, monitoring for DC compromise, and auditing privileged access, is what shrinks the window in which this attack is possible.

None of these stop a golden ticket on their own. Together, they make stealing the krbtgt hash hard, make a stolen hash expire, and make the theft visible before it pays off.

Frequently asked questions

What is a golden ticket attack in simple terms?

A golden ticket attack is when an attacker who has already compromised an Active Directory domain forges their own Kerberos login tickets. They steal the hash of a special account called krbtgt, which is the key the domain uses to sign every authentication ticket. With that key they can create tickets that impersonate any user, with any privileges, for as long as they want, and the domain accepts them as genuine.

What is the krbtgt account and why does it matter?

krbtgt is the service account for the Kerberos Key Distribution Center, the part of a domain controller that issues authentication tickets. Its password hash is the key used to encrypt and sign every ticket-granting ticket in the domain. Because the domain trusts any ticket signed with that key, whoever holds the krbtgt hash can forge tickets the domain cannot tell apart from real ones, which is the entire basis of the golden ticket attack.

What is the difference between a golden ticket and a silver ticket?

A golden ticket forges a ticket-granting ticket signed with the krbtgt hash, giving domain-wide access to any service. A silver ticket forges a service ticket signed with a single service account's hash, giving access only to that one service. A golden ticket is broader and more powerful but requires the krbtgt hash; a silver ticket is narrower and stealthier because it never contacts the domain controller.

How is a golden ticket attack detected?

It is detected by spotting the artifacts a forged ticket leaves rather than the forging itself, which is silent. Watch for ticket-granting tickets with unusually long lifetimes, tickets for users that do not exist or claim privileges they should not have, service-ticket requests with no preceding ticket-granting request, and unexpected encryption types. Centralizing authentication logs and baselining normal Kerberos behavior is what surfaces these anomalies.

How do you stop a golden ticket attack?

You stop it by protecting the krbtgt hash and by being able to invalidate forged tickets. Keep attackers off domain controllers with tiered administration, least privilege, and MFA, since stealing the hash requires domain-level access. If you suspect compromise, reset the krbtgt password twice to rotate out both the current and previous key, which invalidates all existing golden tickets. Rotating krbtgt regularly limits the lifespan of any undetected theft.

Can a golden ticket attack survive a password reset?

Yes, which is what makes it dangerous. A forged ticket is not tied to the impersonated user's password, so resetting that user's password does nothing. It even survives a single reset of the krbtgt password, because Active Directory keeps the previous krbtgt key valid for compatibility. Only resetting the krbtgt password twice, rotating out both keys, invalidates an existing golden ticket.