What Is a Pass-the-Ticket Attack? Kerberos Ticket Theft Explained

Pass-the-ticket attacks bypass most traditional, credential-based defenses because they don’t rely on stolen passwords. Instead, the attacker uses a Kerberos ticket taken directly from a compromised machine’s memory. With this ticket, the attacker can authenticate as that user on other systems, without triggering the failed-logon alerts most defenses watch for. Pass-the-ticket attacks are hard to […]

A single stolen Kerberos ticket can compromise trust across an entire Active Directory (AD) domain — an attack path that password-focused defenses completely miss.

Pass-the-ticket attacks bypass most traditional, credential-based defenses because they don’t rely on stolen passwords. Instead, the attacker uses a Kerberos ticket taken directly from a compromised machine’s memory. With this ticket, the attacker can authenticate as that user on other systems, without triggering the failed-logon alerts most defenses watch for.

Pass-the-ticket attacks are hard to identify: after all, the tickets are real, and so are the domain controllers that issue them. Unsurprisingly, the pass-the-ticket strategy has been used in many enterprise breaches. We’ll explain exactly how this attack works and what sets it apart from other Kerberos and NT LAN Manager attacks. We’ll also explain how to protect your organization from these attacks.

What Is a Pass-the-Ticket Attack?

In a pass-the-ticket attack, an attacker uses a stolen ticket to impersonate the ticket’s true owner, gaining access to protected resources without relying on a password. Attackers steal these tickets – often ticket granting tickets (TGT) or service tickets – from compromised systems, and reuse them on other systems. MITRE ATT&CK classifies the strategy as T1550.003 under its broader Lateral Movement category.

Pass-the-ticket attacks exploit a specific design feature in Kerberos, the authentication protocol behind the attacks. (Kerberos is defined in RFC 4120.) A Kerberos client does not send passwords with each request. Instead, the client collects tickets and then submits them to other services.

Tickets can be copied and then reused — attackers don’t need to guess them or crack them, as they would with passwords. Instead, attackers steal the tickets from compromised endpoints and use them until they expire.

How Does a Pass-the-Ticket Attack Work?

Attackers use a number of different tools to carry out pass-the-ticket attacks – but the attacks always follow the same basic structure. Here’s what that looks like:

  1. Initial compromise: The attacker establishes code execution on the targeted device. Most attacks achieve this through phishing attempts, publicly exposed services, or previously compromised credentials.
  2. Ticket extraction: Once armed with administrative or SYSTEM-level privileges, the attacker extracts Kerberos tickets from Local Security Authority Subsystem Service (LSASS) memory, where Windows stores logged-on session credentials.
  3. Ticket injection: The attacker loads that stolen ticket into a local session, typically on their own system. This enables the attacker to access resources as the legitimate user.
  4. Lateral movement: The attacker uses the injected ticket to request new service tickets, in order to access other systems. Armed with the ticket, the attacker can now move across networks without relying on a password.

    Note: This step closely mirrors standard pivoting strategies: for a detailed explanation, read our guide on lateral movement in enterprise networks.

  5. Persistence and repetition: Attackers can reuse this technique until the ticket expires – and if it has a long lifespan left, the potential damage can be significant.

It’s worth noting that stolen service tickets only grant access to specific services – the ones that the tickets were issued for. In contrast, attackers can use stolen TGTs to request new service tickets for any resource the compromised account was authorized to use.

What’s the Difference Between Pass-the-Ticket, Pass-the-Hash, Golden Ticket, and Silver Ticket?

These strategies are often confused, likely because they all target Kerberos or NTLM authentication material. None of them rely on stolen passwords. The difference comes down to whether attackers are reusing real material or forging something new. Attackers also rely on different credentials to pull off each type of strategy. The following table explains how the different attack types work:

