Golden Ticket Attack: Forged Kerberos TGTs Explained

Kerberos works because every party trusts one shared secret held by the domain controller. A Golden Ticket attack is what happens when the attacker gets that secret too. With it, they stop asking the domain controller for permission and start writing their own tickets, granting themselves any identity and any privilege in the domain. It is one of the most complete forms of persistence in Active Directory, and it is why the krbtgt account matters more than any single admin password.

The krbtgt account and why it is the crown jewel

Every Active Directory domain has a built-in account named krbtgt. It is disabled, no human logs in as it, and it exists for one reason: its password hash is the key the Key Distribution Center (KDC) uses to encrypt and sign every Ticket-Granting Ticket it issues.

When a user authenticates, the KDC hands back a TGT that the user later presents to request service tickets. That TGT is encrypted with the krbtgt hash. Inside it sits a Privilege Attribute Certificate (PAC), which lists the user's group memberships and privileges. The PAC is what tells every service in the domain who the user is and what they are allowed to do.

The domain controller trusts a TGT because only the KDC could have encrypted it with the krbtgt key. That assumption is the whole game. If an attacker learns the krbtgt hash, they can encrypt and sign a TGT that looks identical to a legitimate one, because from the cryptography's point of view it is legitimate.

What a Golden Ticket actually is

A Golden Ticket is a TGT forged offline using the stolen krbtgt hash. The attacker never contacts the domain controller to create it. They assemble the ticket themselves, including:

Any username, even one that does not exist in the directory.
Any group memberships, typically Domain Admins and Enterprise Admins, written straight into the PAC.
Any lifetime, so the ticket can be valid for years rather than the default hours.
The domain SID and a chosen RID, binding the forged identity to the real domain.

Once forged, the attacker injects the ticket into a logon session and requests service tickets like any normal user. Because the TGT carries a valid signature, the KDC issues service tickets against it without question. The forged PAC claims Domain Admin, so those service tickets grant Domain Admin access everywhere.

On MITRE ATT&CK this is Golden Ticket (T1558.001), a sub-technique of Steal or Forge Kerberos Tickets.

The normal Kerberos flow, and where the forgery slots in

To see exactly what a Golden Ticket subverts, it helps to walk the honest exchange first. Kerberos runs in three legs.

Authentication (AS exchange). A user proves who they are to the Key Distribution Center and receives a Ticket-Granting Ticket. That TGT is encrypted with the krbtgt key and carries the user's PAC, the record of their groups and privileges. This is the step Windows logs as event ID 4768.
Service ticket request (TGS exchange). When the user wants to reach a service, they present the TGT and ask the KDC for a service ticket. The KDC validates the TGT by decrypting it with the krbtgt key, trusts the PAC inside, and issues a service ticket. This is event ID 4769.
Service access (AP exchange). The user presents the service ticket to the target service, which trusts it because it was issued by the KDC.

A Golden Ticket removes the first leg entirely. The attacker never performs the AS exchange, because they hold the krbtgt key and can mint a valid TGT themselves. They walk straight to the second leg with a ticket the KDC has no reason to doubt. That is why a stream of TGS requests with no preceding AS exchange is a meaningful detection signal: the ticket being presented was never issued by the KDC in the first place.

Forging one, conceptually

The forging process is mechanical once the krbtgt hash is in hand, and describing it in the general shows why the ticket is so hard to distinguish from a real one. The attacker assembles a TGT structure and fills in the fields they want: a username, a set of group memberships written into the PAC, the domain SID, a chosen RID, and a lifetime. They then encrypt and sign that structure with the stolen krbtgt key, producing a ticket that is cryptographically valid because it was signed with the exact key the KDC uses to validate.

The forged ticket is then loaded into a logon session, a step commonly described as pass-the-ticket, after which the attacker requests service tickets as if they were the impersonated user. Our pass-the-ticket guide covers that injection step. From the domain's point of view, an account with the claimed privileges is simply using Kerberos the way it was designed to be used.

