Kerberos Attack Paths: Golden Tickets, Silver Tickets and Kerberoasting

TL;DR — Kerberos is the authentication backbone of Active Directory, and its attack paths are the lingua franca of domain compromise: with the KRBTGT account’s hash you can mint any ticket for any user (Golden Ticket); with a single service account’s hash you can forge tickets the domain controller never sees (Silver Ticket); and with nothing but a domain account you can harvest crackable service credentials wholesale (Kerberoasting). All three are pure logic abuse — no exploits, no memory corruption — which is why they map to ATT&CK persistence and credential-access techniques rather than exploit categories, and why their detections live in event logs and encryption-type anomalies rather than vulnerability scanners.

Most enterprise compromise narratives converge on the same room: an attacker with a foothold wants the domain, and the paths there run through Kerberos. The protocol itself is elegant — mutually authenticated, ticket-based, designed so passwords never cross the wire. Its attacks are equally elegant, which is the uncomfortable part: they mostly use the protocol as designed, with one secret the attacker shouldn’t have. This is a different flavor of problem than the credential-exposure chains we covered in SSRF to cloud metadata — but the same shape: a powerful, trusted service plus one leaked secret equals total compromise.

Kerberos in Four Sentences

A client authenticates to the Key Distribution Center (KDC) — on Windows, the domain controller — and receives a Ticket Granting Ticket (TGT), encrypted with the KRBTGT account’s key. To reach a service, the client presents the TGT and asks for a service ticket, which the KDC encrypts with the service account’s key. The client presents that ticket to the service, which can decrypt it — proof the KDC vouched for the client — and includes the client’s membership in PAC (Privilege Attribute Certificate) form. Everything hinges on two long-term secrets: the KRBTGT hash and each service account’s hash. Guess which two. (The PAC itself has a history worth knowing: forged-PAC privilege escalation was the class behind 2014’s MS14-068, and signature validation of that structure has been a recurring weak seam in otherwise sound exchanges.)

The Three Classic Attack Paths

Golden Ticket (T1558.001). The TGT is encrypted with the KRBTGT key, so whoever holds that key can fabricate TGTs offline — for nonexistent users, for Domain Admins, with arbitrary lifetimes. It’s the definitive persistence primitive: reset every administrator password in the forest and a pre-existing golden ticket can keep working until the KRBTGT password is rotated (twice, to age out keys cached on every DC) or the domain is rebuilt. Attackers get the hash from a DC (via credential dumping), which is why “how did you get the KRBTGT hash?” is the real incident question.

Silver Ticket (T1558.002). With a service account’s hash — say, the SQL service account — you forge service tickets directly, never contacting the KDC. Scope is nominally one service, but services like MSSQL, SharePoint or IIS run with the privileges of powerful accounts, and a forged ticket can include an arbitrary PAC: the “limited” scope of a silver ticket is the scope of what that service account can reach. The detection twist: because the KDC is bypassed entirely, the usual TGS-request telemetry (event 4769) never fires — you must detect at the service, not the domain controller.

Kerberoasting (T1558.003). The gentlest entry: any authenticated domain user can request service tickets for any account with a Service Principal Name. Those tickets are encrypted with the service account’s key — so the responses are offline-crackable password material, popularized by Tim Medin at DerbyCon 2014. The attack surface is every SPN-owning account whose password is weak; the jackpot is a service account running as Domain Admin with “Summer2024!” as its password. Tools like Rubeus and Impacket’s GetUserSPNs made this a five-minute exercise, and it remains a default step in nearly every modern intrusion report.

Detection: Where the Signals Live

Because these are protocol-logic attacks, the detections are telemetry-logic rules — exactly the kind of work we described in detection engineering with Sigma:

• Encryption-type anomalies (4769, 0x17). Modern environments should negotiate AES (0x11/0x12); Kerberoasting tooling historically requested RC4-HMAC (encryption type 0x17) because it’s fast to crack. Event 4769 (Kerberos service ticket requested) showing RC4 is the classic high-value signal — elevated when the requesting account is unusual or the request volume is enumeration-like.
• Ticket-lifetime anomalies. Golden Tickets with fabricated lifetimes (10-year defaults from old tooling, or any value exceeding domain policy) surface as impossible ticket ages. MITRE’s own detection guidance for T1558.001 centers on correlating anomalous lifetimes and unexpected encryption types.
• SPN sweeps. A single account requesting service tickets across dozens of unrelated SPNs in a short window is enumeration, whatever tool produced it.
• Absence-of-KDC patterns. Silver Ticket’s superpower — no KDC event — means detection must include service-side authentication mismatches and alerting on “service authenticated principals that never requested a ticket.”
• Runtime corroboration. Endpoint tooling watching LSASS access (the credential-dumping prerequisite that yields the KRBTGT hash in the first place) closes the loop upstream; eBPF-based sensors like those described in our eBPF explainer make that visibility cheap on Linux footholds and jump boxes.

