Pass-the-Ticket — Stolen Kerberos Ticket Lateral Movement

MITRE ATT&CK

Security Relevance

Pass-the-Ticket is particularly dangerous because it operates entirely within legitimate Kerberos protocol flows — the authentication traffic is indistinguishable from normal at the packet level. It does not require NTLM (eliminating the pass-the-hash detection signal), does not create new accounts, and does not modify Active Directory objects. A stolen Domain Admin TGT from a shared system like an RDS host gives an attacker 10 hours of full domain access with no failed logon events. Privileged accounts logged into shared or multi-user systems are the highest-risk targets — their tickets sit in LSASS waiting to be stolen.

Indicators of Malicious Use

• ⚑Event 4688 or 4104: sekurlsa::tickets, kerberos::ptt, Rubeus dump, Rubeus ptt — the explicit tooling signatures
• ⚑Event 4769 (service ticket request) from a source IP that does not match the account's most recent 4768 (TGT request) source — ticket was injected from a different host
• ⚑Event 4624 Type 3 (network logon) for a privileged account from an unexpected workstation IP with Kerberos authentication — injected ticket being used for lateral movement
• ⚑Event 4672 (special privileges) on a destination system for an account whose known workstation is different from the logon source — elevated ticket in use from a different host
• ⚑Multiple successful 4769 requests for high-value SPNs (cifs/DC01, host/DC01, ldap/DC01) in quick succession from a single account — attacker mapping what the stolen ticket can access
• ⚑No 4768 on the DC preceding a 4769 for the same account within the expected ticket lifetime — bypassed TGT issuance indicates an injected or forged ticket

Example Log Entry

-- On attacker's host (source of ticket injection) --

Event ID: 4688 — A new process has been created
  Process Name:     C:\Tools\Rubeus.exe
  Command Line:     Rubeus.exe dump /nowrap
                    ← dumps all Kerberos tickets from LSASS to console

[Ticket exported as Base64 — attacker copies the TGT for DomainAdmin@CORP.LOCAL]

  Process Name:     C:\Tools\Rubeus.exe
  Command Line:     Rubeus.exe ptt /ticket:<base64blob>
                    ← injects stolen DomainAdmin TGT into current session

-- On domain controller (destination) --

Event ID: 4769 — Kerberos service ticket requested
  Account Name:     DomainAdmin@CORP.LOCAL
  Service Name:     cifs/DC01.corp.local
  Client Address:   ::ffff:10.10.5.99   ← attacker's IP, not DomainAdmin's workstation
  Ticket Encryption Type: 0x12 (AES256)
  Failure Code:     0x0 (success)

[No preceding Event 4768 from 10.10.5.99 for DomainAdmin — ticket was injected]

Investigation Steps

1. 1.Check Event 4688 on the suspected source host for Mimikatz (sekurlsa::tickets, kerberos::ptt) or Rubeus (dump, ptt, asktgt) — these are the explicit tooling signatures for PtT.
2. 2.Compare the Client Address in Event 4769 against the account's known workstation and the source of their most recent Event 4768 (TGT request). A mismatch means the ticket is being used from a different host than where it was issued.
3. 3.Check for a preceding Event 4768 on the DC from the same Client Address — if no 4768 exists for the account from that IP within the past 10 hours, the ticket was obtained elsewhere and injected.
4. 4.Review Event 4624 Type 3 logons on target systems for the account — identify every system it authenticated to during the suspected window and whether the source IP matches the account's known hosts.
5. 5.Check Event 4672 on destination systems — if special privileges were assigned for the account from an unexpected source IP, the attacker used the stolen ticket for elevated operations.
6. 6.Search for .kirbi files on disk — Mimikatz kerberos::list /export writes ticket files. Common locations: current directory of the mimikatz process, %TEMP%, user profile.
7. 7.Assess scope by identifying the stolen account: if a Domain Admin ticket was taken from an RDS or jump server, all systems the account has rights on must be considered compromised for the ticket's remaining validity period.

Common False Positives