Attack What the Attacker Uses Protocol Credential Needed
Pass-the-ticket A stolen, legitimate Kerberos ticket (TGT or service ticket) Kerberos Access to a system where a valid ticket is already cached
Pass-the-hash A stolen NTLM password hash NTLM An NTLM hash, not a Kerberos ticket
Golden ticket A forged TGT built from scratch Kerberos The domain’s KRBTGT account hash
Silver ticket A forged service ticket built from scratch Kerberos A single compromised service account hash

Pass-the-hash differs from the other techniques in a few key ways. ass-the-hash repurposes an NTLM hash instead of a Kerberos ticket. Unlike pass-the-ticket, the pass-the-hash technique does not touch the KDC.

Golden and silver tickets do not rely on stolen tickets at all. Attackers can use the KRBTGT hash to create a fake TGT without needing to steal a real ticket. MITRE classifies this and similar ticket-forging strategies under T1558, or Steal or Forge Kerberos Tickets.

Pass-the-ticket stands out from the other attack types on that list because it doesn’t forge anything. The ticket used by attackers is absolutely authentic. Pass-the-ticket attacks rely on the fact that Windows trusts all correctly formed, unexpired tickets, no matter which machine presents them.

How to Identify Pass-the-Ticket Attacks

Since the actual ticket is authentic, pass-the-ticket does not trigger failed logon alerts. To detect a pass-the-ticket attack, teams should pay attention to exactly where the ticket shows up, not whether it works. Here’s how to detect this attack type:

  • Use anomalous logon patterns: Event ID 4624 tracks successful logons. It is essential for correlating account activity against anomalous source IP addresses.
  • Track ticket request volume: Monitor Event ID 4768 and Event ID 4769 for sudden volume spikes in TGT and service ticket requests. A sudden increase in requests, especially from atypical source hosts, is worth investigating.
  • Monitor ticket renewal anomalies: Event ID 4770 logs Kerberos service ticket renewals. Flag any renewal from a host without a prior session.
  • Watch for identical tickets on multiple hosts: Simultaneous ticket use across multiple hosts — or mismatched session metadata — often indicates ticket injection rather than a real logon.
  • Monitor user and entity behavior anomalies: Flag tickets used outside an account’s normal geographic location, device, or time of day. This is a standard flag under Security Information and Event Management (SIEM) rules.

Note: It’s worth stressing that none of these signals should be trusted in isolation. Remember that pass-the-ticket detection is a correlation problem: effective detection relies on comparing each ticket’s claims to where and when the ticket is used.

Preventing Pass-the-Ticket Attacks

Because pass-the-ticket targets Windows Kerberos ticket caching, effective defenses belong at the host layer instead of the network edge.

  • Credential Guard: Credential Guard isolates NTLM hashes and Kerberos TGTs by leveraging virtualization-based security. TThis prevents ordinary processes, like malware with local administrator rights, from reading the protected TGT. Credential Guard does not extend that protection to Kerberos service tickets, and it does not stop an attacker who already has malware on the machine from using the privileges tied to a credential — so it narrows pass-the-ticket rather than closing it.
  • Short ticket lifetimes: Minimizing the length of time that a TGT or service ticket stays valid reduces the window for an attacker to use a stolen ticket before expiration.
  • AD tiering and least privilege: Enforcing strict Active Directory tiering prevents high-privilege accounts from authenticating to a lower-tier workstation, limiting how valuable any single stolen ticket can be.
  • Avoiding privileged credential caching: Enforce policies that prevent privileged accounts from interactive logons on standard endpoints. This stops Kerberos tickets from being cached and then stolen.
  • Endpoint hardening and EDR: Revoke local administrator rights and utilize Endpoint Detection and Response (EDR) tooling to monitor LSASS memory access. This strategy directly blocks the tools attackers rely on to extract Kerberos tickets.
  • Regular patching: Maintain current domain controllers and endpoints in order to close privilege escalation vectors attackers exploit before extracting tickets.

Where Does Certificate-Based Authentication Fit In?

Pass-the-ticket attacks don’t begin with Kerberos. They start with an initial compromise — commonly through stolen credentials, phishing, or an exploited internet-facing service. Phasing out password and NTLM dependence at the network layer removes one of the most common footholds attackers use to initiate ticket theft.

