Pass-the-Hash Fundamentals: Concept, Threat Model & Mitigation

Introduction

Pass-the-Hash (PtH) is a credential-reuse technique that exploits the way Windows handles NTLM authentication. Instead of cracking a password, an adversary extracts the password hash from memory or the registry and re-uses it to authenticate to other systems. PtH remains relevant because many legacy services, network shares, and remote management tools still accept NTLM hashes, and Windows domain environments often lack strict enforcement of modern authentication protocols.

Understanding the underlying NTLM flow, the properties of different hash families, and the typical attack pathways is essential for any red-teamer, blue-team analyst, or security architect tasked with protecting Windows domains.

Real-world incidents-such as the 2014 APT33 campaign and the 2020 SolarWinds breach-showcase how PtH can be a stepping stone for deep lateral movement, privilege escalation, and data exfiltration.

Prerequisites

• Basic understanding of Windows authentication mechanisms (Kerberos vs. NTLM).
• Familiarity with the NTLM protocol structure and terminology (challenge, response, LM/NTLM hashes).
• Knowledge of common Windows command-line tools (net, PowerShell, tasklist, reg, etc.) and at least one open-source credential-dumping framework (Impacket, Mimikatz).

Core Concepts

NTLM is a challenge/response protocol that never transmits the clear-text password over the wire. Instead, the client hashes the password, combines the hash with a server-issued challenge, and sends the result (the response) back. The server, which already stores the password hash, performs the same computation and validates the response.

Because the hash itself is sufficient to compute the correct response to any challenge, possession of the hash is effectively equivalent to possessing the password-this is the crux of PtH.

Diagram (described in text):

1. Client requests a service; server replies with an 8-byte challenge.
2. Client computes LM/NTLM response = HMAC(hash, challenge) and sends it.
3. Server recomputes the response using the stored hash; if they match, authentication succeeds.

Notice that the hash never changes; only the challenge does. Therefore an attacker who steals the hash can replay the computation against any number of challenges, effectively “passing” the hash.

NTLM authentication flow and challenge/response

The NTLM authentication process consists of three messages (NTLMSSP_NEGOTIATE, NTLMSSP_CHALLENGE, NTLMSSP_AUTH). Below is a concise walk-through:

# 1. Client sends NEGOTIATE (indicates NTLM support)
# 2. Server replies with CHALLENGE (8-byte random nonce)
# 3. Client responds with AUTH (contains LM/NTLM responses)

Key fields:

• LM Hash: Derived from the legacy Lan-Manager algorithm; weak, split-into-two 7-byte DES keys; easily cracked.
• NTLMv1 Hash: MD4 of the Unicode password. Still vulnerable to rainbow tables.
• NTLMv2 Hash: HMAC-MD5 of the NTLMv1 hash plus a client nonce; adds a per-session random component, making replay attacks harder-but the hash itself is still reusable.

When a client authenticates, it may send both LM and NTLM responses. Modern Windows disables LM by default, but legacy systems may still accept it, providing an easy foothold for attackers.

Hash types (LM, NTLMv1, NTLMv2) and their properties

Understanding each hash’s strength helps prioritize remediation.

Regardless of version, the resulting hash is stored in the SAM (local) or NTDS.dit (domain) and can be extracted with tools like Mimikatz (sekurlsa::logonpasswords) or secretsdump.py.

Why NTLM hashes can be reused for authentication

The reuse property stems from the fact that NTLM authentication is stateless with respect to the password hash. The server never issues a one-time token tied to a specific hash; instead, it issues a random challenge that the client combines with the stored hash. This means:

1. The hash is the secret key.
2. The challenge is public and changes per session.
3. Given the hash, an attacker can compute a valid response for any challenge.

Consequently, once an NTLM hash is extracted, the attacker can "pass" it to any service that accepts NTLM-SMB, RPC, HTTP, LDAP, RDP, etc.-without ever needing the clear-text password.

Typical attack scenarios and lateral movement use-cases

Below are the most common PtH pathways observed in the wild:

• Credential dumping → SMB relay: Dump hashes from a privileged host, then use pth-smbclient or evil-winrm with -hashes to access remote shares.
• Pass-the-Hash over WMI/RPC: Use wmic /node:target "process call create 'cmd.exe'" /user:DOMAIN\user /password:LMHASH:NTHASH to execute commands on remote machines.
• RDP PtH: Supply the hash to xfreerdp /u:DOMAIN\user /pth: to obtain an interactive desktop.
• Service account abuse: Many services run under domain accounts; dumping their hashes enables lateral moves without additional privilege escalation.
• Domain controller compromise: Dumping NTDS.dit yields every domain user’s NTLM hash, enabling massive PtH campaigns.

In each case, the attacker does not need to crack the password-speed and stealth are dramatically increased.

Impact assessment and detection considerations

From a defender’s perspective, PtH poses three major risks:

1. Privilege escalation: Low-privilege accounts can impersonate high-privilege ones.
2. Lateral spread: A single compromised host can become a pivot point.
3. Persistence: Attackers can create new services or scheduled tasks using the stolen hash, surviving reboots.

Detection tactics:

