Pass the Ticket: Reusing Kerberos Tickets for Access

Pass-the-ticket is the Kerberos cousin of pass-the-hash, and it carries the same uncomfortable lesson: the thing an attacker needs to become you is often not your password, but an artifact your own session has already created. In Kerberos that artifact is a ticket, and once an attacker holds a valid one, they can present it to services and be accepted as the user it was issued to. No password, no hash, no cracking.

The property that makes this sting for defenders is that a ticket is a bearer token with a life of its own. It was issued by the domain controller, it is valid for a set period, and changing the user's password does nothing to it while it lives. Rotating the credential, the reflex response to a compromise, leaves a stolen ticket working until it expires on its own schedule.

The tickets that matter

Kerberos uses two kinds of ticket, and the difference shapes the attack. Microsoft's Kerberos overview covers the full flow, but the short version is enough here.

A ticket-granting ticket, the TGT, is issued when a user first authenticates to the domain. It is proof of identity that the user presents to the domain controller to request access to individual services. Because it can be exchanged for service tickets, a stolen TGT is a general-purpose key: the attacker can use it to request tickets for many services across the domain.

A service ticket, the TGS, grants access to one specific service. A stolen service ticket is narrower. It unlocks the service it was issued for and nothing more.

Both can be stolen and reused, which is MITRE ATT&CK T1550.003. The TGT is the higher-value theft because of its reach:

Ticket	Purpose	Reuse value if stolen
Ticket-granting ticket (TGT)	Proves identity, requests service tickets	High, works across many services
Service ticket (TGS)	Grants access to one named service	Low, limited to that one service

This is why an attacker who finds a TGT in memory treats it as the bigger prize, and why the controls below focus on keeping high-value TGTs out of reach.

How a ticket gets stolen and reused

Like pass-the-hash, pass-the-ticket begins with the attacker already controlling a machine. Valid tickets for the users logged on to that machine sit in memory, held by the local security subsystem so the user does not have to reauthenticate for every action. An attacker with sufficient privilege on the machine extracts those tickets from memory.

The reuse step imports the stolen ticket into the attacker's own logon session. Once injected, the ticket is presented to services exactly as the legitimate session would present it. The service validates the ticket, which is genuine and unexpired, and grants access. From the service's perspective the user simply showed up with a valid ticket, because they did.

A password change will not save you

When you discover a compromised account, resetting the password feels like the fix. For a stolen ticket, it is not enough on its own. The already-issued ticket remains valid until it expires, so the attacker keeps their access through the reset. Containing a ticket theft means forcing ticket invalidation, which for a ticket-granting ticket can require resetting the relevant krbtgt material, and it means disabling the account and hunting for where the ticket is being used.

Stolen tickets versus forged tickets

It helps to place pass-the-ticket next to its more dramatic cousins so the defense stays clear. Pass-the-ticket reuses a real ticket that the domain controller genuinely issued to a real user. The ticket is authentic, only the holder is wrong. Forged-ticket attacks are different in kind: they involve minting a ticket from stolen key material so the attacker can create tickets the domain controller never issued, for any user and any lifetime they choose.

The distinction matters for containment. A stolen ticket expires on its normal schedule and is bounded by the privileges of the account it belongs to, so lifetime policy and account disablement are meaningful levers. A forged ticket is bounded only by the compromised key, which is why forged-ticket incidents demand rotating that key material rather than waiting for expiry. For everyday lateral movement, pass-the-ticket is the far more common technique, and the origin-mismatch detection below is what surfaces it. The forged-ticket case is covered separately in the golden ticket guide linked at the end.

Why this evades the usual defenses

Pass-the-ticket sidesteps three defenses that teams often lean on.

Password policy is irrelevant because no password is involved in reuse. The ticket already exists.

Account lockout never triggers because there is no guessing. The ticket is presented once and accepted.

Password rotation does not revoke a live ticket, as above. The credential lifecycle and the ticket lifecycle are separate, and the ticket outlives the reset.

What remains as leverage is the ticket's own lifetime, the memory it is stolen from, and the fact that a reused ticket usually surfaces somewhere it should not.

The lifetime lever

