Pass-the-Ticket (PtT) Attack: Definition, How It Works, and Detection

Pass-the-Ticket (also written pass the ticket or Pass-the-Ticket attack) is a Kerberos technique where an attacker reuses stolen Kerberos tickets (TGT/TGS) to authenticate to Active Directory resources without knowing the password. Because the ticket is already a valid proof of identity, PtT often enables fast lateral movement after a single endpoint compromise.

How a Pass-the-Ticket attack works

Kerberos relies on time-bound tickets to prove identity. PtT abuses the fact that if an attacker can obtain ticket material from memory or the local ticket cache, they can often use it to access services until the ticket expires (or until defensive actions invalidate it).

1) Kerberos basics (the parts PtT abuses)

• TGT (Ticket Granting Ticket): Proves you authenticated to the Key Distribution Center (KDC) and lets you request service tickets.
• TGS / Service ticket: Issued for a specific service principal name (SPN), e.g., cifs/fileserver01 or http/app01.
• KDC: Typically a domain controller in Active Directory.

Normal flow: 1. Client authenticates and gets a TGT (AS-REQ/AS-REP). 2. Client presents TGT to request a service ticket (TGS-REQ/TGS-REP). 3. Client presents service ticket to the target service to access it.

2) Ticket theft: where the attacker gets the ticket

Attackers usually steal tickets after gaining code execution on a Windows endpoint where a user (often privileged) has logged on. Common prerequisites include: - Local admin/SYSTEM privileges (to read LSASS memory or access protected ticket stores) - Debug privileges or credential dumping capability - A user session that already has usable Kerberos tickets

Tickets may be obtained from: - LSASS memory (common in real incidents) - The Kerberos ticket cache (per logon session) - Saved ticket files exported by attacker tooling

3) Ticket injection (“pass” step)

Once ticket material is stolen, the attacker loads it into their current logon session (or creates a new one) so that Windows will present it automatically when accessing network resources.

Two common attacker paths: - Reuse a TGT: Lets the attacker request new service tickets as that user (broader access during validity). - Reuse a service ticket (TGS): Grants access only to the specific service for which that ticket is valid (narrower but still dangerous).

4) Lateral movement and the persistence window

With a valid ticket injected, the attacker can: - Access file shares (\\server\c$ or business shares) via cifs - Query LDAP/AD if they can obtain appropriate tickets for it - Reach web apps integrated with Kerberos (http SPN) - Move laterally to additional servers where the compromised identity has rights

PtT is often fast: once the ticket is present, tools and OS components will authenticate seamlessly until: - The ticket expires (often hours) - The user logs off and tickets are purged (not guaranteed) - The account password is changed and relevant Kerberos keys are rotated/invalidated (details depend on ticket type) - Defender actions invalidate sessions/tickets (e.g., purging tickets, rebooting endpoints, containing hosts)

What defenders should know about Kerberos tickets

• TGT lifetime and renewal policies influence how long an attacker can operate.
• A stolen TGS is typically limited to a single SPN; a stolen TGT is more flexible.
• PtT is different from forging tickets (e.g., Golden/Silver Ticket). PtT uses real issued tickets.

If you need a deeper refresher on how Kerberos integrity and proof-of-authentication concepts relate to “showing you have the right secret,” see our primer on digital verification concepts: what is a digital signature.

Practical investigation commands (defensive)

On a suspected Windows endpoint, list cached Kerberos tickets:

klist

You may see entries like: - krbtgt/DOMAIN.COM (TGT) - cifs/server01.domain.com - ldap/dc01.domain.com - http/app01.domain.com

On Windows, you can purge Kerberos tickets for the current logon session (use with care during IR; it may disrupt user access):

klist purge

Detection: Windows Security logs to review

Domain controller logs

• Event ID 4768 (TGT was requested)
• Event ID 4769 (A Kerberos service ticket was requested)
• Event ID 4771 (Kerberos pre-auth failed; useful for password guessing, less direct for PtT)

What to look for in 4769: - Unusual service names (SPNs) being requested by a workstation/user that doesn’t normally access them - Sudden bursts of cifs/, ldap/, host/, http/ requests - Requests from unexpected client addresses for a given user - Access patterns that don’t match the user’s role (e.g., finance workstation requesting cifs to many servers)

Member server logs

• Event ID 4624 (successful logon) with Logon Type 3 (network) may correlate with Kerberos-based access.
• Correlate timestamps between 4769 (DC) and 4624 (target server).

When you’ll encounter Pass-the-Ticket

Incident response in Active Directory environments

PtT is common after an initial compromise of: - A workstation used by IT admins (helpdesk, server admins) - A jump host - An RMM-managed endpoint with elevated sessions - A server where multiple admins log on interactively (bad but common)

If you see evidence of LSASS access (credential dumping) plus unexplained Kerberos service ticket activity, PtT should be high on your hypothesis list.

Red team and penetration tests

PtT is a frequent technique in legitimate assessments because: - It demonstrates impact without cracking passwords - It highlights the risk of privileged sessions on endpoints - It showcases why endpoint hardening and credential hygiene matter

Hybrid identity and “Kerberos still matters”

Even in organizations using cloud identity heavily, on-prem AD often remains the backbone for: - Legacy file servers - Print services - Older line-of-business apps - Domain-joined systems relying on Kerberos SSO

PtT shows up wherever Kerberos is used and endpoints can be compromised.

Common conditions that make PtT more likely

• Privileged users logging onto low-trust endpoints
• Weak endpoint hardening (no LSASS protections, poor EDR coverage)
• Long ticket lifetimes and permissive renewal policies
• Broad administrative rights (e.g., domain admins using the same account for daily tasks)

Containment and response (high-level playbook)

If you suspect a pass-the-ticket attack:

1. Isolate the suspected source host(s) (the machine where tickets were stolen/injected).
2. Identify impacted identities and scope of access used (DC 4769/4768 + server 4624 correlations).
3. Reset credentials appropriately (user passwords; for privileged accounts, follow your tiering model).
4. Consider Kerberos ticket invalidation actions (session termination, forced logoff, purging tickets, reboots) in a controlled manner.
5. Hunt for additional credential access and persistence (scheduled tasks, services, remote management tools).

Practical hardening often pairs identity controls with endpoint controls. For example, tightening privileged session hygiene and rolling out strong password management reduces credential exposure blast radius—teams commonly standardize on an enterprise password manager like 1Password (Try 1Password →) to enforce unique secrets and improve operational hygiene.

Prevention: reduce the odds of ticket theft

• Enable and validate LSASS protections (e.g., Credential Guard where feasible)
• Reduce privileged interactive logons to workstations; use admin tiering / PAWs
• Use least privilege; remove broad local admin rights
• Shorten ticket lifetimes where it fits risk tolerance and operational requirements
• Ensure EDR coverage on endpoints where admins log on; alert on credential access behaviors
• Review privileged group membership routinely; remove standing privileges

For identity-side controls, requiring phishing-resistant MFA reduces the chance of initial footholds that lead to endpoint compromise in the first place. See: what is multi factor authentication.

Quick “is this PtT?” checklist

• Was there endpoint compromise with potential LSASS/ticket access?
• Do DC logs show unusual 4769 service ticket requests for that user/host?
• Do target servers show 4624 network logons correlating to those ticket requests?
• Is access occurring without corresponding interactive logons or normal user behavior?
• Does scoping indicate ticket reuse rather than password guessing?

If most answers are “yes,” treat it as PtT until disproven.

---

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.