Hardening That Actually Shrinks the Surface

1. Rotate KRBTGT twice, on a schedule. The only real cure for golden tickets is aging out the key — and the double rotation is a well-documented operational minefield (password history caching on DCs), so it belongs in a change window with rollback, not a Friday afternoon.
2. Eliminate service accounts with SPNs running as administrators. Kerberoasting’s blast radius is exactly the privilege of the cracked accounts. Managed group accounts (gMSAs, with automatic 256-bit passwords) or delegated machine accounts remove the weak-password class entirely.
3. Enforce AES. Domain functional levels and account options that refuse RC4 collapse the Kerberoasting signal into a clean anomaly: any 0x17 is now worth paging on.
4. Hunt for the prerequisite, not the technique. All the forgeries need a hash first; credential-dumping detection on DCs and tier-0 assets is the upstream control that matters most.
5. Monitor long-tail persistence. A re-detected “impossible ticket” months after an incident is the difference between closure and a false one — log retention on Kerberos events should match your longest plausible persistence window, not your cheapest storage tier.

Key Takeaways

• Golden Ticket = KRBTGT hash → forge any TGT, domain-wide persistence; remediation requires rotating KRBTGT (twice) and treating existing tickets as burned.
• Silver Ticket = service account hash → forged service tickets the KDC never sees, so 4769 telemetry is structurally absent; detect at the service.
• Kerberoasting = any domain user can harvest SPN service tickets and crack them offline (Tim Medin, 2014); watch event 4769 for RC4/0x17 and enumeration-shaped SPN sweeps.
• All three are logic abuse of a sound protocol — detections are log-analytics rules (lifetimes, encryption types, absence patterns), not vulnerability scans.
• The strongest hardening is upstream: no admin-privilege SPN accounts (gMSAs), AES-only, and credential-dumping detection on tier-0.

FAQ

Why is it called a Golden Ticket?
Because possessing the KRBTGT hash is the Willy Wonka pass: one secret mints tickets for anyone, with any privileges, for however long you like — the whole domain trusts whatever the “golden” key signs.

What’s the difference between Golden and Silver Tickets?
The secret and the scope: golden uses the KRBTGT key to forge TGTs (everything, forever, until the key rotates); silver uses one service account’s key to forge service tickets (that service’s reach, invisible to the KDC).

Is Kerberoasting noisy?
The requests themselves look legitimate — that’s the point. The signals are statistical: RC4 encryption types in an AES environment, unusual requesters, and enumeration-shaped SPN coverage in short windows.

Do password resets fix a Golden Ticket?
User password resets don’t — the forged TGTs reference fabricated users and groups anyway. Rotating the KRBTGT account (ideally twice, days apart) invalidates new forgery; existing tickets age out per domain policy.

Are Linux/Unix realms affected?
MIT Kerberos realms have the same architecture and the same classes of abuse; the attack names come from the Windows tooling ecosystem, but the protocol mathematics is identical.

What’s the single best control?
Removing weak-password service accounts with SPNs — via managed service accounts — eliminates Kerberoasting yield and shrinks Silver Ticket scope, killing two paths with one housekeeping project.

References

1. MITRE ATT&CK — T1558.001 Golden Ticket (detection guidance)
2. MITRE ATT&CK — T1558.002 Silver Ticket
3. MITRE ATT&CK — T1558.003 Kerberoasting
4. RFC 4120 — The Kerberos Network Authentication Service (V5)
5. Microsoft — Kerberos authentication overview
6. Microsoft — Event 4769: Kerberos service ticket requested
7. Varonis — Kerberos attack: Silver Ticket edition
8. CrowdStrike — What is Kerberoasting?
9. GhostPack — Rubeus (Kerberos interaction toolkit)
10. ADSecurity — Kerberos Golden Ticket protection

Current as of September 2026. Educational reference — test detection coverage only in environments you are authorized to assess.

Published by Hmmnm

Hands-on cybersecurity tutorials, CVE breakdowns, and guided learning paths — written and lab-tested by the Hmmnm team.

Learning Paths · About Hmmnm · Editorial policy