Once you have stolen the right key material, you stop asking Kerberos for tickets and start forging them. Ticket attacks are the endgame techniques of Active Directory: they turn a stolen hash or key into durable, high-privilege access that is hard to detect and, in the worst case, survives password resets. They all build directly on the Kerberos exchange, so read that first if the AS/TGS/PAC vocabulary is not familiar.
The family at a glance
| Attack | Key you need | What you get |
|---|---|---|
| Overpass-the-Hash | A user's NT hash | A legitimate TGT for that user |
| Pass-the-Ticket | A stolen TGT or service ticket | Reuse of that ticket's access |
| Silver Ticket | A service account's key | A forged service ticket for that one service |
| Golden Ticket | The krbtgt key | Forged TGTs for anyone — domain-wide |
| Diamond Ticket | The krbtgt key | A modified real TGT — stealthier than Golden |
Overpass-the-Hash (pass-the-key)
The bridge from NTLM to Kerberos. A user's key for Kerberos is derived from their password — and for RC4, that key is the NT hash. So if you have the NT hash, you can perform a legitimate AS-REQ and receive a real TGT, without knowing the password. This is cleaner than pass-the-hash because from that point on you are using Kerberos, which looks entirely normal.
Pass-the-Ticket
Kerberos tickets are just data, cached in memory (and extractable). If you steal a TGT or service ticket from a compromised host, you can inject it into your own session and use it directly — no key material needed, because the ticket is already the proof. Steal a Domain Admin's cached TGT from a workstation and you are that admin until the ticket expires.
Silver Ticket
A Silver Ticket is a forged service ticket. Recall from the Kerberos page that a service ticket is encrypted with the service account's key, and the service decrypts and trusts it on its own — the KDC is not consulted at the AP-REQ step. So if you have the service account's key (its NT hash or AES key), you can forge a service ticket for that service, with any PAC you like, and the service will accept it.
- Scope: limited to the one service whose key you hold (e.g. CIFS on one host, or MSSQL on one server).
- Stealth: very high — because the KDC is never contacted, there is no ticket-request event on the DC at all.
- Source of the key: a Silver Ticket for a machine account only needs that computer's key, which you get by compromising the host — no DA required.
Golden Ticket
The krbtgt account's key encrypts every TGT in the domain. That is the
root of trust for the entire Kerberos system. If you steal the
krbtgt key — obtainable via DCSync
once you have domain-level access — you can forge a Golden Ticket:
a TGT for any user, with any group membership in its PAC, that the KDC will accept
as genuine because it is signed with the key only the KDC is supposed to have.
| Property | Detail |
|---|---|
| Scope | The entire domain — forge a TGT for anyone, including non-existent admins |
| Persistence | Survives password resets of the impersonated user; only rotating krbtgt (twice) invalidates it |
| Danger | The definitive persistence mechanism — a Golden Ticket is why krbtgt theft means the domain must be considered permanently compromised until remediated |
Rotating the krbtgt password is required twice, with
a replication interval between, because AD keeps the current and previous key valid
to avoid breaking in-flight tickets. A single reset leaves the old key — and any
Golden Tickets — still working.
Diamond Ticket
A Diamond Ticket is the stealthier evolution of the Golden Ticket.
Instead of forging a TGT from scratch (which can be detected by tickets that were
never requested from the KDC), you request a real TGT normally, then
decrypt it with the stolen krbtgt key, modify the PAC (to add
privileged group SIDs), and re-encrypt it. The result is a ticket that has a
matching legitimate request event on the DC — far harder to spot than a Golden
Ticket that corresponds to no request at all.
Detection and defence
| Control | Effect |
|---|---|
Protect the krbtgt key | It is the domain's root of trust — guard DCs, and rotate it twice after any suspected compromise |
| Tier-0 isolation | Keep DA/DC credentials off ordinary workstations so TGTs cannot be stolen by pass-the-ticket |
| Short ticket lifetimes | Limits the window a stolen ticket is useful |
| Monitor anomalous PACs / ticket lifetimes | Forged tickets often have telltale long lifetimes or impossible group claims |
| Watch for tickets without a matching 4768/4769 | A Golden/Silver ticket used with no corresponding request event on the DC is a strong signal |
| Credential Guard | Makes extracting the key material from LSASS much harder in the first place |
The takeaway
These attacks form a ladder of stolen trust. An NT hash gets you a legitimate
ticket (overpass-the-hash). A stolen ticket gets you its owner's access
(pass-the-ticket). A service key lets you forge tickets for that service, silently
(Silver). The krbtgt key lets you forge tickets for the entire domain,
durably (Golden), and do it stealthily (Diamond). Every rung depends on stealing
key material first — which is why credential protection and
controlling who can DCSync matter so much, and
why krbtgt theft is treated as total domain compromise. The forging
tools are in the Toolkit (Impacket's ticketer, Rubeus,
Mimikatz), and the step-by-step commands for each of these attacks live in the
Vulns & Misconfigs section under
Kerberos Ticket Attacks.