Every ticket has a lifetime, and after it expires it is worthless. A ticket-granting ticket also has a maximum renewal period, after which it cannot be renewed and a fresh authentication is required. These durations are policy settings.

Long lifetimes are convenient because users reauthenticate less often, but they hand an attacker a long window in which a stolen ticket keeps working. Shorter lifetimes shrink that window. The trade is between user friction and the value of a stolen ticket, and for higher-risk populations the shorter setting is usually worth it. This lever does not stop the theft, it limits how long the theft pays off.

Delegation makes ticket theft worse

One configuration deserves special attention because it concentrates valuable tickets in one place. Unconstrained delegation lets a server receive and store the ticket-granting tickets of users who connect to it, so the server can act on their behalf. That is convenient for some application designs, and dangerous for security, because any server configured this way becomes a reservoir of TGTs. An attacker who compromises such a server can harvest the ticket-granting tickets of every privileged user who has connected to it, including potentially high-value accounts.

The defensive move is to eliminate unconstrained delegation wherever it is not strictly required and replace it with constrained delegation, which limits what the server can request on a user's behalf. Marking sensitive and privileged accounts as not delegable removes them from this exposure entirely, so that even if they touch a delegating server, their tickets are not left there to steal. Auditing which accounts and servers carry delegation settings is a high-value part of any pass-the-ticket review.

How to detect and defend against pass-the-ticket

Because the reused ticket is genuine, defense combines reducing the tickets available to steal, shrinking their useful life, and detecting the ticket that turns up in the wrong place.

Reduce what can be stolen.

Enable Credential Guard on supported systems so tickets and related secrets are held in isolated memory that ordinary extraction cannot reach.
Keep privileged accounts off low-trust machines. A privileged user's ticket in a workstation's memory is a privileged ticket waiting to be lifted, so restrict where those accounts log on.

Shrink the window.

Tighten ticket lifetime and renewal policy so a stolen ticket expires sooner, sizing the settings to the risk of each population.
Have a real revocation plan. Know in advance how you will invalidate tickets during an incident, including the steps for ticket-granting-ticket material, because a password reset alone will not contain it.

Detect the misuse.

Correlate a ticket to the host and address it was issued to. A ticket presented from a different machine or a different source address than the one it was issued on is the core pass-the-ticket signal.
Watch for service access with no preceding ticket request. In a normal flow a service ticket is requested from the domain controller just before use. Access that appears without that request suggests an imported ticket.
Alert on privileged accounts appearing on hosts they never touch, which combined with the ticket-origin mismatch strongly indicates reuse during lateral movement.
Baseline normal ticket behaviour per account so a ticket surfacing far from its origin, or a burst of service access after a single logon, stands out against the noise.

Origin mismatch is your best signal

The single most reliable detection for pass-the-ticket is the mismatch between where a ticket was issued and where it is being used. A legitimate ticket stays on the machine and account it belongs to. When the same ticket shows up on a second host, treat it as reuse until proven otherwise, and pivot to hunting both machines for how it moved.

A walkthrough of a pass-the-ticket operation

Picture the sequence from the attacker's side, because the shape of it tells you where to look. The attacker already has code running on a workstation, and they hold local administrator or an equivalent right that lets them reach protected memory. Their first move is enumeration: list the Kerberos tickets currently cached in the sessions on that host. A busy workstation often holds several, one per logged-on user and per scheduled task or service running under a domain identity.

The attacker reads that list and looks for value. A ticket-granting ticket belonging to a help-desk technician, a backup service account, or a roaming administrator is worth far more than a ticket for an ordinary user, because those identities can reach more of the estate. Having chosen a target ticket, the attacker exports the ticket blob out of memory to a file.

The reuse step is quiet. The attacker opens a fresh logon session that they control and injects the stolen ticket into it, so the session now carries a valid ticket that belongs to someone else. From here the attacker acts as that identity. If the stolen artifact is a ticket-granting ticket, they present it to the domain controller to request service tickets for whatever they want to reach: a file server, a database, a management console. If it is a service ticket, they present it directly to the one service it was cut for.

