Pass-the-Hash in Active Directory: Detection and Mitigation

What Is Pass-the-Hash?

Pass-the-Hash is a method of authenticating with stolen NTLM-derived credential material instead of the user's cleartext password. In practice, the attacker steals reusable authentication material from a compromised Windows system and uses it to access another host or service as that user.

For this article, the scope is deliberately narrow: Windows, Active Directory, NTLM, and lateral movement. This is not a generic credential-theft article. The focus is the specific operating model that makes Pass-the-Hash relevant in enterprise AD environments: a compromised workstation or server, reusable credential material on that system, and a second host that still accepts NTLM-based authentication.

That distinction matters because Pass-the-Hash is often mixed together with several adjacent techniques:

Password spraying guesses common passwords across many accounts and does not require stolen hashes.
Pass-the-Ticket uses stolen Kerberos tickets, not NTLM-derived material.
Overpass-the-Hash uses NTLM-derived material to obtain Kerberos authentication material and then pivots into Kerberos-based access.
Kerberoasting requests service tickets and cracks them offline to recover service-account passwords.

Pass-the-Hash is its own problem: the attacker already has reusable authentication material and does not need to know the password in clear text to keep moving.

How Pass-the-Hash Works

MITRE classifies Pass-the-Hash as T1550.002, a sub-technique of Use Alternate Authentication Material. The core idea is simple: Windows and related authentication flows generate and retain authentication material after a user logs on, and that material can sometimes be reused if an attacker steals it.

In Windows environments, NTLM remains the main reason Pass-the-Hash is still operationally relevant. If a remote target accepts NTLM, the attacker may be able to present stolen NTLM-derived material and authenticate without ever learning the cleartext password. That is why reducing NTLM usage and reducing where reusable credentials land are both central defenses.

The practical source of reusable material is usually one of these paths:

LSASS memory on a compromised endpoint or server after the victim has signed in
SAM / SECURITY hives for local-account material on the host
Shared local administrator credentials reused across many systems
Credential-dumping after the attacker already has local admin or equivalent execution on a host

Microsoft's Credential Guard documentation is useful here because it explains what the feature is actually protecting: NTLM, Kerberos, and Credential Manager secrets are isolated with virtualization-based security instead of being left only in the normal LSASS process space. That does not eliminate all credential-theft risk, but it materially changes the attack surface for classic PtH workflows.

Preconditions for a Successful Pass-the-Hash Attack

Pass-the-Hash usually succeeds only when several conditions line up.

1. The attacker already compromised a Windows host

Pass-the-Hash is rarely the first move. The attacker typically begins with phishing, malware, exploited remote access, weak local admin hygiene, or another initial foothold. PtH then becomes a lateral-movement technique.

2. Reusable credential material is present on the compromised system

This is the central requirement. If privileged users log on to lower-trust systems, if administrators use RDP without stronger protections, or if servers accumulate reusable admin credentials in LSASS, the attacker has something to steal.

3. The next target still accepts NTLM authentication

The technique is much harder to use if the environment has reduced NTLM reliance, hardened remote admin patterns, or moved critical workflows away from reusable NTLM-backed authentication paths.

4. The compromised credential still has meaningful rights elsewhere

A stolen low-value account hash is far less useful than the material of a local administrator reused across endpoints, a helpdesk account with broad admin reach, or a privileged AD account that signs into member servers.

5. Administrative hygiene is weak enough to let the attacker chain hosts

This is why Pass-the-Hash is tightly connected to lateral movement, not just credential theft. If local admin passwords are unique, privileged admins use dedicated workstations, and privileged credentials do not land on lower-tier systems, the attacker loses the path that makes PtH valuable.

The Attack Chain

A typical Pass-the-Hash sequence in an AD environment looks like this.

Step 1 - Gain code execution on an initial host

The attacker compromises a workstation or server through phishing, malware, vulnerable software, or a preexisting access path.

Step 2 - Dump reusable material

Once the attacker has the required privileges on that host, they target LSASS or local credential stores and extract reusable material. MITRE explicitly maps tooling such as Mimikatz to Pass-the-Hash use, including the SEKURLSA::Pth module.

Step 3 - Identify the best account to reuse

The attacker does not need every account. They need the account that can reach the next system. In real environments this often means:

a reused local administrator account
a helpdesk or endpoint admin identity
a server admin account that touched many hosts
a privileged AD account that should never have landed on that endpoint

