Golden and Silver Tickets are caught by logs that should exist

The scenario is fictional. Event details come from the book and aren't tested on a live domain. Detection only.

After DCSync the attacker holds the krbtgt key. From here on, the evidence changes: instead of "something happened" logs, you hunt for things that should have happened but didn't.

What you'll learn

• What Golden and Silver tickets forge (five lines)
• The decisive absence correlations
• Supporting signals (lifetime, RC4, nonexistent accounts)
• False positives (ticket cache, log gaps)

How it works

1. TGTs are encrypted with the krbtgt key; service tickets with the service key.
2. krbtgt key = forge any TGT (Golden).
3. Service account key = forge a ticket for that service only (Silver).
4. Golden: a service ticket request with no TGT request on record.
5. Silver: the DC is never contacted.

Timeline (incident report facts, UTC)

01:40 svc_web requests many SPNs with RC4; 02:05 Administrator NTLM type 3 from WS01; 02:11 svc_sql 4769 for CIFS/DC01 with no 4768; 02:13 svc_sql (non-DC) requests replication GUIDs (4662); 02:20 Administrator 4769 with no 4768, 10-year lifetime, RC4.

Golden: a 4769 without a 4768

Normal: 4768 then 4769, AES, lifetime within policy. Golden: 4769 alone, RC4, abnormal lifetime, nonexistent or disabled account names.

Silver: member server yes, DC no

Service logon (4624 Kerberos) on the member server, but no 4768/4769 on the DC. You can only see this if both logs are collected centrally. PAC validation can also catch it.

False positives

Log gaps or clock skew can break 4768/4769 pairing (collect healthily, normalize to UTC). Ticket caching can hide DC requests; ask whether an earlier acquisition can be traced. Only fully untraceable privileged access is forgery.

Recovery and defense

Reset krbtgt twice. Use gMSA, enforce AES, disable RC4, enable PAC validation, protect Tier 0.

Next: beacons betray themselves with a clock.

Adapted from chapter 23 of my Japanese book on server defense.