Nothing in this flow requires a password prompt, a hash crack, or a brute-force loop. The domain controller sees a genuine ticket-granting ticket and issues service tickets against it, because that is exactly what the ticket is for. The target service sees a genuine service ticket and grants access. The only anomaly is geographic: the ticket is being used from a host and an account context that do not match where it was born. That single mismatch is the thread every detection below pulls on.

Detection signals in Windows event data

Because the reused ticket is authentic, detection leans on correlation across the events that Kerberos generates. Treat the following as concrete places to hunt.

Ticket-granting-ticket requests without a matching logon. A normal ticket-granting ticket is requested at interactive or network logon time. When a service ticket request (4769) appears for an account with no preceding ticket-granting-ticket request (4768) or interactive logon on that host, the account is presenting a ticket that was minted elsewhere and imported.

Host and address mismatch. The core signal. A ticket issued to one workstation that is later exercised from a second host, or from a source network address that does not match the account's normal footprint, is the definition of reuse. Baseline where each privileged account normally authenticates from, then alert when a ticket for that account drives service requests from an unfamiliar host.

Logon events with no network authentication chain. A logon (4624) with logon type indicating network access that lands on a sensitive server, unaccompanied by the expected authentication trail, deserves a second look, especially for privileged accounts.

Unusual ticket encryption or option flags. Tickets requested by tooling sometimes carry encryption types or renewal and forwardable option combinations that differ from what the native client stack requests. A population of tickets that all share an oddly uniform set of options against a diverse user base can indicate scripted reuse.

Bursts of service ticket requests after a single logon. A stolen ticket-granting ticket is often used to fan out. One logon followed immediately by service ticket requests for many distinct services, in quick succession, is a lateral-movement fingerprint rather than ordinary user behavior.

None of these signals is conclusive alone. Their strength is combinatorial: a privileged account, on a host it never touches, driving a spray of service ticket requests, with no preceding ticket-granting-ticket request on that host, is pass-the-ticket until proven otherwise.

Pass-the-ticket in the wider Kerberos abuse family

Placing the technique among its neighbors keeps the response proportionate. The table below compares the common credential-reuse and ticket-abuse techniques by what the attacker must possess and how you contain each.

Technique	What the attacker holds	How it is contained
Pass-the-hash	An NTLM password hash	Rotate the credential, restrict NTLM, isolate privileged logons
Pass-the-ticket	A live, genuine Kerberos ticket	Expire or invalidate the ticket, disable the account, hunt the origin mismatch
Overpass-the-hash	A hash used to request a fresh ticket	Rotate the credential and treat resulting tickets as suspect
Golden ticket	The `krbtgt` key, used to forge ticket-granting tickets	Reset `krbtgt` twice, because expiry never comes on its own
Silver ticket	A service account key, used to forge service tickets	Rotate the service account key, monitor service access directly

Pass-the-hash and pass-the-ticket are close relatives that both ride an artifact the session already produced. The distinction is which artifact. Pass-the-hash reuses a hash and can be answered by rotating the password, because a new password produces a new hash. Pass-the-ticket reuses a ticket, and a new password does nothing to a ticket that already exists, so the lever is the ticket lifecycle instead. The forged-ticket techniques sit further along the same spectrum: they stop reusing what exists and start minting new artifacts from stolen key material, which is why their containment always involves rotating a key rather than waiting for anything to expire.

Common misconceptions

"I reset the password, so the account is safe." A password reset invalidates a hash. It does not touch a ticket that the domain controller already issued. The stolen ticket keeps working until it expires or the account is disabled and the relevant material is handled. Rotation is the reflex, and for ticket theft it is the wrong reflex on its own.

"Kerberos is the secure protocol, so this cannot be Kerberos." Kerberos is sound as a protocol. Pass-the-ticket does not break the cryptography. It steals a valid output of the protocol from a machine the attacker already controls and replays it. The weakness is the endpoint holding the ticket, not the ticket math.

"Multi-factor authentication stops it." Multi-factor sits at the moment of initial authentication. Once a user has authenticated and a ticket exists, the ticket is a bearer token that carries no second factor. An attacker who lifts that ticket inherits the already-authenticated session and never faces the prompt.