A Golden Ticket outlives the credential

Resetting the compromised user's password does nothing to a Golden Ticket. The forged TGT does not depend on any live account; it depends only on the krbtgt key that signed it. As long as that key is unchanged, the ticket stays valid even if the impersonated account is deleted or disabled. This is what makes it persistence rather than a one-time bypass.

How the krbtgt hash gets stolen

A Golden Ticket is a post-compromise technique. To forge one, the attacker must already hold the krbtgt hash, and that hash lives in the Active Directory database on domain controllers. Reaching it means the attacker has already achieved a high level of domain access. Common paths include:

Path to the krbtgt hash	What the attacker already has	Related technique
DCSync replication abuse	Replication rights, often via a compromised privileged account	T1003.006
Credential dumping on a DC	Local admin or SYSTEM on a domain controller	T1003.003
Offline extraction from a backup	Access to a DC backup or the `NTDS.dit` file	T1003.003
Compromise of Domain Admin	Full domain administrative control	T1078.002

The common thread is that the domain is already deeply compromised by the time a Golden Ticket becomes possible. That framing matters for defense: the Golden Ticket is the attacker locking the door behind them, so much of the prevention work happens earlier, at the DCSync and Domain Admin layer.

Why it is such durable persistence

Most footholds an attacker plants can be removed by the obvious response. A backdoor account gets disabled. A stolen password gets reset. A malicious service gets deleted. A Golden Ticket resists all of these, and understanding why explains its place in an intrusion.

The forged ticket is self-contained signed material. It does not point at a live account, a running process, or a file on disk that a defender can find and remove. It depends on exactly one thing: the krbtgt key that signed it. As long as that key is unchanged, the ticket is valid, and the krbtgt key is the one secret most organisations never rotate, because it sits at the root of authentication and rotating it carelessly breaks the domain.

That combination, a credential that survives every routine cleanup and depends on a key nobody wants to touch, is what makes the Golden Ticket a favoured persistence technique for actors who have reached the top of a domain. It lets them return at will long after the intrusion that created it, with the privileges of any account they choose, including ones that do not exist. The lifetime field compounds this, since a ticket can be minted to remain valid for years, well beyond the window most investigations look at.

The PAC is the real payload

The part of the ticket that grants power is the Privilege Attribute Certificate. The PAC is a structure inside the TGT that lists the user's group memberships, their RID, and the privileges those groups carry. Services across the domain read the PAC to decide what the holder is allowed to do.

In a legitimate ticket the KDC fills in the PAC from the directory, so it reflects the user's real groups. In a forged ticket the attacker writes the PAC themselves, claiming membership in Domain Admins, Enterprise Admins, or whatever they choose. Because the whole ticket is signed with the krbtgt key, services trust the PAC without re-checking it against the directory. Microsoft has hardened PAC validation over time to make some forgeries detectable, and the underlying trust relationship, that a krbtgt-signed PAC is believed, remains the mechanism the attack exploits. The Kerberos authentication overview describes the exchange the PAC rides inside.

Golden Ticket versus Silver Ticket

The two are cousins and worth separating clearly. A Golden Ticket forges a TGT using the krbtgt hash and is honored across the whole domain. A Silver Ticket forges a service ticket using a single service account's hash and works only for that one service. The Golden Ticket is broader and more powerful; the Silver Ticket is quieter because it never touches the domain controller at all. Our companion guide on the Silver Ticket attack covers that narrower case.

Property	Golden Ticket	Silver Ticket
Key required	krbtgt hash	Target service account hash
Ticket forged	Ticket-Granting Ticket	Service ticket
Scope of access	Entire domain	One service on one host
Contacts the DC	Yes, for service tickets	No
Blast radius	Domain-wide	Single service
Eviction	Rotate krbtgt twice	Rotate the service account password

The table shows the trade the attacker makes. The Golden Ticket reaches everything and pays for it by touching the domain controller, which creates the request pattern defenders can watch. The Silver Ticket touches nothing central and stays quiet, at the cost of only unlocking the one service whose key was stolen. An attacker who holds the krbtgt hash can produce either at will, which is another reason that hash is the crown jewel.