Step 4 - Authenticate to another host using NTLM-backed access

At this point the attacker moves laterally through administrative protocols, remote service creation, SMB-based admin access, WMI, scheduled tasks, or other Windows management paths that still accept the reused material.

Step 5 - Repeat until the attacker reaches a privileged tier

The danger of Pass-the-Hash is not one hop. The danger is the chain. One compromised workstation leads to another admin context, then to a management server, then to a server where higher-value credentials are present, and eventually to domain or enterprise control. That is the same operational logic described more broadly in Active Directory Attack Paths to Domain Admin: each weak credential boundary makes the next hop easier.

Pass-the-Hash vs. Overpass-the-Hash vs. Pass-the-Ticket

These techniques are related but they are not interchangeable.

Pass-the-Hash stays centered on NTLM-derived authentication material and NTLM-accepted access paths.

Overpass-the-Hash starts from NTLM-derived material but uses it to obtain Kerberos authentication material, effectively pivoting from NTLM-derived secrets into Kerberos-based access.

Pass-the-Ticket skips NTLM-derived material and reuses stolen Kerberos tickets directly.

That distinction matters for both detection and remediation. If defenders collapse them into one concept, they usually build a weak detection strategy and apply the wrong mitigations to the wrong path.

Detection

There is no single Windows event that says "this was Pass-the-Hash." A usable detection strategy is a correlation strategy.

MITRE's Windows detection strategy for T1550.002 is directionally correct: correlate anomalous NTLM LogonType 3 activity with process, session, and network context rather than relying on one indicator in isolation.

What to look for

4624 patterns

4624 is useful when you care about where the session appeared, what logon type it used, and which account context is unexpected on that system.

High-value examples include:

a network logon that places an admin identity on a host it rarely touches
repeated lateral movement from one compromised workstation into multiple peers or servers
a reused local admin identity showing up across several endpoints

4672 on the destination

4672 is helpful when a new logon receives special privileges on the target system. It is not a PtH detector by itself, but it helps identify which remote logons actually matter.

NTLM context where available

Where your telemetry captures NTLM authentication context, that is valuable because PtH lives or dies on NTLM-accepted access paths. The goal is not to alert on every NTLM event. The goal is to identify unexpected NTLM-backed administrative activity involving accounts, systems, or paths that do not normally pair together.

Unusual privileged movement across hosts

The strongest signals often come from behavior, not a single event ID:

the same admin identity appearing across multiple hosts in a short window
local administrator context reused on hosts that should each have unique admin passwords
administrative access starting from a workstation that is not part of the normal admin workflow

EDR signals for credential dumping and LSASS access

Pass-the-Hash typically depends on credential theft first. If your EDR shows suspicious LSASS access, credential-dumping behavior, or follow-on remote admin activity from the same host, that correlation is usually more valuable than a standalone event-based rule.

Example detection framing

Do not frame detections as "4624 means Pass-the-Hash." A better frame is:

suspicious credential-access behavior on host A
followed by NTLM-backed remote logon or admin activity on host B
using an account context that does not match the normal source system or admin workflow

That is the level at which defenders actually catch PtH.

Monitoring dependency

If you are weak on AD and Windows monitoring, this technique will be easy to miss. That is why Active Directory Monitoring: Security Event IDs That Matter belongs in the same control family as PtH detection.

Remediation

Pass-the-Hash remediation is not one setting. It is a strategy to reduce where reusable credential material exists, reduce where NTLM is still accepted, and reduce how far one stolen admin context can travel.

1. Enable Credential Guard where it is supported

Microsoft states that Credential Guard protects NTLM hashes, Kerberos TGTs, and other secrets by isolating them with virtualization-based security. This is one of the most direct mitigations against classic credential-theft workflows that enable PtH.

Important caveats from Microsoft documentation:

some authentication capabilities are blocked, so applications must be tested before rollout
Credential Guard does not protect local accounts and Microsoft accounts in the same way it protects domain-derived secrets
supplied credentials for NTLM authentication are not fully protected in every scenario
Microsoft explicitly says enabling Credential Guard on domain controllers is not recommended

2. Use Remote Credential Guard or Restricted Admin for RDP workflows

Microsoft documents two different protections for RDP-based admin workflows.

Remote Credential Guard prevents credentials from being sent to the remote device and is preferred where the scenario supports it.

