What is a Golden Ticket Attack?

Definition

A Golden Ticket attack is an Active Directory persistence and impersonation technique in which an attacker uses the KRBTGT account's password hash to forge arbitrary Kerberos Ticket Granting Tickets (TGTs). With a Golden Ticket, the attacker can impersonate any user, including non-existent accounts, and access any service in the domain.

It is MITRE ATT&CK T1558.001.

In simple terms:

The KRBTGT hash is the master key of the domain. Steal it once and you can forge any identity for as long as KRBTGT isn't rotated twice.

---

Why Golden Tickets Are Devastating

• Bypass normal password and group policy.
• TGTs can be issued with arbitrary lifetimes (default 10 hours; attackers often use 10 years).
• Valid for any user, even ones that don't exist in AD.
• Survive most clean-up: password resets, account disablements, group changes.
• Persistence ends only when KRBTGT is rotated twice.

A Golden Ticket is the textbook way to maintain persistent Domain Admin equivalence in a compromised environment.

---

Prerequisites for a Golden Ticket

Attacker needs the KRBTGT hash, plus the domain SID and FQDN.

The KRBTGT hash is obtained by:

• DCSync from a DC.
• NTDS.dit theft (backup, snapshot).
• Compromise of a DC.

Once they have it, they're free to forge.

---

How a Golden Ticket Works

Forging

Tools (Mimikatz kerberos::golden, Impacket's ticketer.py):

mimikatz # kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-... /krbtgt:<hash> /id:500 /groups:512,513,518,519,520 /ptt

The attacker specifies:

• User name (real or fake).
• Group memberships (e.g., 512 = Domain Admins).
• Lifetime (default usually 10 years).
• TGT encryption type.

Use

The forged TGT is loaded into the session (Pass-the-Ticket) and presented to any service. The DC issues service tickets without questioning the TGT — because it's signed with the real KRBTGT key.

Detection Difficulty

• TGT was never issued by a real KDC, so AS events are missing.
• Service tickets look real.
• Some forensic anomalies exist (long ticket lifetimes, encryption type mismatches, Privileged Attribute Certificate (PAC) anomalies).

---

Real-World Examples

1. Persistence After Cleanup

After incident response, defenders reset Domain Admin passwords and remove the attacker's accounts. The attacker still holds KRBTGT hash from earlier and forges Golden Tickets to walk back in.

2. APT Persistence

Multiple APT groups have used Golden Tickets to maintain access for years. KRBTGT is rarely rotated, so a single DCSync gives long-term access.

3. Forged Non-Existent Admin

Attacker forges a TGT for "JohnSmithAdmin" who doesn't exist. Because the TGT is signed with KRBTGT, every DC accepts it; the SID and group claims grant Domain Admin equivalence.

---

Related Attacks

• Silver Ticket — forged service ticket using a service account hash, scoped to one service.
• Diamond Ticket — modifies a legitimate TGT to add privileges, blending with normal traffic.
• Sapphire Ticket — exploits PAC validation gaps for stealthier forgery.
• Skeleton Key — DC patch that accepts a master password for any user.

---

Defense Against Golden Tickets

Protect KRBTGT

1. Rotate KRBTGT twice per year (twice consecutively because KRBTGT keeps the previous key).
2. Rotate KRBTGT twice immediately after any suspected compromise.
3. Use Microsoft's official KRBTGT reset script (or equivalent).

Protect DCs and DCSync

4. Treat all DCs as Tier 0.
5. Audit and minimize replication rights to prevent DCSync.
6. Monitor for DCSync events.
7. Secure NTDS.dit backups.

Cryptography

8. Disable RC4 Kerberos encryption types where possible — Golden Tickets in RC4 stand out more easily when AES is the norm.
9. Force AES for the KRBTGT account.

Detection

10. Monitor TGT lifetimes — alert on anomalously long ticket lifetimes.
11. Watch for users with no AS event but TGS events (forged TGT used to request services).
12. Detect PAC anomalies with EDR / ITDR products.
13. Honeypot accounts — alert on any TGS request for non-existent users.

Tier 0 Hygiene

14. PAWs and JIT for any account near KRBTGT exposure.
15. Forest recovery procedures — practice them.

---

Golden Ticket Defense Checklist

• KRBTGT rotated twice within last 6 months?
• KRBTGT rotation script tested and ready?
• DCSync rights audited and minimized?
• RC4 disabled / AES enforced for KRBTGT and accounts?
• Long TGT lifetime alerts in SIEM?
• Forged-ticket / PAC anomaly detections via EDR/ITDR?
• Honeypot user with TGS-request alerts in place?
• Forest recovery plan tested?

---

How Forestall Helps

Forestall maps the paths that lead to KRBTGT exposure:

• DCSync rights (direct and effective).
• Tier 0 paths to DC compromise.
• Backup paths that could yield NTDS.dit.
• KRBTGT password age and crypto support.
• Stale Golden Ticket-relevant configurations.

Combined with detections in your SIEM/EDR, this closes both the path to KRBTGT and the time it takes to detect a forged ticket.

---

Frequently Asked Questions

How long does a Golden Ticket persist?

Until KRBTGT is rotated twice. Without rotation, attackers can use the same hash for years.

Why rotate KRBTGT twice?

KRBTGT keeps the current and previous password to allow tickets in flight to validate. One rotation invalidates pre-rotation tickets only after the second.

Can I detect Golden Tickets reliably?

Detection is hard but improving. Long lifetimes, missing AS events, PAC anomalies, encryption mismatches, and ITDR products help.

Should I rotate KRBTGT regularly even without incidents?

Yes — twice per year is the standard recommendation.

Does disabling RC4 prevent Golden Tickets?

It makes them harder to forge undetected (AES tickets stand out less, but force more crypto rigor) and aligns with broader hardening.

---

Conclusion

Golden Ticket attacks turn one bad day on a Domain Controller into permanent invisibility for the attacker. The defenses are straightforward but require discipline: rotate KRBTGT twice per year, minimize DCSync rights, treat DCs and their backups as Tier 0, force modern crypto, and detect anomalies in Kerberos traffic. Combined, these controls make Golden Ticket persistence both rarer and shorter — and shrink one of the most damaging long-tail risks in Active Directory.