Pass the Hash Attacks: How to Detect and Stop Them
Break pass the hash paths by protecting credential material, removing shared admin access, restricting NTLM, and correlating remote use.


Pass the hash is not a password cracking problem. It is a credential replay path that turns one exposed Windows secret into access across every system willing to trust it.
That distinction changes the defense. A stronger password helps before its hash is stolen, but the attacker does not need to recover the password to reuse the hash. Multifactor authentication may never appear in the exchange. The real job is to protect credential material, reduce shared administrative access, restrict NTLM, and block remote administration paths that should not exist.
Treat the technique as a four gate system. The actor needs a reusable hash, a service that accepts NTLM, an account with useful rights, and a target it can reach. Close any gate during an incident. Close all four in the operating model.
A pass the hash attack needs four open gates
The hash matters only when an accepted protocol, useful privilege, and a reachable target complete the path.
What is a pass the hash attack?
A pass the hash attack uses a stolen Windows password hash to authenticate without knowing the clear text password. MITRE ATT&CK tracks pass the hash as T1550.002, a Windows subtechnique under Use Alternate Authentication Material. The normal proof of the account secret has become the stolen artifact itself.
This is different from cracking. Password cracking tests guesses until one produces the same hash. Pass the hash skips that work and presents the NT hash through an authentication flow that accepts it. It is also different from NTLM relay, which forwards a live challenge and response between systems. Both abuse trust in NTLM, but the evidence and containment actions are not identical.
The technique usually follows credential access. An actor with local administrator or SYSTEM rights extracts material from LSASS memory, the Security Account Manager database, an Active Directory database, or another exposed store. They then use the account against SMB, remote service control, Windows Management Instrumentation, or another permitted channel. One host becomes a route to the next. Our credential dumping defense guide explains how to protect those stores and scope every identity exposed on the host.
Which conditions make pass the hash work?
First, the stolen material must still be valid. A password change replaces the NT hash, but service identities and local administrator passwords often survive for months. Second, the target must accept an NTLM path. Kerberos first environments still fall back when an application, local account, name resolution failure, or old workflow forces NTLM.
Privilege decides consequence. A hash for a standard user with no remote logon right may go nowhere. A shared local administrator hash can work on every machine carrying the same password. A domain identity with broad local administrator reach can turn workstation compromise into server compromise.
Network reach completes the path. SMB open from user networks to server networks, remote service management from ordinary workstations, and administrators signing in to lower trust systems all widen the route. This is why a useful lateral movement model joins identity, endpoint, protocol, and destination instead of labeling every hash exposure critical.
Why do password policy and MFA fall short?
Password policy still matters because a weak password makes other attacks easier. It does not solve replay after the hash is exposed. Standard multifactor authentication protects many interactive and cloud sign ins, but a pass the hash flow can use NTLM against a service that never asks the identity provider for another factor.
The 2025 Microsoft Digital Defense Report describes an analysis of 12.2 million accounts in one password spray campaign. Only 1.5 percent of correct username and password attempts in that example were blocked by multifactor authentication, while 45 percent of attempts used a valid username with a wrong password. Those figures show the scale of password abuse. They should not be misread as pass the hash telemetry. The defensive point is narrower: controls at an interactive sign in cannot protect a protocol exchange they never see.
Resetting a compromised password is necessary because it invalidates the old hash. It is not enough. If the same privileged identity signed in elsewhere, more hosts may hold usable material. If the actor already created a service, scheduled task, new account, ticket, or remote tool, the password reset removes only one foothold.
What changed in pass the hash defense in 2026?
MITRE revised T1550.002 on May 12, 2026. The page now includes a detection strategy that correlates NTLM network logons with logon session creation and process or service activity. It also added the 2025 Poland energy sector wiper attacks as a procedure example. This matters because a single event ID has never been a dependable answer. Relationships are the detection.
Microsoft published another useful signal in April 2026. Its domain compromise case studydescribes an actor moving from local escalation to directory credential access. Within 24 hours, the actor used a compromised privileged account to start a task on a domain controller and package directory credentials. The lesson is speed. Waiting for confirmed reuse gives the actor the time needed to create more credentials.
A better response begins when a privileged credential was probably exposed on a hostile endpoint. Restrict the identity, isolate the device, and inspect likely destinations before the first obvious remote service event. That is an operating change, not another alert rule.
How do you prevent pass the hash?
Protect secrets where they live. Microsoft Credential Guard guidanceexplains how virtualization based security isolates NTLM hashes, Kerberos tickets, and stored domain credentials. Microsoft enables it by default on eligible domain joined Windows 11 22H2 and Windows Server 2025 systems that are not domain controllers. An upgrade does not override a prior explicit disable setting, so verify actual state.
Remove credential overlap. Windows LAPS gives each managed machine a different local administrator password and rotates it. Keep domain administrators off user devices. Use separate accounts for ordinary work and privileged administration. Deny remote logon where an identity has no reason to connect. The Active Directory hardening guide covers tier boundaries, local password management, and recovery evidence in more detail.
Audit NTLM before restricting it. Identify applications, appliances, local accounts, and name resolution failures that still cause fallback. Fix the dependency, test the change, then narrow or deny NTLM by policy. At the network layer, allow administrative protocols only from managed administration systems to named targets.
Here is the simple math. If 800 endpoints share one local administrator password, one stolen hash may represent 800 possible targets. Unique LAPS passwords reduce that credential's valid target set from 800 to one. Segmentation can reduce the reachable set again. That is measurable risk reduction.
How can you verify Credential Guard?
Do not treat a policy assignment as proof. Microsoft documents this read only PowerShell check from an elevated session. A value of 0 means Credential Guard is not running. A value of 1 means it is running.
Run the check across the managed fleet and store the device, operating system, result, and collection time. Investigate eligible devices that report zero, plus devices that never report. Missing telemetry is not a pass. It is an unknown control state.
How do you detect pass the hash activity?
Start with successful NTLM network logons, then add source identity, source device, target, privilege, process, and service context. MITRE's current strategy calls out anomalous Logon Type 3 authentication without the domain logon events expected around normal use. That is a lead, not a verdict.
Correlate the logon with remote service creation, scheduled task creation, WMI activity, SMB access to administrative shares, or a process launched under the new session. Compare the relationship with history. A backup service reaching its normal server at the normal hour differs from a finance workstation authenticating to five servers it has never touched.
Watch for the precursor too. Credential dumping, access to LSASS, copies of registry hives, domain controller snapshot activity, and suspicious access to directory databases can justify containment before replay appears. The MITRE ATT&CK operating guide shows how to map those evidence requirements without turning a technique list into a false coverage score.
What should responders do after suspected hash exposure?
Isolate the source device while preserving evidence. Restrict identities that logged on there, starting with the accounts whose reach is greatest. Search for their authentication from other sources. Inspect target systems for new services, tasks, sessions, tools, and persistence. Then rotate secrets in an order that does not destroy your ability to understand the path.
Do not reset every account first and investigate later. A rushed reset can interrupt business services, remove useful signals, and leave persistence untouched. Build a containment sequence by identity value and observed reach. High privilege credentials on hostile endpoints go first.
Measure exposed privileged sessions, shared local administrator credentials, NTLM volume by application, systems without Credential Guard, allowed administration edges, and time from likely exposure to identity restriction. Those metrics describe the path. A count of blocked hashes does not.
Which pass the hash metrics should leaders track?
Track the number of privileged accounts that authenticate to ordinary endpoints, local accounts without verified password rotation, NTLM connections without an approved owner, and management ports reachable outside named administration zones. Add the percentage of eligible devices reporting Credential Guard as running. Report unknown devices separately instead of hiding them in the denominator.
For response, measure minutes from likely credential exposure to identity restriction, target search, and secret rotation. A team that closes a credential alert in five minutes but needs six hours to learn where the account can authenticate still has a six hour exposure window. Speed should follow the relationship, not the alert status.
Frequently asked questions
Does pass the hash reveal the original password?
No. The actor authenticates with the stolen NT hash without recovering the clear text password. They may still try to crack it for use in systems that require the password.
Does changing the password stop pass the hash?
It invalidates the old hash for that account. Responders still need to find other exposed credentials, active sessions, tickets, persistence, and systems reached before the change.
Can multifactor authentication prevent pass the hash?
Not by itself. Many NTLM service authentications do not invoke an interactive multifactor challenge. Protect the credential, restrict NTLM, narrow remote access, and remove reusable administrative passwords.
Is every NTLM logon evidence of an attack?
No. Enterprises often retain valid NTLM dependencies. Judge the source, identity, destination, process, service, timing, and prior relationship before escalating the event.
The executive takeaway
Ask for four numbers: privileged identities exposed on ordinary endpoints, machines with shared local passwords, eligible devices where Credential Guard is not running, and administrative network paths that lack an owner. Fix the intersections first. Deep endpoint context with AI driven analysis can help connect a credential event to the system state and exact target path. The management decision is simpler. Stop allowing one stolen secret to remain valid everywhere.
Put more evidence behind vulnerability decisions
Artemes AI combines endpoint telemetry, sourced vulnerability intelligence, and analysis with practitioner review so teams can examine the evidence, missing context, and recommended next step together. We are accepting early access requests now.

Chris Seymour
Chris writes about vulnerability prioritization, exploitability, remediation supported by AI, and the engineering realities of turning scanner output into remediation decisions.
Related Reading
Get articles like this in your inbox.
Security research and occasional Artemes AI product updates.

