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 technically, and what you can do about them.

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 this TGT with the KRBTGT account's NTLM hash.

The KRBTGT account is special. It exists solely to sign Kerberos tickets. Two hashes: one for the current key, one for the previous key (for replication safety). If an attacker gets these hashes, they can create fake TGTs that the domain will accept as valid.

That's a Golden Ticket attack.

Golden Ticket Attack Workflow

1. Gain access to the KRBTGT hash — This usually happens after DCSync (using SeBackupPrivilege, VSS copy of NTDS.dit, or other methods to extract domain controller data).
2. Forge a TGT — The attacker creates a Kerberos TGT for any user they want (including Enterprise Admins or Domain Admins). They sign it with the KRBTGT hash, making it cryptographically valid.
3. Inject into memory — Using tools like Mimikatz or Impacket's goldenPass.py, the attacker injects this forged TGT into their current session.
4. Access anything — With a valid TGT, the attacker can request service tickets for any service in the domain: CIFS (file shares), LDAP, RPC, WinRM, whatever they need.

The Golden Ticket doesn't expire when the legitimate TGT expires. It lasts for the duration specified in the ticket (up to 10 hours), and can be renewed within the 7-day window. The attacker controls the timing.

Silver Ticket: Targeted Service Access

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

Every Windows service runs as a principal (user or computer account). The service's NTLM hash is used to sign its Kerberos service tickets. If you have that hash, you can forge a service ticket and present it directly to the service.

Silver Ticket Attack Workflow

1. Get the target service's NTLM hash — This is usually a computer account (like DC01$) or a domain user running a service. You get this through DCSync, password spray, or credential dumping.
2. Forge a service ticket — Create a TGS (Ticket Granting Service) request for the specific service you want (like CIFS\DC01, RPCSS, LDAP). Sign it with the service account's hash.
3. Connect directly — Present the forged ticket to the target service. The service validates it against its own hash and grants access.

No TGT needed. No interaction with the KDC. The attacker goes straight to the target service.

Real-World Detection Challenges

Here's where it gets tricky: these attacks often leave minimal traces in your logs.

Golden Ticket Detection Issues

• No KDC interaction — Since the attacker creates the TGT locally with a copied hash, there's no communication with the domain controller during forging or ticket usage.
• Event ID 4768 (TGT request) — You might see legitimate TGT requests from the attacker's machine, but you can't distinguish them from the forged ones without deep packet inspection.
• Event ID 4624 (Logon) — You'll see successful logons, but Kerberos authentication (type 3) doesn't distinguish between real and forged tickets in the event log.

Silver Ticket Detection Issues

• No KDC interaction at all — The attacker bypasses the KDC entirely. No Event ID 4768, no Event ID 4769.
• Event ID 4624 only — You see a successful logon, but the authentication package is Kerberos. Without analyzing the ticket itself, you can't tell it's forged.

The only reliable detection path is monitoring for anomalous Kerberos ticket usage patterns—like a user requesting tickets for services they've never accessed before, or unusual service logons from atypical locations.

What You Can Actually Do

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

1. Restrict DCSync Rights

DCSync is the gateway to both Golden and Silver Ticket attacks. It requires SeBackupPrivilege or equivalent.

• Limit who has SeBackupPrivilege — Only domain admins should have it by default. Audit any non-admin accounts with this right.
• Monitor DCSync attempts — Look for Event ID 4662 with properties containing "ds-Replication-Sync" or "ds-Get-Changes". This is often the first sign of compromise.

2. Monitor KRBTGT Hash Changes

The KRBTGT hash should never change outside of scheduled rotation.

• Set up alerts for Event ID 4769 with service "krbtgt" — Actual KRBTGT ticket requests are rare. If you see them, investigate.
• Rotate KRBTGT passwords periodically — Microsoft recommends every 90 days. This invalidates any stolen KRBTGT hashes.

3. Enable Kerberos Audit Logging

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

• Event ID 4768 (TGT requested) — Log Username, Client Address, Service Name.
• Event ID 4769 (TGS requested) — Log Target Server, Client Address, Service Name.
• Event ID 4770 (TGT renewed) — Monitor for unusual renewal patterns.
• Event ID 4675 (SIDs filtered) — Indicates potential privilege escalation attempts.

Combine these with SIEM correlation: if a user requests tickets for services outside their normal pattern, flag it.

4. Use Protected Users Group

Members of the Protected Users group have enhanced Kerberos protections:

• No TGT caching beyond 8 hours
• No delegation (constrained or unconstrained)
• NTLM authentication disabled

This doesn't prevent Golden Ticket attacks (the attacker has the hash), but it does limit what happens after compromise. Protected Users can't be pass-the-hash attacked, and their tickets can't be cached as long.

5. Implement Constrained Delegation Carefully

Unconstrained delegation is a Golden Ticket enabler. If a server has unconstrained delegation, any service ticket presented to that server can be forwarded to any other service.

• Use constrained delegation instead — Specify exactly which services the delegated server can impersonate users to.
• Audit delegation settings — Run Set-ADUser -Identity <user> -PrincipalsAllowedToDelegateToAccount $null to reset delegation rights on critical accounts.

A Real Example from My Latest Engagement

Last month, I inherited a compromised environment where the attacker had been present for 6 months.

How did they get in? A service account with password "Service2023!" on a file server. That account had domain read access.

Once they had that password, they used it to bind to LDAP and extract the KRBTGT hash via DCSync. Then they created a Golden Ticket for "Administrator" and started moving laterally.

The indicators were subtle:

• Event ID 4624 with Logon Type 3 (network logons) from internal IPs to file servers
• Unusual service tickets requested for CIFS\FILE01 from workstations that don't normally access file shares
• Kerberos ticket requests at odd hours (2 AM - 4 AM)

The smoking gun was Event ID 4768 showing a TGT request for "krbtgt" service—a normal user shouldn't ever request tickets for the KRBTGT service.

We disabled the compromised service account, rotated KRBTGT passwords, reset all admin passwords, and implemented better Kerberos monitoring.

Final Thoughts

Golden Ticket and Silver Ticket attacks aren't sophisticated. They're basic Kerberos exploitation against environments that haven't been hardened or monitored.

Your defense isn't about finding exotic detection rules. It's about:

1. Preventing DCSync — Restrict who can read NTDS.dit
2. Monitoring Kerberos activity — Look for anomalous patterns, not just specific events
3. Rotating critical passwords — KRBTGT, service accounts, admin accounts
4. Limiting privileges — Constrained delegation instead of unconstrained, Protected Users for critical accounts

If you can do these four things, you'll catch most attackers before they get to the point of forging tickets. And if they do forge one, you'll detect it quickly.