Restricted Admin is still valuable, and Microsoft specifically recommends it for helpdesk support scenarios because it helps keep reusable credentials and user resources from being exposed to a compromised remote host.

Important caveats from Microsoft documentation:

Remote Credential Guard only works with RDP
it requires Kerberos
it is supported only for direct connections to target machines, not through RD Gateway or Connection Broker
it cannot be used when the remote host is Microsoft Entra joined only
Remote Credential Guard does not support every authentication scenario, so compatibility testing matters

3. Eliminate local administrator password reuse with Windows LAPS

Shared local admin passwords are one of the easiest ways to make Pass-the-Hash scale. Microsoft explicitly frames Windows LAPS as protection against attacks that exploit local accounts for lateral movement, including PtH-style progression.

If the same local admin password exists on dozens or hundreds of endpoints, one host compromise can become a broad lateral-movement campaign. Windows LAPS Not Deployed: Why Shared Local Admin Passwords Still Matter should therefore be treated as a direct PtH exposure article, not a separate hygiene topic.

4. Keep privileged credentials off lower-trust hosts

Microsoft's own Credential Guard guidance is blunt here: use dedicated PCs for high-value accounts. This is one of the most practical anti-PtH controls because it reduces the chance that privileged credential material ever lands on commodity workstations.

That can take several forms:

dedicated admin workstations
admin jump hosts with strict role scope
tiered administration where lower-tier systems cannot collect higher-tier credentials
separate admin identities rather than daily-use admin behavior

5. Reduce NTLM use where feasible

Pass-the-Hash remains operationally useful because NTLM remains operationally useful. If critical administrative paths still rely on NTLM, the attacker has more room to move. Reducing NTLM usage, removing unnecessary NTLM dependencies, and preventing silent fallback all lower PtH exposure.

This is also why PtH and NTLM Relay Attacks: Hijacking Authentication in AD belong in the same review motion. They are different techniques, but both survive on the same underlying protocol debt.

6. Protect the accounts most worth stealing

For highly privileged identities, consider controls that make NTLM usage and reusable credential storage less acceptable operationally:

avoid signing into general-purpose systems with privileged identities
use the Protected Users group where the environment can support its restrictions
review Stale Privileged Accounts: Hidden Risk in Active Directory and remove old identities that keep unnecessary reach into many systems
tighten Active Directory Password Security: Misconfigurations That Matter so weak password hygiene does not amplify the damage of one stolen admin context

Protected Users is powerful but not free. Microsoft documents that its members cannot authenticate using NTLM, Digest, or CredSSP default delegation, and that legacy workflows may fail. That makes it a strong high-value-account control, but not a drop-in change for every environment.

Validation After Hardening

Do not close Pass-the-Hash remediation because one setting was enabled. Validate the path end to end.

confirm that privileged accounts no longer sign into lower-tier systems that expose their credential material
verify that Windows LAPS is actually rotating unique local admin passwords on the systems in scope
test Credential Guard compatibility on representative systems before broad rollout, then confirm it remained enabled after deployment
validate that RDP admin workflows use Remote Credential Guard or Restricted Admin where intended
review whether the remaining administrative paths still rely on NTLM or silent fallback
test whether a compromised endpoint could still reach other endpoints using a reused local admin context

The right success criterion is not "we enabled a control." The right success criterion is "one stolen admin context can no longer move the attacker through the same chain."

EtcSec does not need a fake Pass-the-Hash taxonomy tag to be useful here. The value is in the related exposures that make PtH viable.

The most relevant control families around PtH are:

Together, those checks tell you whether the environment still has the ingredients that let one stolen Windows credential become a lateral-movement chain.

Pass-the-Hash is rarely the only identity problem in the estate. If you want to reduce real attacker movement rather than improve one checklist item, review PtH together with Windows LAPS Not Deployed: Why Shared Local Admin Passwords Still Matter, WDigest Enabled: Why Cleartext Credentials Reappear in LSASS, NTLM Relay Attacks: Hijacking Authentication in AD, Stale Privileged Accounts: Hidden Risk in Active Directory, Active Directory Monitoring: Security Event IDs That Matter, and Kerberoasting: How Attackers Crack Service Account Passwords. Those are the neighboring controls that decide whether PtH remains a practical operator technique in your AD environment.

Pass-the-Hash: How Stolen NTLM Hashes Still Lead to Lateral Movement