Pass-the-hash attack: How the attack works and how to stop it

A stolen password hash grants immediate access to every system that account touches, bypassing password complexity entirely. Pass-the-hash exploits NTLM's authentication design: Windows systems accept the hash value itself as proof of identity, making a 20-character password as vulnerable as "password123" once the hash is compromised.

Attack surfaces and threat vectors

Pass-the-hash targets NTLM authentication, which stores password hashes in the Local Security Authority Subsystem Service (LSASS) process memory on Windows systems. Attackers extract these hashes from LSASS memory using tools like Mimikatz, then replay the hash to authenticate to remote systems without knowing the plaintext password.

It is worth noting that pass-the-hash as a technique does not work against NTLMv2, which incorporates a challenge-response mechanism that prevents a raw hash from being replayed directly. However, NTLMv2 authentication traffic can still be captured and relayed intact to a target system in a pass-the-hash relay attack, allowing an attacker to authenticate as the victim without ever recovering the underlying hash value. Upgrading to NTLMv2 alone is therefore not sufficient protection against hash-based lateral movement.

Domain controllers store NTLM hashes for all domain accounts in the NTDS.dit database, creating catastrophic single points of failure. Workstations and servers cache NTLM hashes for recently logged-in users in LSASS memory, turning every endpoint into a credential repository. The operational consequence: administrative login to any system exposes those credentials to theft from memory.

Service accounts amplify pass-the-hash impact because their hashes remain static until manual password rotation. Local administrator accounts with identical passwords across systems create lateral movement highways—one compromised hash unlocks hundreds of machines simultaneously.

The attack sequence follows predictable patterns: gain initial workstation access, dump LSASS memory to extract hashes, identify administrative account hashes, then authenticate to additional systems using stolen credentials. Remote Desktop Protocol, SMB file shares, Windows Management Instrumentation, and PowerShell remoting all accept NTLM authentication, providing multiple attack vectors for hash replay.

Business impact

Pass-the-hash transforms single workstation breaches into enterprise-wide compromises within hours. Administrative hashes stolen from one endpoint enable authentication to domain controllers, file servers, and databases across the network. The attack bypasses multi-factor authentication because hash replay occurs after initial authentication, rendering MFA useless for lateral movement.

Ransomware deployment becomes trivial when attackers possess administrative hashes for simultaneous system access. Recovery complexity multiplies because determining breach scope requires extensive forensics to trace which systems were accessed using stolen credentials versus legitimate authentication.

Data exfiltration accelerates when stolen hashes grant direct access to file shares and database servers. Regulatory violations follow when organizations cannot determine the scope of unauthorized access, potentially triggering breach notification failures under GDPR, HIPAA, and state privacy laws.

Detection guidance

Monitor NTLM authentication events to identify hash replay attempts. Focus on authentication patterns that deviate from normal user behavior: logins from unfamiliar source IPs, authentication to systems users don't normally access, or rapid authentication sequences suggesting automated tools.

# Logic pattern / pseudocode — validate for your platform
# Detect NTLM authentication from workstations to servers outside normal patterns
source="windows_security_logs" EventCode=4624 
| where LogonType=3 AND AuthenticationPackageName="NTLM" 
| where SourceWorkstation!="-" AND TargetServerName!="localhost"
| stats count by Account, SourceWorkstation, TargetServerName, hour
| where count > 10 OR TargetServerName matches unusual_servers

LSASS process access events indicate credential dumping attempts. Sysmon Event ID 10 captures process access operations targeting LSASS, which attackers use to extract password hashes.

# Logic pattern / pseudocode — validate for your platform
# Detect suspicious LSASS memory access
source="sysmon" EventCode=10 TargetImage="*lsass.exe"
| where GrantedAccess in ("0x1010", "0x1038", "0x143a") 
| where SourceImage!="C:\Windows\System32\*"
| stats count by SourceImage, SourceProcessId, Computer

Combine network logon events with NTLM authentication to identify lateral movement. Look for Type 3 logons using NTLM authentication originating from workstations to multiple servers within short time windows.

