Pass-the-ticket attack: How the attack works and how to stop it

A compromised workstation exposes every cached Kerberos ticket to lateral movement attacks. Attackers extract valid tickets from memory and inject them elsewhere, gaining authenticated access across the network without password knowledge or triggering standard authentication monitoring. Organizations lose visibility into breach expansion because stolen tickets appear as legitimate authentication sessions to targeted services.

Pass-the-ticket attacks enable lateral movement through stolen Kerberos tickets without requiring password knowledge. This differs from pass-the-hash attacks, which rely on NTLM authentication mechanisms rather than Kerberos tickets.

Attack surfaces and threat vectors

Workstation memory compromise
Workstations store Kerberos tickets in the Local Security Authority Subsystem Service (LSASS) memory after user authentication. Attackers with administrative privileges on compromised systems can extract these tickets using tools like Mimikatz or Rubeus. The business consequence: every authenticated user session becomes a potential pivot point for network traversal. The extracted tickets remain valid until expiration, typically 10-12 hours for Ticket Granting Tickets (TGT) and 10 hours for service tickets.

Service account exposure
Service accounts present another vector when they run with cached Kerberos tickets on multiple systems. Attackers who compromise one system running the service can extract tickets and use them to access other systems where the same service operates. A stolen service account ticket can grant simultaneous access to backup systems, database servers, and application infrastructure.

Domain controller targeting
Domain controllers become high-value targets because they process all Kerberos authentication requests and may cache tickets for multiple users. Compromise of a domain controller exposes tickets for any recently authenticated user, creating organization-wide lateral movement opportunities.

The attack sequence follows a predictable pattern: initial compromise through phishing or exploitation, privilege escalation to access LSASS memory, ticket extraction using specialized tools, and lateral movement by injecting stolen tickets on target systems.

Business impact

Pass-the-ticket attacks create cascading access across network segments without triggering standard authentication monitoring. The attack bypasses multi-factor authentication controls because Kerberos tickets represent completed authentication sessions.

Financial services face regulatory exposure when attackers use stolen tickets to access customer data systems. This gap can trigger compliance violations under PCI DSS or SOX requirements where MFA is mandated for sensitive system access. (Source: learn.microsoft.com)

Operational disruption occurs when attackers target service accounts with broad system access. Recovery requires coordinated password resets across multiple systems and services, often during business hours to maintain operational continuity. (Source: learn.microsoft.com)

Customer trust erodes when pass-the-ticket enables data exfiltration from customer-facing applications. (Source: attack.mitre.org) The attack's stealth characteristics mean breaches can persist for weeks before detection, expanding the scope of compromised data.

Detection guidance

Pass-the-ticket detection requires monitoring Kerberos authentication patterns and ticket lifecycle anomalies. Focus on four key indicators: ticket injection, authentication source mismatches, volumetric anomalies, and temporal inconsistencies.

Logic pattern/pseudocode — validate for your platform

// Detect ticket injection - TGS requests without corresponding TGT
source_type="WinEventLog:Security" 
EventCode=4769 AND NOT EventCode=4768 
| where SourceAddress != DomainControllerIP 
| stats count by Account_Name, Client_Address
| where count > threshold

Logic pattern/pseudocode — validate for your platform

// Detect cross-IP ticket usage
source_type="WinEventLog:Security" 
EventCode=4769 
| eval ticket_source=if(match(Client_Address, "^10."), "internal", "external")
| stats dc(Client_Address) as unique_ips by Account_Name 
| where unique_ips > 2 AND timespan < 1h

Domain controller security logs provide the primary telemetry source through Event IDs 4768 (TGT requests) and 4769 (service ticket requests). Monitor for service ticket requests that lack corresponding TGT requests from the same source IP address within a reasonable timeframe.

Anomalous authentication patterns include high-volume TGS requests from workstations, which typically generate minimal Kerberos traffic. Service accounts authenticating from unusual IP addresses or network segments also indicate potential ticket theft.

Logic pattern/pseudocode — validate for your platform

// High volume TGS requests from workstations
source_type="WinEventLog:Security" 
EventCode=4769 
| where Client_Address matches workstation_ranges 
| stats count by Client_Address, Account_Name 
| where count > 50 AND timespan = 1h

Temporal inconsistencies emerge when tickets are used outside normal business hours for accounts that typically authenticate during standard schedules. Service accounts present a different pattern — they should show consistent usage patterns where deviation indicates compromise.

Mitigation strategies

Credential caching restrictions
Implement credential caching restrictions through Group Policy to limit ticket lifetime and scope. Configure the "Maximum lifetime for user ticket" setting to 4 hours instead of the default 10 hours. This reduces the window for stolen ticket abuse while maintaining operational functionality for most environments. (Source: attack.mitre.org)

Disable credential caching on high-value systems through the "Do not store passwords and credentials for network authentication" Group Policy setting. Apply this control to jump servers, privileged access workstations, and systems processing sensitive data. (Source: attack.mitre.org) Increased authentication prompts versus reduced credential exposure represents the core decision.

Service account hardening
Configure service accounts with "Account is sensitive and cannot be delegated" to prevent their tickets from being used for delegation attacks. This setting limits the scope of compromise when service account tickets are stolen.

Deploy Microsoft's Local Administrator Password Solution (LAPS) to rotate local administrator passwords, reducing the impact of credential theft. Stolen tickets for local accounts become less valuable when passwords change frequently.

Network controls
Implement network segmentation to limit lateral movement paths even when tickets are compromised. Micro-segmentation around critical systems forces attackers to compromise additional credentials rather than relying solely on stolen tickets. (Source: attack.mitre.org)

Monitor and alert on Mimikatz execution signatures in endpoint detection systems. Deploy application allowlisting to prevent unauthorized credential dumping tools from executing. The operational cost is increased false positives versus prevention of credential theft.

Emergency response
Reset the krbtgt account password twice to invalidate all existing Kerberos tickets when pass-the-ticket activity is confirmed. This nuclear option disrupts active attacks but requires careful coordination to avoid legitimate user impact.

Getting started checklist

Immediate actions (24-48 hours):
- [ ] Enable security logging on all domain controllers for Event IDs 4768 and 4769
- [ ] Deploy detection rules for TGS requests without corresponding TGT requests
- [ ] Inventory service accounts and their current delegation settings
- [ ] Identify systems with cached credentials enabled via Group Policy Results

Short-term implementation (1-2 weeks):
- [ ] Configure credential caching restrictions on high-value systems
- [ ] Set service accounts to "sensitive and cannot be delegated"
- [ ] Deploy endpoint detection rules for credential dumping tools
- [ ] Create baseline authentication patterns for anomaly detection
- [ ] Test krbtgt password reset procedures in a lab environment

Ongoing operations:
- [ ] Monitor authentication patterns weekly for volume and source anomalies
- [ ] Review service account ticket usage monthly for unauthorized access
- [ ] Validate Group Policy application quarterly to ensure controls remain effective
- [ ] Test incident response procedures for pass-the-ticket scenarios semi-annually

Incident response preparation:
- [ ] Document rapid ticket invalidation procedures (klist purge commands)
- [ ] Prepare communication templates for coordinated password resets
- [ ] Create decision trees for krbtgt password reset scenarios
- [ ] Establish change control exceptions for emergency credential modifications

Sources