Golden Tickets and Silver Tickets: How Attackers Forge Kerberos and How to Catch Them

Most attacks are noisy on the way in and quiet once they own the domain. Kerberos ticket forgery is what makes the "quiet" part possible. When an adversary reaches Domain Admin, the very last thing a good operator does before you notice is extract one specific secret — the krbtgt account's password hash — because that single value lets them forge authentication tickets at will. From then on they don't need to steal a password again, exploit a service, or trip your lockout policy. They just ask themselves for a ticket and Active Directory believes it.

This is the technique behind the phrase "assume breach." A forged Golden Ticket is the difference between an incident you can evict with a password reset and one where the attacker is still walking back in three weeks after you thought you were clean.

How Kerberos Trust Actually Works

Kerberos is a ticketing protocol. When you log on, the domain controller's Key Distribution Center (KDC) issues you a Ticket Granting Ticket (TGT), encrypted with the krbtgt account's key. When you want to reach a specific service — a file share, SQL, a web app running under a service account — you present that TGT and get back a service ticket (TGS), encrypted with that service account's key.

The critical design fact: the KDC does not re-check the user's rights when a ticket is presented. It trusts the ticket because it can decrypt it. The group memberships and privileges are baked into a structure called the PAC (Privilege Attribute Certificate) inside the ticket. Whoever holds the encryption key controls what the ticket says.

Golden Ticket: forging the TGT

A Golden Ticket is a TGT the attacker builds themselves using the stolen krbtgt hash. Because they hold that key, they can stamp any username, any group SIDs (including Domain Admins and Enterprise Admins), and any lifetime they like — tools default to a ten-year validity. The forged PAC can even name accounts that don't exist. The domain controller decrypts it, sees "Domain Admin," and issues service tickets accordingly.

Silver Ticket: forging the service ticket

A Silver Ticket skips the KDC entirely. If the attacker steals the password hash of a single service account (or a computer account, which is just an account whose name ends in $), they can forge a TGS directly for that one service. It's stealthier — there's no TGT request logged on the DC at all — but scoped to whatever that account can reach. Steal a SQL service account's key, forge a Silver Ticket, own that database host. No Domain Admin required.

The uncomfortable part: resetting a compromised user's password does nothing to a Golden Ticket. The ticket is signed with the krbtgt key, not the user's. To truly revoke it you must reset the krbtgt account password twice (the account keeps its two most recent keys), and let replication settle.

Why This Is So Hard to Detect on the Wire

Forged tickets are valid Kerberos. They decrypt cleanly, so nothing "fails." Classic tells exist — a TGT with an absurd 10-year lifetime, an RC4-encrypted ticket in an AES-only environment, a ticket whose account name doesn't resolve to a real SID, or Event ID 4769 (service ticket requested) with no preceding 4768 (TGT issued) — but a careful operator forges tickets with realistic lifetimes and AES keys to blend in. Network-only detection is a losing game.

That's why the durable signal is on the endpoint: the credential theft that precedes forgery. Nobody forges a Golden Ticket out of thin air. First they dump the krbtgt hash — via a DCSync replication request from a non-DC host, an LSASS memory read on a domain controller, or offline extraction from a stolen NTDS.dit. Catch that, and the forged tickets never get minted.

What WinSentinel Watches on Each Host

WinSentinel runs on the machine itself, so it sees the local preconditions and artifacts that a network sensor misses. Every one of the 33 modules runs at full power on the free single-machine agent — there's no "credential module" locked behind a paywall. Relevant checks include:

• LSASS access hygiene. Flags whether LSA protection (RunAsPPL) and Credential Guard are enabled, and surfaces suspicious LSASS handle opens — the read that harvests the hashes forgery depends on.
• Kerberos policy posture. Reports maximum ticket lifetime, whether RC4 is still permitted (a forgery-friendly weakness), and whether krbtgt hasn't been rotated in a long time — a stale krbtgt means an old Golden Ticket could still be live.
• DCSync-capable rights. On domain controllers, highlights non-DC principals granted the replication rights (Replicating Directory Changes All) that enable a remote hash dump.
• Event log integrity. Ensures Kerberos auditing (4768/4769/4770) is actually on and not being cleared — because attackers who forge tickets also love to wipe the trail.

$ winsentinel --audit --modules credentials,kerberos

 Kerberos & Credential Exposure
 ─────────────────────────────────────────────────────
 [CRITICAL] krbtgt password last set 1,284 days ago
   → A Golden Ticket forged any time since is still valid.
   → Fix: reset krbtgt twice (allow replication between resets).

 [WARNING]  RC4 (etype 23) still permitted for Kerberos
   → Enables downgrade + eases offline ticket forgery.
   → Fix: enforce AES via "Network security: Configure
     encryption types allowed for Kerberos".

 [WARNING]  LSA Protection (RunAsPPL) not enabled
   → LSASS memory readable → krbtgt/service hashes exposable.

 [INFO]     Max TGT lifetime = 10 hours (default) — OK

The Practical Playbook

You will not "block" Golden Tickets — the design trusts the key. You shrink the window and force the noise:

• Rotate krbtgt twice, on a schedule (and immediately after any suspected DA compromise). This is the only thing that invalidates existing Golden Tickets.
• Enforce AES, kill RC4. AES-only tickets make forgeries stand out and remove a downgrade path.
• Turn on Credential Guard and LSA Protection to make the upstream hash theft dramatically harder.
• Tier your admins. Never log a Domain Admin onto a workstation; that's how the krbtgt-adjacent keys leak to a machine the attacker already owns.
• Alert on the precursors — unexpected DCSync, LSASS reads on DCs, cleared security logs — not just on the tickets themselves.

For a single machine, run the audit and fix what it flags today. For a fleet, this is exactly where centralized orchestration earns its keep: WinSentinel Pro rolls every host's Kerberos and credential posture up to a central node, so "krbtgt is 1,200 days stale on 40 machines' domain" or "RC4 re-enabled across an OU" becomes one drift alert instead of a finding you'd have to notice on each box independently. The forgery happens in seconds; catching the conditions that allow it is a posture problem, and posture is what you manage across the fleet.

Run winsentinel --audit now. If your krbtgt hasn't been rotated this year, that's your weekend. If RC4 is still on and LSASS is unprotected, an attacker who reaches your DC gets a decade-long skeleton key — and no password reset will take it back.