Why can stored Kerberos tickets be stolen, and what is a pass-the-ticket attack?
Tickets and their session keys sit in a credential cache on the client (originally a file in /tmp on multi-user Unix systems); whoever copies that cache can present the tickets as the user (pass-the-ticket) until they expire, without knowing the password.
Kerberos was originally designed for single-user workstations. On a shared Unix machine the credential cache was a file in /tmp, and anyone with root access (or a careless permission) could copy another user's tickets. Today the same idea is used against Windows: tools dump tickets from the memory of the logon process.
Why it works: a ticket plus its session key is everything a client needs. The attacker builds fresh authenticators with the stolen session key, so the timestamp checks pass. Timestamps and replay caches only stop replaying captured network messages; they do not stop someone who has the key material itself.
What limits the damage:
- Short ticket lifetimes, so stolen tickets expire soon.
- Protected caches: per-user kernel keyrings on Linux, isolated credential storage (for example Credential Guard) on Windows.
- Endpoint security and least privilege, because dumping tickets usually needs administrator rights on the client.
Go deeper:
MITRE ATT&CK: Pass the Ticket (T1550.003) — how stolen tickets are reused, with detection and mitigation advice.- Tarlogic: How to attack Kerberos? — overview of the main attacks, from pass-the-ticket to golden tickets.