Golden Ticket

A Golden Ticket is a TGT we forge ourselves: instead of requesting it from the KDC, we build it and sign it with the key of the domain's krbtgt account. Since the KDC trusts any TGT it can decrypt with that key, a ticket forged with the krbtgt hash is indistinguishable from a legitimate one and lets us act as any user, with any group membership.

Why it works. Every TGT is encrypted and signed with the krbtgt key. The KDC keeps no copy of the tickets it issues: if you present a TGT that decrypts correctly, it accepts it and reads your identity and groups (the PAC) straight from inside it. Whoever holds the krbtgt NT hash can therefore write a tailor-made TGT (placing themselves in Domain Admins, say) and the domain will accept it. That hash comes from a DCSync or an NTDS dump, so a Golden Ticket is not the foothold, it is the persistence that follows a domain compromise.

The abuse. With the krbtgt hash and the domain SID you forge the ticket and inject it into memory (/ptt). The sids field lets you add an extra SID: this is SID History abuse, the child → parent hop, where you add the SID of the root domain's Enterprise Admins group to rule the whole forest.

# Windows: forge and inject with mimikatz or Rubeus
kerberos::golden /user:<user> /domain:<domain> /sid:<domain-sid> /krbtgt:<hash-krbtgt> /sids:<sid-extra> /ptt
Rubeus.exe golden /rc4:<hash-krbtgt> /domain:<domain> /sid:<domain-sid> /sids:<sid-extra> /user:<user> /ptt
Rubeus.exe golden /aes256:<aes-krbtgt> /domain:<domain> /sid:<domain-sid> /user:<user> /ptt   # AES: stealthier than RC4

# Linux: with Impacket, export the ccache and use it over Kerberos (-k -no-pass)
ticketer.py -nthash <hash-krbtgt> -domain-sid <domain-sid> -domain <domain> -extra-sid <sid-extra> <user>
export KRB5CCNAME=<user>.ccache
psexec.py <domain>/<user>@<dc> -k -no-pass -target-ip <ip>

Requirements. You need the krbtgt NT hash (or AES key) and the domain SID; both come from a prior compromise of the DC (DCSync). Without the krbtgt hash there is no Golden Ticket. The krbtgt almost never rotates its password, which is why the ticket lasts months or years.

How to detect it. A forged TGT never went through the initial AS-REQ, so on the DC you see an Event ID 4769 (a TGS was requested) with no preceding 4768 (a TGT was requested) for that account: a ticket the KDC never issued is being used. Other signals: tickets with anomalous lifetimes (mimikatz defaulted to 10 years), usernames that do not exist in the directory yet present valid tickets, and RC4 (0x17) where the domain already runs AES only. Correlating a privileged account's use with the absence of its 4768 is the strongest signature.

Defence. Rotate the krbtgt password twice (this invalidates existing tickets) on a schedule and after any suspected DC compromise; protect the DC and the NTDS database so the hash cannot leak; and watch privileged accounts for the 4769-without-4768 pattern. It shares its goal with the Silver Ticket (which forges a service TGS without touching krbtgt) and depends on a prior DCSync or LSASS dump.