How to detect and defend

Golden Tickets are designed to look normal, so detection leans on the artifacts of forgery and on watching the choke points where the krbtgt hash could leak.

Detection signals

Anomalous PAC and ticket values. Forged tickets often carry lifetimes far longer than your domain policy allows, usernames that do not resolve to a real account, or a domain SID paired with a username whose RID does not match. A TGT for an account that the directory says does not exist is a strong signal.
TGS requests without a preceding TGT request. In normal Kerberos flow, a TGT is issued (event ID 4768) before service tickets are requested (event ID 4769). A stream of service ticket requests with no corresponding TGT issuance can indicate a ticket that was forged rather than granted.
Encryption-type mismatches. Tickets using downgraded or unusual encryption types, out of step with what your domain normally issues, warrant investigation.
Logons from mismatched accounts. The account name inside the ticket not matching the account context on the source host is a classic forged-ticket tell.
Watch the theft path directly. Since the hash comes from replication or DC access, monitoring for unexpected DCSync activity and credential access on domain controllers catches the attack before the ticket is ever used. See our DCSync guide for that layer.

Defensive controls

Rotate the krbtgt password twice. The krbtgt account retains its previous password for backward compatibility, so a single reset leaves the old key valid. Reset it once, wait long enough for replication and for outstanding tickets to expire, then reset it again. This invalidates every existing TGT, including forged ones. Microsoft documents this in its forest recovery guidance.
Protect the source of the hash. Restrict who holds replication rights, limit Domain Admin membership, and tier your administrative accounts so DC access is tightly held. If the krbtgt hash never leaks, no one can forge a Golden Ticket.
Harden and monitor domain controllers. Treat DCs as the highest-value assets. Limit logon rights, enable robust auditing of directory replication and credential access, and forward those logs off-host.
Shorten ticket lifetimes. Enforcing sane maximum TGT lifetimes through policy makes the extreme lifetimes common in forged tickets stand out more sharply.
Rotate krbtgt on a schedule. Even without a known compromise, periodic krbtgt rotation (twice, with a delay) caps how long any leaked hash stays useful.

Rotate twice, then assume nothing else worked

If you suspect a Golden Ticket, a krbtgt double-reset is necessary but rarely sufficient on its own. An attacker who reached the krbtgt hash almost certainly holds other footholds. Treat the finding as evidence of full domain compromise, rotate krbtgt twice, then run a broader recovery that assumes every privileged credential in the domain is exposed. The attacker groups that reach this depth are catalogued in our Threat Group Directory.

Common mistakes in eviction

The response to a Golden Ticket has a few recurring failure modes that let the attacker keep their access despite an apparent cleanup.

Rotating krbtgt only once. The krbtgt account keeps its previous password for backward compatibility, so a single reset leaves the old key valid, and any ticket forged with it still works. The reset has to happen twice, with a gap between them long enough for replication to complete and for outstanding legitimate tickets to expire. Resetting twice too quickly can break authentication across the domain, so the timing matters.

Treating the ticket as the whole problem. A Golden Ticket is the artifact of a domain already compromised deeply enough to reach the krbtgt hash. Rotating krbtgt invalidates the forged tickets and does nothing about the other footholds the attacker almost certainly holds. Eviction that stops at the ticket leaves the door the attacker walked through wide open.

Rebuilding on compromised infrastructure. If the domain controllers themselves are compromised, resetting krbtgt from within that environment can be undermined. Serious recovery treats the whole domain as suspect and follows a structured process rather than a single password change.

Forgetting the timeline. Because a Golden Ticket can carry a lifetime of years, an attacker may have forged tickets long before they were discovered. Assuming the compromise is recent, and scoping the investigation to the last few days, misses the persistence the technique was chosen to provide. The discovery of a forged ticket says nothing about when the krbtgt hash was first stolen, so the investigation window should reach back to whenever domain-controller access could plausibly have begun.

