Pass-the-Hash and Pass-the-Ticket: Mechanics and Detection for Blue Teams

Credential theft remains one of the most reliable ways for an intruder to move through a Windows domain, and two techniques sit at the center of it: Pass-the-Hash (PtH) and Pass-the-Ticket (PtT). Both abuse how authentication protocols are designed to work rather than a single patchable bug, which is exactly why defenders need to understand them deeply. This article takes an understand-to-defend approach: we explain what these techniques are, how they operate at a conceptual level, where the credential material lives, and — most importantly — the concrete detection signals and hardening steps that let a blue team spot and contain lateral movement. There are no attack recipes here, only the knowledge a defender needs to build resilient monitoring and shrink the blast radius of a compromised host.

What Pass-the-Hash and Pass-the-Ticket actually are

In a Windows environment, users rarely re-enter their password for every resource. Instead, the operating system keeps authentication artifacts in memory so it can prove identity on the user's behalf. In NTLM authentication that artifact is a password-equivalent hash; in Kerberos it is a ticket, either a Ticket-Granting Ticket (TGT) or a service ticket. Pass-the-Hash is the reuse of a stolen NTLM hash to authenticate as a user without ever knowing the plaintext password. Pass-the-Ticket is the equivalent idea for Kerberos: a stolen or forged ticket is presented to gain access. The strategic point for defenders is that both techniques turn a single compromised endpoint into a launchpad, because the artifacts harvested there are valid elsewhere in the domain.

How the techniques work at a high level

Both techniques share a common precondition: an attacker who has already gained privileged code execution on a host and can read protected memory belonging to the LSASS process, the Windows subsystem that caches credential material for single sign-on. Once that material is extracted, PtH replays the hash against services that accept NTLM, and PtT injects a valid ticket into a logon session so that Kerberos-based services trust it. Variants such as Overpass-the-Hash bridge the two worlds by using an NTLM hash to request a Kerberos TGT, while forged-ticket variants — the Golden Ticket built from the krbtgt key and the Silver Ticket scoped to a single service — let an intruder mint their own tickets rather than steal existing ones. The unifying theme is that the attacker never needs the password: the secret they need is the derived artifact, and that artifact is designed to be replayable by legitimate software. This is why the defensive answer is layered — you cannot simply patch away a protocol that is behaving as specified, so you constrain where artifacts appear, isolate them in memory, and instrument the environment to make their abuse noisy.

Attack surface: where credential material lives

Understanding the surface tells you what to protect. The primary reservoir is LSASS memory on any host where a privileged account has recently logged on interactively, over Remote Desktop, or through a service that caches credentials. Secondary reservoirs include the local SAM database, cached domain logon verifiers, the NTDS.dit database on domain controllers, and backups or virtual-machine snapshots that contain any of these. Highly privileged accounts — Domain Admins, service accounts with broad rights, and backup operators — are the crown jewels, because a single harvested hash or ticket for one of them can unlock the entire directory. The defensive corollary is a principle of credential hygiene: never let a Tier 0 account authenticate to a lower-trust workstation, because doing so seeds that machine's memory with a domain-owning secret.

Detection signals: logs, Event IDs and telemetry

Detection is where blue teams win. Because these techniques reuse legitimate protocols, no single event is a smoking gun; instead you correlate several weak signals into a strong one. Watch Windows Security logs for Event ID 4624 (successful logon) with Logon Type 3 (network) or Type 9 (NewCredentials), especially when the authentication package is NTLM for accounts that should be using Kerberos. Pair 4624 with 4776 (NTLM credential validation) and 4672 (special privileges assigned) to spot privileged network logons that do not match normal patterns. For Kerberos abuse, monitor 4768 (TGT requested) and 4769 (service ticket requested); tickets with unusual encryption types, mismatched lifetimes, or requests for accounts that never log in interactively deserve scrutiny. Forged-ticket variants often produce tickets whose lifetime exceeds domain policy, which is a strong anomaly.

Endpoint telemetry closes the gap. A quality EDR flags suspicious handle requests to LSASS — process access with rights such as PROCESS_VM_READ from a non-system process is a high-value alert — as well as the loading of unusual drivers and the injection of ticket material into logon sessions. Sysmon adds precision: Event ID 10 (ProcessAccess) targeting lsass.exe, Event ID 1 (process creation) for known credential-tooling patterns, and Event ID 3 (network connection) for lateral connections from workstation to workstation. The most durable behavioral signal is lateral movement itself: an account authenticating from a machine it has never used before, at a time it never works, to hosts it never touches. Baselining normal authentication paths and alerting on deviations catches PtH and PtT even when the tooling is novel.