# Logic pattern / pseudocode — validate for your platform
# Correlate rapid lateral movement using NTLM
source="windows_security_logs" EventCode=4624 LogonType=3 AuthenticationPackageName="NTLM"
| bucket _time span=1h 
| stats dc(Computer) as target_count by Account, IpAddress, _time
| where target_count > 5

Monitor for credential access tools in process creation logs. Tools like Mimikatz, ProcDump, and Cobalt Strike beacons create distinctive process execution patterns when dumping credentials.

# Logic pattern / pseudocode — validate for your platform
# Detect credential dumping tools
source="sysmon" EventCode=1
| where (Image="*mimikatz*" OR CommandLine="*sekurlsa*" OR 
 CommandLine="*procdump* -ma * lsass*" OR
 CommandLine="*comsvcs.dll MiniDump*")
| table _time, Computer, Image, CommandLine, ParentImage

Mitigation strategies

Disable NTLM authentication where Kerberos can replace it. Start with internal systems and gradually expand to reduce the attack surface for hash replay. Operational complexity during the transition trades off against eliminating the fundamental vulnerability that enables pass-the-hash attacks. Note that because NTLMv2 authentication can be relayed even without hash extraction, eliminating NTLM entirely—rather than simply upgrading to NTLMv2—is the more complete defense.

Deploy Local Administrator Password Solution (LAPS) to randomize local administrator passwords across all systems. LAPS prevents lateral movement using shared local administrator credentials by ensuring each system has a unique password stored in Active Directory. Shared local admin passwords create attack highways—LAPS builds roadblocks at every system.

Enable Windows Defender Credential Guard on Windows 10 and Windows Server 2016 or later. Credential Guard uses virtualization-based security to isolate credentials from the main operating system, preventing direct memory access to NTLM hashes. The technology requires compatible hardware and breaks some legacy applications that directly access LSASS memory.

Implement Restricted Admin mode for RDP connections to prevent credentials from being sent to remote systems during administrative sessions. This reduces hash exposure but requires modern Windows versions and breaks legacy applications that expect full credential delegation.

Configure NTLM authentication auditing to log all NTLM usage across the domain. Set the "Network Security: Restrict NTLM: Audit NTLM authentication in this domain" policy to identify systems still using NTLM before disabling it. This visibility enables gradual NTLM elimination without breaking critical services.

Rotate service account passwords regularly and use managed service accounts where possible. Managed service accounts automatically handle password rotation, reducing the persistence of stolen hashes. Manual rotation schedules fail under operational pressure—automation prevents credential staleness.

Deploy Protected Process Light (PPL) for LSASS to prevent unauthorized access to credential memory. PPL requires additional privileges for processes to access LSASS, blocking many credential dumping tools. The protection stops common attack tools but sophisticated attackers can bypass PPL with kernel-level access.

Getting started checklist

Immediate actions:
- [ ] Enable NTLM authentication auditing on domain controllers to identify current usage patterns
- [ ] Deploy LAPS to randomize local administrator passwords across all Windows systems
- [ ] Configure Sysmon to capture process access events targeting LSASS (Event ID 10)
- [ ] Create detection rules for NTLM authentication anomalies in your SIEM

First 30 days:
- [ ] Inventory systems still requiring NTLM authentication and develop migration plans
- [ ] Enable Credential Guard on all compatible Windows 10 and Server 2016+ systems
- [ ] Implement Restricted Admin mode for RDP connections where supported
- [ ] Rotate all service account passwords and document rotation schedules

First 90 days:
- [ ] Begin disabling NTLM on internal systems starting with non-critical applications
- [ ] Deploy Protected Process Light (PPL) for LSASS on high-value systems
- [ ] Implement managed service accounts to automate password rotation
- [ ] Test Kerberos-only authentication in isolated network segments

Ongoing:
- [ ] Monitor NTLM authentication logs for unexpected usage patterns
- [ ] Review and update service account password rotation procedures quarterly
- [ ] Validate Credential Guard deployment status during system audits
- [ ] Assess progress toward NTLM elimination monthly

Sources