Pass-the-Ticket Attacks: Step-by-Step Mechanics and Defense
Attackers bypass password checks entirely by stealing encrypted authentication tokens, rendering standard credential rotation ineffective against active session hijacking.

Pass-the-ticket attacks steal Kerberos ticket-granting tickets from memory after initial compromise. The attacker injects these tickets into their session to access resources without knowing the password. Defense requires monitoring for anomalous ticket creation and restricting service account privileges.
The Authentication Shortcut
Network authentication often relies on Kerberos, a protocol that uses tickets to prove identity. Instead of sending passwords over the wire, a client requests a ticket from a Key Distribution Center. This ticket is encrypted and serves as a digital badge. If an attacker compromises a machine, they do not need the password. They can simply copy the badge already in memory. This is the core of a pass-the-ticket attack.
The attack is silent because it uses valid, existing credentials. No password guessing occurs. No brute-force logs are generated. The system sees a legitimate ticket and grants access. This makes traditional perimeter defenses blind to the intrusion. The attacker moves laterally by presenting stolen badges to other services.

### Stage 1: Initial Access and Credential Harvesting
The sequence begins when an attacker gains a foothold on a workstation or server. They achieve this through phishing, exploiting a vulnerability, or reusing stolen credentials. Once inside, they need a way to authenticate to other systems. They cannot simply guess passwords. They must extract the active authentication tokens.
The attacker targets the LSASS process, which manages logons in Windows. This process holds the cryptographic keys and tickets in memory. Techniques for LSASS credential theft are common in modern intrusions. The attacker runs a tool to dump this memory. They extract the Kerberos tickets, specifically the Ticket-Granting Ticket and service tickets. These files are encrypted, but the attacker has the keys to decrypt them on their machine.
### Stage 2: Ticket Extraction and Manipulation
With the tickets in hand, the attacker prepares them for reuse. The tickets are bound to the user account that created them. They may also be bound to the machine that created them, depending on configuration. The attacker checks if the tickets are constrained. If they are unconstrained, they can request access to any service.
The attacker may also modify the tickets. They can change the timestamp to extend validity. They might strip machine-specific constraints if the protocol allows. This step is technical and requires understanding the ticket structure. The goal is to make the ticket flexible enough to access high-value targets. The attacker does not need to know what is on the target server. They just need a ticket that the server will accept.
### Stage 3: Injection and Lateral Movement
The attacker now moves to the next phase. They take the stolen ticket and inject it into their own session. This is not a login. It is a substitution. The attacker’s process now holds the victim’s ticket. When the attacker requests access to a file server or database, they present this ticket.
The target service checks the ticket with the Key Distribution Center. The KDC validates the signature and expiration. If valid, the service grants access. The attacker is now operating as the victim. They can read files, execute commands, or install software. This movement is lateral. It spreads the breach from one machine to another. The attacker repeats this process, hopping from server to server.
### Stage 4: Persistence and Privilege Escalation
The attack does not stop at lateral movement. The attacker looks for higher privileges. They target domain controllers or administrative accounts. If they steal a ticket from an admin, they can escalate their access. They may create new admin accounts or modify group policies.
To maintain access, the attacker might create scheduled tasks that run their tools periodically. This ensures they can re-inject tickets if the session expires. They may also install backdoors. The goal is to own the environment. The stolen ticket is just the key to the door. Once inside, they fortify their position. This persistence makes removal difficult.
See also: Incident Triage Meaning: How to Prioritize Alerts Fast
Where the Chain Breaks
Understanding the stages reveals where to intervene. The attack relies on memory access and ticket validity. Defenses must address both. You cannot stop the attack by changing passwords alone. The ticket remains valid until it expires. You must monitor for the extraction and injection phases.
Detection requires looking for unusual behavior. A service account accessing a web server is suspicious. A workstation requesting access to a database is anomalous. You need baseline behavior to spot deviations. Threat intelligence feeds help identify known tools used for extraction. But you must also detect new variants.
| Stage | What happens | Where it can be stopped |
|---|---|---|
| Initial Access | Attacker compromises a host and runs extraction tools. | Endpoint detection prevents memory dumping of LSASS. |
| Extraction | Tickets are copied from memory to disk or network. | Monitoring for process injection and unusual API calls. |
| Injection | Attacker loads stolen ticket into their session. | Alert on ticket usage from unexpected source IPs or machines. |
| Lateral Movement | Attacker accesses other systems using the ticket. | Restricting service account rights and monitoring for anomalous access patterns. |
The Hidden Cost of Trust
The biggest flaw in this attack vector is the trust model. Systems trust the ticket because it is signed by the KDC. They do not re-verify the user’s intent. This is efficient but dangerous. It assumes the ticket holder is the ticket owner. In a compromised environment, this assumption fails.
You must reduce the value of each ticket. Use constrained delegation. This limits where a ticket can be used. If a ticket can only access one service, the attacker gains little from stealing it. This limits lateral movement. It forces the attacker to compromise more machines to gain broader access.
Detection Beyond Logs
Standard logs often miss these attacks. Successful logins look normal. You need to correlate data. Look for high-volume ticket requests. Look for tickets used outside business hours. Look for service accounts accessing user resources. These patterns indicate abuse.
Integrate this with cyber threat intelligence. Feed indicators of compromise into your detection rules. Look for known extraction tool signatures. But do not rely solely on signatures. Attackers change their tools. Behavioral analysis is more durable. It catches the technique, not the tool.
Mitigating the Risk
Start by hardening your endpoints. Prevent unauthorized access to LSASS. Use virtualization-based security to protect memory. This raises the bar for extraction. Then, monitor your network. Look for Kerberos traffic anomalies.
Implement least privilege. Ensure service accounts have minimal rights. Use group-managed service accounts where possible. These accounts rotate passwords automatically and cannot be used for interactive logins. This reduces the impact of a stolen ticket.
Finally, practice incident response. Simulate pass-the-ticket attacks. Test your detection rules. Ensure your team knows how to revoke tickets quickly. Speed matters. The longer the ticket is valid, the more damage is done.
Key takeaways
- Stealing the ticket allows access even if the original password is changed immediately.
- The attack relies on the trust relationship between the client and the Key Distribution Center.
- Detection depends on spotting unusual service principal name usage, not failed login attempts.
Pass-the-ticket attacks bypass password checks by stealing valid authentication tokens from memory. Implement endpoint protection to prevent memory dumping and monitor for anomalous ticket usage to detect lateral movement.
Frequently asked questions
Can changing the password stop a pass-the-ticket attack?
No, the stolen ticket remains valid until it expires or is revoked. You must reset the Kerberos keys or revoke the ticket to stop access.
How do you detect a pass-the-ticket attack?
Monitor for successful logins from unusual locations or times. Look for service accounts accessing resources they never touch. Correlate ticket requests with user behavior.
What is the difference between pass-the-hash and pass-the-ticket?
Pass-the-hash uses NTLM hashes for local authentication. Pass-the-ticket uses Kerberos tickets for network authentication. Kerberos is more common in modern environments.
Does multi-factor authentication prevent this?
MFA helps at initial access. Once the attacker has a valid ticket, MFA is bypassed. You need strong endpoint security to prevent the initial compromise and ticket theft.
How this guide was produced: written by the Sandbox Dispatch editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.



