Golden Ticket & Silver Ticket Attacks

Kerberos attacks are old news. But they still work on every engagement I do. Specifically, Golden Ticket and Silver Ticket attacks - where attackers forge Kerberos tickets to move laterally or escalate privileges.

If you're doing IR work, you need to understand these attacks. Not because they're clever - but because they're simple and effective. The attacker doesn't exploit a vulnerability in Active Directory. They exploit your misconfigurations, your forgotten service accounts, and the fact that you haven't monitored or restricted ticket granting.

Let me break down what these attacks look like in practice, how they actually work, and what you can do about them. This is a defender's post: I'll keep the attacks conceptual and spend the time where it counts - on detection, prevention, and recovery.

The Kerberos Ticket Granting Ticket (TGT) - Your Golden Ticket Source

Every domain user gets a Kerberos TGT when they log in. The TGT validity period is 10 hours by default, renewable for up to 7 days. The KDC (Key Distribution Center) signs and encrypts this TGT with the KRBTGT account's key.

The KRBTGT account is special. It exists solely to sign Kerberos tickets. It keeps two keys: the current key and the previous key (so tickets stay valid across a password change while the change replicates). If an attacker gets the KRBTGT key material, they can create forged TGTs that the domain will accept as valid.

That's a Golden Ticket attack.

How a Golden Ticket Works, Conceptually

The attacker who has extracted the KRBTGT hash can mint a TGT for any principal they choose - including Domain Admins or Enterprise Admins - and set its properties, including how long it lives. They don't need current admin rights once they hold that hash. The hash is the key.

Here's the part most write-ups get wrong: a Golden Ticket does involve the KDC. The TGT is forged offline, but it still has to be used - and using it means presenting it to the KDC to request service tickets for the resources the attacker wants (file shares, LDAP, WinRM, and so on). Those service-ticket requests are real Kerberos traffic and they generate Event ID 4769 on the domain controller.

What's missing is the front half of the exchange. A legitimate session starts with an AS-REQ that produces Event ID 4768 (a TGT request) before any 4769 service-ticket requests appear. A Golden Ticket skips that step entirely, because the TGT was never requested - it was forged. So the tell-tale signature is a stream of 4769 events with no preceding 4768 from the same account on the same host.

Because the attacker sets the lifetime, a Golden Ticket does not expire when a normal TGT would. Tools default to absurd lifetimes (years), and the attacker can choose whatever they like. Don't assume the ticket follows your domain's 10-hour policy.

Silver Ticket: Targeted Service Access

A Silver Ticket attack is more surgical. Instead of forging a TGT, the attacker forges a service ticket (TGS) for one specific service.

Every Windows service runs as a principal (a user or computer account). The service's own key is used to encrypt its Kerberos service tickets. If the attacker has that account's hash, they can forge a service ticket and present it directly to the service.

This is where there genuinely is no KDC interaction. The forged TGS goes straight to the target service, which validates it against its own key and grants access. No 4768, no 4769 - which is exactly why Silver Tickets are harder to catch than Golden Tickets. The trade-off for the attacker is scope: a Silver Ticket only works against the one service whose key they hold.

Real-World Detection

These attacks can leave minimal traces, but "minimal" is not "none." The mistakes people make are looking for the wrong indicators and giving up.

Golden Ticket Indicators

• 4769 with no matching 4768 - Service-ticket requests from an account/host that never produced a TGT request. This is the strongest generally available signal.
• Tickets for disabled or nonexistent accounts - A forged ticket can name a principal that AD no longer has (or never had). A 4769 for an account that's disabled or doesn't exist is a red flag.
• RC4 tickets in an AES domain - If your environment is standardized on AES, Kerberos activity using RC4 (encryption type 0x17) stands out. Forgery tooling has historically defaulted to RC4.
• DCSync from a non-DC - Because Golden Tickets almost always follow KRBTGT theft via replication, watch for Event ID 4662 containing the replication extended-right GUIDs (1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 and 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2) sourced from any account that isn't a domain controller.

Silver Ticket Indicators

• No KDC record at all - You won't get 4768 or 4769 for the forged service access, so pivot to the service side.
• 4624 on the target host without corresponding KDC events - A successful Kerberos logon on a member server with no matching 4769 on a DC is suspicious, because legitimate Kerberos access to that service should have produced a service-ticket request.

What You Can Actually Do

You can't eliminate these attacks entirely. If an attacker already has DCSync rights or domain admin, they can get the KRBTGT hash. But you can make it harder, shorten the attacker's window, and detect faster.

1. Restrict and Monitor DCSync Rights

