Golden Ticket vs Silver Ticket: Creation, Scope, and Detection

The Absolute Forensic Boundary

• Golden Ticket: Forged using the domain krbtgt account hash. It is a TGT (Ticket Granting Ticket). It grants arbitrary, unconstrained access across every service in the entire domain or forest. The KDC is contacted to exchange this TGT for service tickets.
• Silver Ticket: Forged using the target service account’s secret key (computer machine account or managed service account). It is a TGS (Service Ticket). It grants access strictly to that designated service. The domain controller is never contacted.

Concept

In post-exploitation Kerberos operations, ticket forgery enables adversaries to bypass authentication authorities to construct synthetic cryptographic proof of authorization:

1. Golden Ticket: The attacker usurps the identity of the KDC. Armed with the symmetric key of krbtgt, they manufacture a valid TGT containing a custom PAC (e.g., injecting RID 512 Domain Admins).
2. Silver Ticket: The attacker usurps authentication against a specific service endpoint (e.g., CIFS, MSSQL, HTTP). Using the service account’s secret key, they directly forge the final TGS presented to that host application.

---

Why It Matters in DFIR

Distinguishing a Golden Ticket from a Silver Ticket fundamentally determines incident scope and containment actions:

• Compromise Blast Radius:
  • Finding a Golden Ticket confirms krbtgt theft $\rightarrow$ the entire domain and forest are compromised at Tier 0.
  • Finding a Silver Ticket indicates that only that specific service secret was compromised $\rightarrow$ the domain database remains intact.
• Log Visibility and Telemetry Footprint:
  • Golden Tickets generate seemingly legitimate TGS requests against DCs (Event ID 4769), but are never preceded by an Event ID 4768 (TGT request)!
  • Silver Tickets are presented directly to resource servers. Zero events appear on domain controllers. Telemetry exists solely on the member server (Event ID 4624).
• Remediation Procedures:
  • Revoking Golden Tickets requires rotating the domain krbtgt password twice consecutively (respecting replication latency).
  • Revoking a Silver Ticket requires rotating the target service account password (or the host computer account password).

---

How It Works

Technical Forensic Comparison Matrix

Feature	Golden Ticket	Silver Ticket
Ticket Type	TGT (krbtgt)	TGS (Service Ticket)
Cryptographic Key Required	NTLM hash or AES key of krbtgt	NTLM hash or AES key of target service account
Access Scope	All enterprise services / forest-wide	Strictly the targeted service (CIFS, SQL, etc.)
DC Communication?	Yes (presents TGT to request TGS)	No (presented directly to target workload)
KDC PAC Signature	Valid (signed with genuine krbtgt key)	Invalid / Dummy (fabricated signature)
Default Lifetime	10 years (Mimikatz default)	10 years (Mimikatz default)
DC Telemetry	Event 4769 without preceding Event 4768	Zero DC telemetry
Target Workload Telemetry	Event 4624 (Logon Type 3 Kerberos)	Event 4624 (Logon Type 3 Kerberos)
Remediation	Consecutive double krbtgt rotation	Service or machine account password reset

---

What Is Possible

• Forging Golden Tickets for Non-Existent Users: An adversary can fabricate a ticket for ghost_admin. The KDC processes TGS requests without querying LDAP to verify account existence (unless account validation policies are enforced).
• Maintaining Decade-Long Persistence: Forged tickets commonly declare lifetimes spanning 10 years.
• Detecting Silver Tickets When PAC Validation Is Enforced: If a service issues an RPC Netlogon query to verify the KDC signature, the DC identifies the dummy signature and denies access.

---

What Is Not Possible

• Presenting a Silver Ticket Against Another Service: Silver tickets are encrypted under Service A’s key. Presenting it to Service B triggers decryption failure (KRB_AP_ERR_MODIFIED / 0x29).
• Hunting Silver Tickets from DC Event Logs Alone: Because Silver Tickets bypass the KDC, they are completely invisible without endpoint log collection.
• Revoking a Golden Ticket by Resetting the Impersonated User’s Password: Golden Tickets validate against the krbtgt key, completely detached from the user’s password. Only krbtgt rotation invalidates the ticket.