Deploying PKINIT (RFC 4556) enables Kerberos to validate user identity with a public key infrastructure (PKI) certificate rather than passwords. Using Dynamic PKI to deliver X.509 certificates ties identities to devices and users, rather than to passwords that an attacker could phish.

Note: Although this strategy cannot stop ticket theft that is already in progress, it does remove a common vector attackers use to get onto compromised machines.

How Network Segmentation Supports Kerberos Defense

On its own, segmentation does not stop ticket theft. However, it reduces the reach of stolen tickets once they are in an attacker’s hands.

Segmenting devices by identity at the network access layer — instead of relying on IP addresses or subnets alone — limits which sensitive, high-privilege services a compromised low-tier machine can reach. Domain-joined endpoints still need a path to a domain controller to request Kerberos tickets and apply Group Policy, so the goal is to narrow that reach, not to remove it.

Note: Bear in mind that this is a minor, supporting control, and does not correct the underlying Kerberos weakness. It is most effective when used along with 802.1X-driven access enforcement at the network authentication layer.

Reducing Attack Surfaces via Cloud RADIUS and Dynamic PKI

Pass-the-ticket targets Active Directory and Kerberos directly. Once an attacker gains administrative rights on an endpoint, network security tools can’t prevent them from reusing cached tickets on that machine. However, network access controls can reduce initial footholds and contain how far a compromised device can reach.

Dynamic PKI eliminates password-based Wi-Fi, VPN, and application logins, replacing legacy mechanisms with phishing-resistant certificates. This cuts off a primary entry point — passwords — that attackers exploit before ever reaching Kerberos.

Cloud RADIUS enforces access at the point of connection, segmenting devices and users based on identity, not subnet. Together, Cloud RADIUS and Dynamic PKI shrink the credential-theft surface that enables lateral movement, leaving Kerberos-layer defenses to target pass-the-ticket directly.

Schedule a demo to learn more about how certificate-based network access supports a defense-in-depth strategy that works with Credential Guard, AD tiering, and Kerberos monitoring.

Key Takeaways
  • Pass-the-ticket attacks exploit stolen Kerberos credentials to impersonate users without needing a password.
  • Attackers harvest cached Kerberos tickets from memory, inject them into new sessions, and move laterally across the network as trusted users.
  • While pass-the-ticket relies on harvesting stolen tickets, golden and silver tickets are generated using stolen account hashes.

Frequently Asked Questions

Does multi-factor authentication prevent pass-the-ticket attacks?

Multi-factor authentication (MFA) is an effective strategy for preventing the initial logon that generates tickets. However, MFA can’t protect you from attack once the ticket is already stolen. After an attacker extracts the ticket from memory, they do not need to pass MFA again: as far as the system is concerned, the user already did.

Is network segmentation an effective defense against pass-the-ticket?

The short answer is no. Segmentation does constrain a stolen ticket’s movement reach across the network, but it does not prevent attackers from stealing and reusing the ticket in the first place. The best defense against pass-the-ticket is located at the Kerberos and endpoint layer. Tools like Credential Guard, short ticket lifetimes, and administrative tiering are highly effective against this attack form.

How long do stolen Kerberos tickets remain valid?

This depends on the AD administrator, who sets the domain’s configured ticket lifetime policy. Typically, a TGT’s lifetime lasts several hours without renewal. Attackers can use stolen tickets during the configured window, which is why shortening ticket lifetimes is a standard strategy for limiting the impact of pass-the-ticket attacks.

Is pass-the-ticket visible in Active Directory event logs?

Pass-the-ticket is detectable, although not through a single definitive event. Effective detection correlates Kerberos ticket-request events (4768, 4769, 4770) and logon events (4624) across unusual hosts; the best practice is to combine this with behavior analytics. Individual event IDs can’t identify pass-the-ticket attacks on their own, because the ticket itself is valid.