DCSync is the usual gateway to both Golden and Silver Tickets. It does not require SeBackupPrivilege - it requires directory replication rights, specifically Replicating Directory Changes and Replicating Directory Changes All on the domain naming context. (The SeBackupPrivilege / VSS copy of NTDS.dit is a separate route to the same data, and worth restricting too, but it's not what makes DCSync work.)

• Audit who holds replication rights - By default only domain controllers and a small set of privileged principals should. Any user or service account with these rights is a finding until proven otherwise.
• Alert on DCSync - Event ID 4662 with the replication GUIDs above, sourced from a non-DC account, is often the first hard sign of compromise.

2. Rotate and Monitor KRBTGT

The KRBTGT password should never change outside deliberate rotation, so a change is meaningful.

• Alert on KRBTGT password changes - Watch for account-management events showing a password set/change on the krbtgt account. Legitimately this happens only when you rotate it.
• Rotate KRBTGT regularly, and twice after any suspected compromise - This is the one people get wrong. KRBTGT keeps a current and a previous key, so a single reset leaves the old key valid - a stolen hash still works. You must reset it twice to fully invalidate stolen key material. Between the two resets, allow time for the first change to replicate to every DC and for tickets issued under the old key to expire - at least the maximum ticket lifetime, 10 hours by default. Reset twice too quickly and legitimate users and services start failing to authenticate. Treat "rotate regularly" as hygiene and "twice, spaced correctly" as incident response.

3. Enable Kerberos Audit Logging

Windows has detailed Kerberos logging you probably aren't fully using.

• Event ID 4768 (TGT requested) - Account name, client address, encryption type.
• Event ID 4769 (TGS requested) - Service name, account name, client address, encryption type.
• Event ID 4770 (TGT renewed) - Unusual renewal patterns.
• Event ID 4624 (logon) - Correlate host-side logons against the KDC events that should accompany them.

The value is in correlation, not any single event: 4769 without a preceding 4768, service tickets for accounts that shouldn't be requesting them, or RC4 where you expect AES.

4. Use the Protected Users Group

Members of Protected Users get enhanced Kerberos protections:

• A shorter, non-renewable TGT lifetime of 4 hours
• No delegation (constrained or unconstrained)
• No NTLM, no RC4, no DES for these accounts

This doesn't prevent a Golden Ticket (the attacker holds the KRBTGT key), but it limits the blast radius after compromise and blocks pass-the-hash against those accounts. Put your privileged accounts in it - after testing, since it will break anything that depends on delegation or legacy protocols.

5. Deal With Unconstrained Delegation

Unconstrained delegation is dangerous for a specific reason: when a user authenticates to a server configured for it, that server caches the user's TGT in memory. Anyone who compromises such a server can harvest the TGTs of everyone who has connected to it - including, if you're unlucky, a Domain Admin or a domain controller's ticket. It's not a "Golden Ticket enabler" in the KRBTGT sense; it's a TGT-harvesting sink.

• Prefer constrained delegation - Specify exactly which services a host may impersonate users to, and use resource-based constrained delegation where you can.
• Find unconstrained delegation - Enumerate computer accounts with the TrustedForDelegation flag set. Your DCs will have it (that's expected); anything else deserves scrutiny.
• Remove the flag once you've confirmed it isn't needed:
  Set-ADComputer -Identity <computer> -TrustedForDelegation $false

A Real Example from a Recent Engagement

I inherited a compromised environment where the attacker had been present for months.

How did they get in? A service account with a weak, long-unchanged password on a file server. On its own that account had only ordinary directory read access - it could not DCSync. What made it dangerous was that, years earlier, someone had granted that same account replication rights for a since-forgotten sync tool and never removed them. That combination - a crackable password plus stale replication rights - was the whole ballgame.

Once they had the password, they authenticated as that account, used its replication rights to DCSync the KRBTGT hash, forged a TGT for a Domain Admin, and moved laterally.

The indicators were there, subtle but present:

• Event ID 4662 with replication GUIDs sourced from a non-DC account
• 4769 service-ticket requests for CIFS on file servers from workstations that never normally touched those shares, with no preceding 4768
• RC4 tickets in an environment that was otherwise AES
• Kerberos activity at 2-4 AM

We disabled the compromised account, stripped its replication rights, reset KRBTGT twice (allowing replication between resets), reset privileged passwords, and stood up proper Kerberos and DCSync monitoring.

Final Thoughts

Golden and Silver Ticket attacks aren't sophisticated. They're basic Kerberos abuse against environments that haven't been hardened or monitored. Your defense comes down to four things:

1. Control DCSync - Audit replication rights; alert on 4662 with replication GUIDs from non-DC accounts.
2. Monitor Kerberos properly - Look for 4769 without 4768, tickets for disabled/nonexistent accounts, and RC4 in an AES domain - not the krbtgt-service red herring.
3. Rotate the right things the right way - KRBTGT twice after compromise, weak service-account passwords replaced.
4. Limit privilege - Constrained over unconstrained delegation, Protected Users for critical accounts.