Misconceptions

"You can patch against Golden Tickets." Nothing is broken to patch. The KDC is doing exactly what it was designed to do, trusting a ticket signed with the krbtgt key. The defense is protecting the key and detecting forged tickets, not applying a fix.

"A strong Domain Admin password prevents it." The attack depends on the krbtgt hash, not on any admin's password. Once the krbtgt hash leaks, password strength elsewhere is irrelevant to forging tickets. Password strength matters earlier, in preventing the compromise that exposes the hash.

"Deleting the impersonated account stops the ticket." A Golden Ticket can name an account that does not exist. The ticket depends only on the krbtgt signature, so disabling or deleting accounts does nothing to it.

"Only Domain Admins can be forged." The PAC in a forged ticket can claim any group membership the attacker writes into it, including Enterprise Admins. The attacker chooses the privileges, so the ceiling is the whole forest, not a single group. This is also why a forged ticket sometimes carries an oddly rich or inconsistent set of group memberships, which becomes another detection tell.

Frequently asked questions

What exactly makes the krbtgt account so important?

Its password hash is the key the KDC uses to encrypt and sign every Ticket-Granting Ticket in the domain. That makes it the root of trust for Kerberos authentication. Anyone who holds the krbtgt hash can sign tickets that the domain will accept as genuine, which is why it is the single most valuable secret in an Active Directory environment.

How does an attacker get the krbtgt hash?

Always from a position of deep compromise. Common paths are DCSync replication abuse with stolen replication rights, credential dumping on a domain controller, offline extraction from a domain controller backup or the directory database file, or full Domain Admin control. Each of these already requires high privilege, which is why the Golden Ticket is a post-compromise persistence technique.

Why do you have to reset the krbtgt password twice?

The account retains its previous password to avoid breaking authentication during rotation. A single reset therefore leaves the old key valid, and tickets forged with it keep working. Resetting twice, with enough delay between the two resets for replication and for outstanding tickets to expire, invalidates the old key and every ticket signed with it, including forged ones.

Can a Golden Ticket be detected while it is being used?

Yes, through the artifacts of forgery and the request pattern. Signals include service ticket requests with no preceding TGT issuance, tickets with lifetimes exceeding domain policy, usernames that do not resolve to real accounts, mismatched RIDs, and unusual encryption types. Watching the theft path, such as unexpected replication activity on domain controllers, catches the attack before any ticket is used.

Is a Golden Ticket the same as pass-the-ticket?

They are related steps. Forging the TGT is the Golden Ticket. Loading that ticket into a logon session so it can be used is pass-the-ticket, an injection technique that also applies to stolen legitimate tickets. A Golden Ticket attack forges the ticket and then uses pass-the-ticket to wield it.

What is the difference between a Golden Ticket and a Silver Ticket?

A Golden Ticket forges a Ticket-Granting Ticket with the krbtgt hash and is honored domain-wide, contacting the domain controller for service tickets. A Silver Ticket forges a service ticket with a single service account's hash, works only for that one service, and never contacts the domain controller. The Golden Ticket is broader and louder; the Silver Ticket is narrower and quieter.

If we find a Golden Ticket, what should we assume about the rest of the domain?

Assume full domain compromise. Reaching the krbtgt hash requires privilege at the level of domain controllers or Domain Admin, so an attacker who forged a Golden Ticket almost certainly holds other credentials and footholds. Rotate krbtgt twice, then run a broader recovery that treats every privileged credential as exposed, rather than assuming the forged ticket was the extent of the access.

The bottom line

A Golden Ticket turns the trust model of Kerberos against the domain. The attacker holds the key that signs identity itself, so the domain believes whatever they write. You cannot patch this, because nothing is broken; the KDC is doing exactly what it was designed to do. The defense is to keep the krbtgt hash out of attacker hands by protecting domain controllers and privileged access, to watch the replication and credential-access paths that lead to it, and to know how to rotate the account twice when eviction is needed.