A pass-the-hash attack is a lateral movement technique in which an attacker who has already captured a Windows NTLM password hash from one compromised machine uses that hash to authenticate to other systems on the network, without ever cracking it into a plaintext password. To answer the question of what a pass-the-hash attack actually is at the protocol level: NTLM challenge-response authentication accepts the hash itself as valid proof of identity, so a stolen hash is functionally equivalent to the password for authentication purposes. That single design decision, made decades before today's threat landscape, is why pass-the-hash remains one of the most reliable and enduring privilege-escalation techniques inside Windows domains. A single compromised workstation where a domain administrator once logged in can become the pivot point for full domain compromise within minutes, which is why the technique appears in nearly every major ransomware and APT playbook targeting enterprise networks.
What Is a Pass-the-Hash Attack?
A pass-the-hash attack is the reuse of a stolen NTLM hash to authenticate as a user without knowing their real password. Windows stores password hashes locally in the Security Account Manager (SAM) database and, for logged-in sessions, in the memory of the Local Security Authority Subsystem Service (LSASS) process. Under NTLM authentication, a server never asks a client to send a password — it sends a random challenge, and the client proves possession of the account by encrypting that challenge with the NTLM hash. Because the hash itself is the cryptographic material being checked, an attacker who extracts it from memory or disk can skip the "recover the password" step entirely and inject the hash straight into an authentication request. Tools such as Mimikatz, Impacket's wmiexec.py and psexec.py, and CrackMapExec automate this: they accept a captured hash as a credential and open an authenticated session on a target host exactly as if the real password had been typed in.
How Does NTLM Hash Theft Happen on a Windows Host?
NTLM hash theft almost always starts with local administrator access on a single endpoint, from which an attacker dumps credential material out of memory or the registry. The most common method is dumping the LSASS process, which caches the NTLM hashes of every account that has interactively logged onto that machine since the last reboot — including, critically, any domain admin who ran a script or opened a remote session there. Mimikatz's sekurlsa::logonpasswords module reads this directly from memory; other techniques pull hashes from the SAM database, from Volume Shadow Copies of the NTDS.dit database on a domain controller, or from cached domain credentials (MSCache2) on laptops that authenticate offline. Because many organizations still allow local administrator rights, reuse local admin passwords across machines, or leave helpdesk and service accounts logged in broadly, a single phishing foothold is frequently enough to reach a host holding high-value hashes.
How Do Attackers Achieve Lateral Movement With Stolen Hashes?
Lateral movement with stolen hashes works because Windows authentication protocols historically did not require proof that a client possesses the plaintext password — only proof it holds the corresponding hash. Once an attacker has a privileged hash, they inject it into their own session's memory using Mimikatz's sekurlsa::pth command, or pass it directly as a credential to remote-execution tools like PsExec, WMI, or PowerShell remoting (WinRM). This lets the attacker authenticate to any other machine or service the compromised account has rights on — file shares, domain controllers, backup servers — with zero interaction from the legitimate user and no password ever transmitted in the clear. Because a single hash can be reused against dozens of systems in the same forest, an intruder frequently escalates from a low-value workstation to full domain-admin control across an entire environment in a single attack session, hopping machine to machine until a Domain Controller's hash is captured.
What Real-World Incidents Have Used Pass-the-Hash?
The 2017 NotPetya outbreak is the clearest large-scale example of pass-the-hash combined with a network worm to devastate a global enterprise. After gaining initial access through a compromised Ukrainian accounting software update, the malware harvested NTLM credentials and hashes from infected machines using a bundled Mimikatz component, then used pass-the-hash alongside the EternalBlue and EternalRomance SMB exploits to authenticate to and infect every reachable machine on the network. At Maersk, this combination destroyed roughly 49,000 laptops and servers in under 48 hours and cost the company an estimated $300 million, precisely because a single set of harvested domain-admin hashes gave the malware trusted access across the entire corporate network rather than requiring it to exploit each machine independently. Nation-state groups tracked as APT29 and APT41 have used the same core technique in long-running espionage campaigns, extracting hashes from a beachhead system and quietly pivoting toward domain controllers over weeks.
How Can Organizations Mitigate Pass-the-Hash Attacks?
Effective pass-the-hash mitigation starts with denying attackers the privileged hashes to steal in the first place, rather than trying to detect every possible reuse. Windows Defender Credential Guard isolates LSASS secrets in a virtualization-based security container that ordinary user-mode tools like Mimikatz cannot read, which directly blocks the most common theft path. Enforcing unique, randomized local administrator passwords through Microsoft LAPS prevents an attacker from reusing one cracked local admin hash across an entire fleet of machines. A tiered administration model — where domain admin credentials are never used to log into standard workstations, and admin accounts are restricted to jump hosts — limits which machines can ever hold a high-value hash in memory. Organizations should also disable NTLM in favor of Kerberos wherever legacy systems allow it, add sensitive accounts to the Protected Users security group (which prevents NTLM hash caching outright), and enforce network segmentation so that lateral SMB and RPC traffic between workstations is blocked by default. Combined, these controls shrink both the attack surface for Windows credential theft and the blast radius when a single endpoint is compromised.
How Safeguard Helps
Safeguard approaches pass-the-hash and broader Windows credential theft risk from the software supply chain angle: by making sure the build systems, CI/CD runners, and deployment credentials that touch your infrastructure are never left as an easy hash-harvesting target in the first place. Safeguard continuously inventories the service accounts, machine identities, and privileged credentials used across your pipelines, flags accounts with excessive standing access or stale sessions that leave hashes cached longer than necessary, and enforces short-lived, scoped credentials in place of long-lived NTLM secrets wherever a build or deployment step can be migrated off them. Because a single compromised build agent with cached domain credentials can become exactly the kind of pivot point pass-the-hash attacks exploit, Safeguard's dependency and pipeline visibility helps teams spot which systems hold high-value credentials, verify that mitigations like Credential Guard and Protected Users are actually applied to the machines that matter most, and catch anomalous lateral authentication patterns before a single stolen hash turns into a domain-wide breach.