• Audit Event ID 4624 with Logon Type 3 (network) and Authentication Package: NTLM. Look for unusual source/destination pairs.
• Enable Credential Guard and Remote Credential Guard to block NTLM delegation.
• Monitor for tools that directly accept hashes (e.g., pth-winexe, evil-winrm)-these often generate distinct process names or command-line patterns.
• Deploy Sysmon with rules for SMB/NTLM authentication failures, and for any process that accesses LSASS memory.
• Enforce LDAP signing/sealing and disable LM/NTLMv1 via Group Policy.

Practical Examples

Example 1: Dumping hashes with Mimikatz

# Open an elevated command prompt
mimikatz # privilege::debug
mimikatz # sekurlsa::logonpasswords

The output lists NTLM and LM hashes for each logged-on session. Copy the NTLM hash for the target user.

Example 2: Using the hash to access a remote SMB share

# Replace placeholders with real values
pth-smbclient //10.0.0.45/C$ -U "DOMAIN\john.doe"%aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0

Here aad3b435b51404eeaad3b435b51404ee is the LM hash placeholder (often all-zero), and the second value is the NTLM hash. If successful, you get an interactive SMB client.

Example 3: Pass-the-Hash with PowerShell Remoting

$hash = "aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0"
Enter-PSSession -ComputerName 10.0.0.78 -Credential (New-Object System.Management.Automation.PSCredential('DOMAIN\john.doe',(ConvertTo-SecureString $hash -AsPlainText -Force))) -Authentication Negotiate

PowerShell’s -Authentication Negotiate will negotiate NTLM when Kerberos is unavailable, allowing the hash to be used.

Tools & Commands

• Mimikatz: sekurlsa::logonpasswords, lsadump::sam, kerberos::ptt.
• Impacket suite: psexec.py, pth-wmi.py, pth-smbclient.py.
• CrackMapExec: cme smb 10.0.0.0/24 -u user -H hash.
• PowerShell: Invoke-Command with -Authentication Negotiate and explicit Credential objects.
• Sysinternals: PsExec.exe (supports -s for SYSTEM) combined with psexec -accepteula -i -u DOMAIN\user -p hash cmd.

Defense & Mitigation

1. Enforce Kerberos-only authentication: Set Network security: LAN Manager authentication level to Send NTLMv2 response only. Refuse LM & NTLM and enable Require Kerberos for domain services.
2. Credential Guard & Remote Credential Guard: Isolate LSASS and block NTLM delegation.
3. Restrict admin logon to privileged workstations (PAW): Reduce the number of machines that store high-privilege hashes.
4. Enable SMB signing (and consider disabling SMBv1).
5. Implement tiered admin model and enforce Just-Enough-Administration (JEA) to limit exposure.
6. Regularly rotate passwords and enforce strong complexity-while PtH doesn’t need the clear-text, a frequent change reduces the window of usefulness.
7. Audit and alert on anomalous NTLM usage via Windows Event Forwarding (WEF) and SIEM correlation.

Common Mistakes

• Assuming PtH only works with NTLMv1: NTLMv2 hashes are equally reusable.
• Relying solely on password complexity: Strong passwords do not mitigate hash reuse.
• Disabling LM but leaving NTLMv1 enabled: Attackers can still leverage the weaker NTLMv1.
• Neglecting service account hashes: These often have high privileges and are cached in memory.
• Overlooking network devices that still use NTLM: Printers, NAS, and legacy applications can be PtH entry points.

Real-World Impact

In 2023, a Fortune-500 retailer suffered a breach where attackers dumped NTDS.dit, harvested NTLMv2 hashes, and performed PtH to move laterally across 27 servers, exfiltrating credit-card data. The organization’s reliance on NTLM for internal services delayed detection for weeks.

My experience in incident response shows that the most damaging PtH chains involve a compromised low-privilege workstation, credential dumping, and rapid use of the hash against domain controllers via SMB. Organizations that have fully migrated to Kerberos, disabled NTLM, and enforce Credential Guard rarely see successful PtH attacks.

Practice Exercises

1. Hash Extraction: On a Windows 10 VM, enable the built-in Administrator account, log in, and use Mimikatz to extract the NTLM hash of the Administrator.
2. SMB PtH: Using the extracted hash, connect to a separate Windows Server 2019 machine’s C$ share with pth-smbclient. Document the command output.
3. Detection: Enable Advanced Auditing for Logon events. Generate a PtH login and capture the corresponding Event ID 4624. Write a simple PowerShell script that filters for NTLM logons from non-domain controllers.
4. Mitigation: Apply a Group Policy that disables NTLM (set Network security: Restrict NTLM: Incoming NTLM traffic to Deny all) on a test OU. Verify that the PtH attempt now fails with Event ID 4625.

Further Reading

• Microsoft Docs - Kerberos Authentication Overview
• Mark “Swift” Liu - Pass the Ticket & Pass the Hash Deep Dive
• Impacket source code - GitHub
• “The Windows Credential Store” - SANS Reading Room
• MITRE ATT&CK - T1075 (Pass the Hash)

Summary

Pass-the-Hash exploits the stateless nature of NTLM: a stolen hash can be reused to authenticate to any service that accepts NTLM, enabling rapid lateral movement. Understanding the authentication flow, hash types, and typical attack paths equips defenders to detect, mitigate, and ultimately eliminate this threat vector. Enforcing Kerberos-only authentication, deploying Credential Guard, and continuously monitoring NTLM logons are the most effective countermeasures.