---

Common DFIR Confusions

Frequent Confusion	Verifiable Forensic Reality
”We discovered a Golden Ticket in the web server logs.”	False. Web servers only receive TGS tickets (Silver Tickets or legitimate TGS). A Golden Ticket (TGT) is only presented to KDCs.
”A single krbtgt password reset revokes all Golden Tickets.”	Active Directory maintains the previous krbtgt key to avoid terminating legitimate active sessions. You must rotate twice with replication intervals.
”Silver Tickets generate Event ID 4769 on DCs.”	No. Silver Tickets bypass the KDC entirely, communicating directly with the target workload.

---

Concrete Forensic Example

During an investigation, an analyst inspects file server FS01 encrypted by ransomware:

1. On FS01: Event ID 4624 records a network logon at 01:45 UTC under CORP\TempAdmin via Kerberos.
2. On Domain Controllers:
   • Searching Event 4768 (TGT) for TempAdmin around that timestamp: zero records.
   • Searching Event 4769 (TGS) for cifs/FS01: zero records.
3. Forensic Assessment: The connection to FS01 was executed using a Silver Ticket forged with the FS01$ computer account secret stolen earlier from LSASS. The DC was entirely bypassed.

---

Key Forensic Artefacts

1. DC Security Logs (Golden Ticket Detection):
   • Orphan Event 4769: TGS requests lacking a preceding Event 4768 within the standard 10-hour Kerberos window.
   • Encryption Downgrades: Prevalence of 0x17 (RC4) in Event 4769 records when AES-256 (0x12) is enterprise baseline.
   • Non-Existent Principals: Event 4769 issued for identities absent from Active Directory.
2. Member Server Security Logs (Silver Ticket Detection):
   • Event ID 4624: Logon Type 3 Kerberos occurring without any matching Event 4769 on domain controllers.
3. Endpoint Memory Artefacts:
   • Ticket inspection via klist or Rubeus revealing expiration timestamps years into the future.

---

Investigation Methods

1. Correlate Event 4768 and Event 4769 Records: Identify accounts requesting service tickets without having negotiated a TGT from an authoritative KDC.
2. Audit Ticket Lifetimes on Suspect Hosts: Inspect cached Kerberos tickets for anomalous validity windows exceeding default policy (10 hours).
3. Verify Historical krbtgt Rotations: Check pwdLastSet on krbtgt to confirm whether a double password rotation was conducted post-incident.

---

Investigative Tooling

• Rubeus:

  Rubeus.exe triage
  Rubeus.exe klist

• PowerShell Event Log Hunt:

  # Hunt for RC4-encrypted service tickets
  Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4769} |
    Where-Object { $_.Properties[2].Value -eq '0x17' } |
    Select-Object TimeCreated, @{N='User';E={$_.Properties[4].Value}}, @{N='Service';E={$_.Properties[0].Value}}

---

Key Takeaways

• Golden Ticket = Forged TGT via krbtgt $\rightarrow$ full domain compromise.
• Silver Ticket = Forged TGS via service secret $\rightarrow$ localized compromise, completely invisible on DCs.
• The signature of a Golden Ticket is a TGS request (4769) without a preceding TGT issuance (4768).
• Remediating a Golden Ticket strictly mandates a consecutive double krbtgt password reset.

---

References & Further Reading

• Microsoft Learn: Kerberos Authentication Overview
• Microsoft Learn: Resetting the krbtgt Password
• Card 21 — NTLM vs Kerberos: Fundamental Differences in DFIR Investigations
• Card 22 — The Kerberos PAC: Structure, Validation, and Forgery
• Card 26 — DCSync: Mechanics, Prerequisites, and Forensic Artefacts