Golden Ticket: why one KRBTGT reset never stops a forged TGT

A Golden Ticket does not crack a password. Once an attacker has the KRBTGT key, they forge ticket-granting tickets offline for any user and any privilege, and every domain controller trusts them.

How the attack works

A principal with replication rights pulls the KRBTGT secret from a domain controller using directory-replication calls, the same operation a rogue replica uses. With that key, a TGT is forged offline asserting Domain Admins and Enterprise Admins with a multi-year lifetime. No authentication request ever reaches a domain controller, so service tickets appear with no preceding authentication exchange, and the access survives password resets of the impersonated users because the ticket is signed by KRBTGT, not by the user. Ticket lifetimes far beyond domain policy give it away. In ATT&CK terms this is T1558.001, Golden Ticket, enabled by T1003.006, DCSync.

Why it works

KRBTGT signs every ticket-granting ticket in the domain, so possession of that one key is domain-wide forgery. Resetting the impersonated users is irrelevant because their secret was never used.

How to fix it

The non-obvious containment is a double KRBTGT reset. The account keeps its current and previous password, and tickets validate against both, so a single reset leaves the stolen key valid in the previous slot. Reset KRBTGT once, allow full replication, then reset it again so the stolen key ages out of both slots, and invalidate existing tickets. Then close the theft path by removing the replication rights that enabled DCSync, and scope what else was replicated. Hunt service tickets that have no matching authentication request to find impersonated identities.

Practice it

We built this as a GraphLattice Range scenario so responders can rehearse the forged-ticket detection and the double KRBTGT reset that actually contains it.