"Only domain controllers matter." The tickets are stolen from ordinary member hosts, wherever privileged users log on. A workstation that a domain administrator touches becomes a source of a domain-administrator ticket. Where privileged accounts authenticate matters as much as how the domain controllers are hardened.

"Short lifetimes make us immune." Short lifetimes shrink the window, they do not close it. An attacker who is already inside can use a stolen ticket the moment they have it. Lifetime policy limits how long a theft keeps paying, and it pairs with detection rather than replacing it.

How the technique fits the broader trend

Pass-the-ticket belongs to a family of techniques that intruders adopted as endpoint defenses improved. As organizations got better at blocking malware execution and cracking passwords became slower against modern hashing, attackers moved toward living off legitimate authentication material already present in memory. Reusing a real ticket generates far less noise than a fresh authentication attempt, and it blends into normal Kerberos traffic. The rise of memory-protection features such as Credential Guard is the defensive answer to that shift, moving the tickets into isolated storage that ordinary extraction cannot reach. The back-and-forth continues, which is why the durable defense combines reducing what can be stolen, shrinking how long a theft stays useful, and detecting the ticket that surfaces where it was never issued.

Pass-the-ticket is common tradecraft for intrusion sets operating inside Active Directory, because it lets them ride a legitimate session sideways without generating the noise of fresh authentication. You can review which actors lean on Kerberos ticket abuse in our Threat Groups directory, which helps you decide whether Credential Guard coverage or ticket-lifetime tightening is the more urgent move for your environment.

Frequently asked questions

Does changing my password stop a stolen ticket? No. A password change invalidates the password and its hash, but an already-issued Kerberos ticket lives on its own schedule until it expires. Containing a stolen ticket means disabling the account, forcing ticket invalidation, and for ticket-granting-ticket material that can mean resetting the krbtgt key. Treat rotation as one step in containment, never the whole answer.

Is pass-the-ticket the same as a golden ticket? No. Pass-the-ticket reuses a real ticket that the domain controller genuinely issued to a real user. A golden ticket is forged from the stolen krbtgt key, so the attacker mints ticket-granting tickets the domain controller never issued, for any user and lifetime they choose. Pass-the-ticket is bounded by the account and the ticket's normal expiry. A golden ticket is bounded only by the compromised key.

Does multi-factor authentication prevent it? Not once a ticket exists. Multi-factor protects the initial authentication. A Kerberos ticket issued after that point is a bearer token with no second factor attached, so an attacker who steals the ticket inherits the authenticated session without facing a prompt.

How is a stolen ticket actually detected? The strongest signal is origin mismatch: a ticket used from a host or source address that differs from where it was issued. Support it with service ticket requests that lack a preceding ticket-granting-ticket request, privileged accounts appearing on hosts they never touch, and bursts of service access after a single logon. Correlating these across 4768, 4769, and 4624 events surfaces reuse.

Why is the ticket-granting ticket the bigger prize than a service ticket? A ticket-granting ticket proves identity to the domain controller and can be exchanged for service tickets across the domain, so one stolen ticket-granting ticket unlocks many services. A service ticket grants access to a single named service and nothing more. Reach is the difference, and it is why defenses concentrate on keeping high-value ticket-granting tickets out of memory.

What is the single most effective preventive control? Keeping privileged tickets off machines that might be compromised, paired with Credential Guard on supported systems. If a domain administrator never logs on to an ordinary workstation, that workstation's memory never holds a domain-administrator ticket to steal. Combine that with shorter lifetimes and origin-mismatch detection for defense in depth.

Can constrained delegation help? Yes, indirectly. Unconstrained delegation lets a server hoard the ticket-granting tickets of everyone who connects to it, turning that server into a reservoir of high-value tickets. Replacing it with constrained delegation and marking sensitive accounts as not delegable removes those tickets from the server entirely, so a compromise of that server yields far less.

The core of the defense follows from the nature of the attack. A ticket is a bearer token that your password cannot revoke, so protect the memory it lives in, keep privileged tickets off machines that might be compromised, shorten how long a stolen one stays useful, and detect the ticket that appears somewhere it was never issued. Do that and a stolen ticket becomes a short-lived, loud, and quickly contained problem instead of a quiet path across your domain.