• ◎Legitimate Kerberos ticket renewal and reuse — Windows caches and reuses TGTs across sessions for the ticket's lifetime. A single account authenticating from slightly different IPs (DHCP lease change, VPN reconnect) may look like PtT but is usually benign.
• ◎Load-balanced environments — application servers behind a load balancer may generate 4769 requests from IPs that differ from the account's primary workstation. Correlate with known infrastructure IPs.
• ◎Authorized security testing — red team exercises use Rubeus and Mimikatz PtT as standard techniques. Confirm no engagement is in progress before escalating.
• ◎Service accounts — some service accounts operate across multiple hosts and generate Kerberos tickets from various source IPs as part of normal operation. Baseline before alerting on IP mismatch.

Remediation

• ✓Enable Credential Guard on all systems that host privileged users — Credential Guard stores Kerberos tickets in a virtualization-based security container that Mimikatz and Rubeus cannot read from LSASS.
• ✓Add all Tier 0 and Tier 1 accounts to the Protected Users security group — members have shorter ticket lifetimes (4 hours for TGT instead of 10), cannot use credential delegation, and require AES encryption, limiting the PtT window.
• ✓Enforce tiered administration — Domain Admin accounts must not log into workstations or shared RDS servers. A DA ticket in LSASS on a multi-user system is an easy PtT target. Use PAWs (Privileged Access Workstations) for all Tier 0 administration.
• ✓Reduce ticket lifetime via Group Policy (Computer Configuration → Windows Settings → Security Settings → Account Policies → Kerberos Policy → Maximum lifetime for user ticket). Shorter lifetimes reduce the exploitation window.
• ✓Alert on Rubeus.exe and Mimikatz process names via endpoint detection — both tools have well-known binary signatures and command-line patterns. Hash-based detection alone is insufficient given recompilation, but command-line arguments like 'ptt', 'dump', and 'sekurlsa' are reliable.
• ✓If a ticket theft is confirmed: the stolen ticket cannot be invalidated until it expires. Reset the victim account password AND wait for the ticket TTL to expire — resetting the password alone does not invalidate outstanding Kerberos tickets. For immediate invalidation, reset the krbtgt password (only needed if a TGT was stolen and used to forge further tickets).

Related Event IDs

Related Detection Guides

Frequently Asked Questions

What is the difference between Pass-the-Ticket and Pass-the-Hash?

Pass-the-Hash (PtH) uses a stolen NTLM hash to authenticate via the NTLM protocol — it does not use Kerberos at all. Pass-the-Ticket (PtT) steals a valid Kerberos ticket from LSASS and injects it into a session, authenticating via Kerberos. PtT leaves no NTLM traces (no Event 4776, no NTLM logon type in 4624) and blends in with legitimate Kerberos traffic. In environments where NTLM is blocked or monitored, PtT is the attacker's preferred alternative.

Can I invalidate a stolen Kerberos ticket before it expires?

Not directly — Windows has no mechanism to revoke an individual outstanding Kerberos ticket. Once issued, a TGT is valid until its expiry (10 hours by default) regardless of password changes. Resetting the victim's password prevents new tickets from being issued but does not invalidate the stolen one. To immediately invalidate all outstanding tickets: reset the krbtgt account password twice (invalidates all TGTs domain-wide, causing disruption). For a targeted response, your only option is to wait out the ticket lifetime while containing the attacker's access.

What is the difference between Pass-the-Ticket and a Golden Ticket?

Pass-the-Ticket reuses a legitimately-issued ticket stolen from LSASS — it works until that ticket expires (10 hours for a TGT). A Golden Ticket is entirely forged using the krbtgt NTLM hash, can be created for any account with any expiry, and survives password resets of the target account. PtT requires access to a system where the victim is logged in; Golden Ticket requires the krbtgt hash (from DCSync or NTDS.dit dumping) but is then independent of any real session.

Which systems are highest-risk for ticket theft?

Shared multi-user systems — RDS (Remote Desktop Session Host) farms, Citrix servers, jump servers, and VDI hosts. These concentrate the Kerberos tickets of every user logged in simultaneously. If a Domain Admin is logged into an RDS server that a lower-privileged user can also access, the DA's ticket sits in that system's LSASS waiting to be exported. The fix is tiered administration: privileged accounts must only log into dedicated PAWs (Privileged Access Workstations), never shared systems.