Stop Pass-the-Ticket Attacks: Practical Prevention and Detection
Kerberos tickets are often stored in memory rather than on disk, meaning traditional endpoint scanning frequently misses the primary attack vector for lateral movement.
Restrict ticket delegation, enforce short ticket lifetimes, and monitor for unusual service principal name usage. Standard antivirus tools cannot detect these attacks because they do not involve executable files, requiring behavioural detection instead of signature-based scanning.
The Memory Residency Problem
Pass-the-ticket attacks rely on stealing Kerberos tickets rather than passwords. Kerberos is the standard authentication protocol used in most corporate networks to verify identity without sending passwords over the wire. When a user logs in, the system issues a ticket-granting ticket (TGT) and service tickets. These digital vouchers prove identity to servers.
The critical insight for defenders is where these tickets live. They are stored in the process memory of the operating system, specifically within the Local Security Authority Subsystem Service (LSASS) process. They are not saved as files on the hard drive. This distinction determines your entire defence strategy. Most security tools look for malicious files or suspicious registry changes. They do not inspect running memory by default.
Imagine an attacker who has gained access to a single workstation. They do not need to crack passwords. They simply read the memory of the LSASS process to extract valid tickets. These tickets allow them to access other servers as if they were the original user. Because the tickets are valid credentials, the server accepts them without question. The attack leaves no trace of password guessing or brute force attempts.
Why Standard Defences Fail
Many organisations believe that patching operating systems and updating antivirus definitions are sufficient. This belief is dangerously incorrect for this specific threat. Pass-the-ticket attacks exploit legitimate authentication protocols. The tickets themselves are valid cryptographic objects. There is no malware to scan for. There is no exploit to patch in the authentication logic itself.
Antivirus solutions rely on known signatures of malicious code. Since the attacker uses built-in system tools to extract memory, there is no third-party executable to detect. Even next-generation antivirus that analyses behaviour often misses this because reading memory is a legitimate administrative task. Without specific behavioural monitoring, the theft goes unnoticed.
This is where the concept of token theft becomes relevant. While token theft involves stealing Windows security tokens, the principle is similar: the attacker abuses legitimate identity structures. Both methods bypass password complexity requirements entirely. You cannot defend against this by forcing users to change passwords more often. The password is never used in the second phase of the attack.
Priority One: Shorten Ticket Lifetimes
The most effective immediate control is reducing the validity period of Kerberos tickets. By default, these tickets may remain valid for hours or even days. This gives an attacker a wide window to move laterally across the network. If you reduce the lifetime to minutes, the stolen ticket expires quickly. The attacker must then find a way to obtain a new ticket, which increases the chance of detection.
Configuring shorter lifetimes requires changes to the domain controller group policies. You must balance security with usability. If tickets expire too quickly, users may be prompted to re-authenticate constantly, leading to support tickets and potential workarounds. A lifetime of thirty minutes is often a reasonable compromise for high-security environments. This limits the operational window for any stolen credential.
This measure does not prevent the theft of the ticket. It only reduces the value of the stolen item. Think of it as a short-lived key card. If a thief steals it, it stops working soon after. You still need to detect the theft and respond to it. Short lifetimes are a containment strategy, not a prevention strategy. They buy you time to identify and isolate the compromised host.
Priority Two: Restrict Delegation Rights
Kerberos delegation allows a service to act on behalf of a user. This is necessary for single sign-on experiences where a web application accesses a database on the user's behalf. However, unconstrained delegation is a significant risk. It allows any service with this right to impersonate any user who has authenticated to it.
Attackers target servers configured with unconstrained delegation. Once they compromise such a server, they can harvest TGTs for all users who have interacted with it. They can then use these tickets to access any other resource in the domain. This turns a single compromised server into a gateway for the entire network.
You must audit your environment for services with unconstrained delegation. Most modern applications do not need this privilege. Replace it with constrained delegation, which restricts which services can be impersonated and for which protocols. This limits the blast radius of a compromise. Even if an attacker steals a ticket from a delegated service, they cannot pivot to unrelated systems.
This requires careful planning. You must map out which applications require delegation and configure them precisely. Incorrect configuration can break legitimate workflows. Test changes in a non-production environment first. The effort is high, but the risk reduction is substantial. This is a structural change that removes the attack path entirely for many scenarios.
Priority Three: Detect Abnormal Access Patterns
Since prevention is difficult, detection is vital. You must monitor for anomalies in authentication logs. Look for users accessing services they never normally use. A helpdesk technician accessing the finance server is a red flag. A service account logging in from a workstation is another.
Network detection and response solutions can help identify these patterns. They analyse traffic flows and correlate them with identity information. If a ticket is used to access a server from an unexpected location or at an unusual time, the system can alert. This requires baseline knowledge of normal user behaviour.
You should also monitor for the use of specific commands that extract tickets. Tools like Mimikatz are well-known, but attackers often write custom scripts to avoid detection. These scripts may not match known signatures, but they will trigger alerts if you monitor for abnormal process behaviour. For example, a command prompt reading memory from LSASS is suspicious.
This ties into alert triage. You will receive many alerts. You must prioritise those that indicate lateral movement. A single failed login is noise. A user accessing three different servers in five minutes is signal. Focus your investigation on accounts that move horizontally across the network.
See also: Tactics, Techniques and Procedures (TTPs) for Security Decisions · Attacker Reconnaissance Myths: What Your Defenders Actually See
What Does Not Work
Another common misconception is that disabling local admin rights prevents ticket theft. While it limits the attacker's ability to install tools, many ticket extraction techniques work with standard user permissions if they can access the memory of other processes. Some advanced techniques require admin rights, but basic extraction does not.
Encryption at rest is also irrelevant. The tickets are in memory, not on disk. Encrypting the drive protects data when the computer is off. It does nothing to protect data in active use. You must focus on memory protection and runtime integrity, not storage security.
Quick Wins and Ongoing Hygiene
You can implement several measures quickly. First, review your Kerberos ticket lifetime policies. Reduce them if they are set to defaults. Second, audit your delegation settings. Disable unconstrained delegation wherever possible. Third, ensure your logging captures detailed authentication events. You cannot detect what you do not log.
For deeper analysis, consider how PowerShell abuse might facilitate these attacks. Attackers often use PowerShell scripts to extract and manipulate tickets. Restricting the execution of unsigned scripts can hinder their ability to automate this process. While not a complete solution, it adds friction.
Finally, remember that these attacks are part of a broader campaign. They are often used in nation-state cyber attacks to maintain persistence. Defending against them requires a holistic approach. You must combine identity management, network monitoring, and endpoint protection. No single tool will solve this problem.
| Measure | Effort | What it stops |
|---|---|---|
| Shorten ticket lifetimes | Low | Limits the window of opportunity for lateral movement |
| Restrict delegation | High | Prevents impersonation across unrelated services |
| Monitor for anomalous access | Medium | Detects the use of stolen tickets after theft |
| Audit delegation settings | Medium | Identifies misconfigurations that enable pivoting |
Checklist for Today
- Review current Kerberos ticket lifetime policies and reduce them if necessary.
- Identify all services configured with unconstrained delegation.
- Ensure authentication logs are being collected and analysed for anomalies.
Key takeaways
- Kerberos tickets reside in volatile memory, rendering file-based security controls ineffective against theft.
- Shortening ticket validity windows limits the time an attacker can operate before re-authentication is required.
- Restricting constrained delegation prevents attackers from impersonating privileged accounts across unrelated services.
Kerberos tickets are memory-based credentials that bypass traditional file-based security controls. You must shorten ticket lifetimes and monitor for abnormal access patterns to mitigate the risk.
Frequently asked questions
Can antivirus software detect pass-the-ticket attacks?
Generally no, because these attacks use legitimate system processes to read memory rather than executing malicious files. Signature-based detection is ineffective against this method.
Does multi-factor authentication prevent this attack?
No, MFA only secures the initial login. Once a valid ticket is issued, it proves identity without requiring re-authentication, allowing attackers to bypass MFA protections.
How do I know if my tickets have been stolen?
Monitor for unusual access patterns, such as users accessing services they do not normally use or logging in from unexpected locations. Anomalies in authentication logs are key indicators.
What is the difference between pass-the-hash and pass-the-ticket?
Pass-the-hash uses a password hash to authenticate, while pass-the-ticket uses a valid Kerberos ticket. Both bypass password checks, but tickets are more flexible and harder to detect.
How this guide was produced: written by the Phish Herald 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.