Mitigation and hardening

The most effective control is credential tiering: divide accounts and systems into administrative tiers (Tier 0 for domain controllers and identity infrastructure, Tier 1 for servers, Tier 2 for workstations) and forbid high-tier credentials from ever logging on to lower tiers. This alone denies the attacker the crown-jewel artifacts on soft targets. Enable Credential Guard, which uses virtualization-based security to isolate LSASS secrets from the running OS, dramatically raising the cost of extraction. Deploy LSASS protection (RunAsPPL / Protected Process Light) so ordinary code cannot open a read handle to the process. Use the Protected Users security group for sensitive accounts, which disables NTLM, weak Kerberos encryption, and credential caching for its members.

Reduce the number of places secrets land. Enforce the least-privilege principle so day-to-day work never uses a domain-admin account; provide separate, non-email admin accounts used only from hardened privileged-access workstations (PAWs). Configure logon restrictions with Deny log on locally and Deny log on through Remote Desktop to keep Tier 0 accounts off ordinary machines. Rotate the krbtgt account password on a schedule — twice, with a delay — to invalidate forged Golden Tickets. Disable NTLM where possible and audit where it remains required. Segment the network so a compromised workstation cannot reach peers directly, and require SMB signing and LDAP channel binding to blunt relay-style abuse. Finally, shorten Kerberos ticket lifetimes within operational tolerance so stolen tickets expire quickly.

Common pitfalls that weaken defenses

Even mature teams undercut themselves. A frequent mistake is enabling Credential Guard on workstations but leaving a domain-admin logging on to servers where it is not enabled, re-seeding harvestable secrets. Another is treating detection rules as fire-and-forget: authentication baselines drift as the estate changes, so a rule that was tuned last year now buries real alerts in noise. Teams also over-trust a single Event ID; because 4624 and 4769 fire constantly, alerting on them without correlation produces alert fatigue and nothing else. Backups are a blind spot — an unprotected NTDS.dit backup hands over every hash in the domain. Finally, forgetting to rotate krbtgt after an incident leaves forged-ticket persistence intact even after you believe you have evicted the intruder.

Defender checklist

Use this as a working checklist. Identity: implement administrative tiering; place sensitive accounts in Protected Users; use PAWs for all privileged work; rotate krbtgt twice on a schedule and after any suspected compromise. Host hardening: enable Credential Guard and RunAsPPL; keep LSASS protection verified, not just configured; restrict local and RDP logon rights per tier. Detection: collect and centralize Security Event IDs 4624, 4672, 4768, 4769, 4776; deploy Sysmon with ProcessAccess monitoring on lsass.exe; baseline normal authentication paths and alert on deviation; hunt for tickets with abnormal lifetimes or encryption types. Containment: segment the network, enforce SMB signing and LDAP channel binding, disable legacy NTLM, and rehearse an incident runbook that includes krbtgt rotation and privileged-credential resets.

Frequently asked questions

Is Pass-the-Hash still relevant if we use Kerberos everywhere? Yes. Many environments fall back to NTLM for edge cases — direct IP connections, older applications, or misconfigured services — and any residual NTLM surface keeps PtH viable. Moreover, Pass-the-Ticket targets Kerberos directly, so migrating protocols is not a substitute for credential isolation and monitoring.

Does multi-factor authentication stop these techniques? MFA is essential at the point of interactive logon, but PtH and PtT reuse artifacts created after a successful authentication. Once the hash or ticket exists in memory, MFA is no longer in the loop. That is why the durable controls are artifact isolation (Credential Guard, LSASS protection), tiering, and behavioral detection rather than authentication strength alone.

Conclusion

Pass-the-Hash and Pass-the-Ticket endure because they exploit the very mechanisms that make single sign-on convenient. There is no single patch that removes them; instead, defenders win by making the harvested artifacts hard to obtain, useless outside a narrow scope, and loud when abused. Concentrate on credential tiering, memory-isolation features like Credential Guard and RunAsPPL, disciplined logon restrictions, and correlated detection built on Windows Event IDs and endpoint telemetry. When those layers work together, a single compromised workstation stays a single compromised workstation — and the intruder's most trusted technique becomes their most visible mistake.