Pass-the-Hash has been around since the late 1990s, and I still see it work in modern engagements more often than I’d expect. It’s one of those techniques that keeps proving a simple point: if a network trusts a hash the same way it trusts a password, then stealing the password was never actually necessary. This guide breaks down how Pass-the-Hash works, how to practice it safely, and — just as importantly — how to defend against it.
What Is a Pass-the-Hash Attack?
Pass-the-Hash (PtH) is a technique where an attacker authenticates to a remote system or service using the NTLM hash of a user’s password, rather than the plaintext password itself. Windows authentication protocols like NTLM don’t require the plaintext password for authentication — they use the hash directly in the challenge-response process. That means if an attacker steals a password hash (say, from LSASS memory or a SAM database), they can use it to authenticate anywhere that hash is valid, without ever cracking it.
This is fundamentally different from password cracking — you never need to recover the plaintext to use the hash for authentication.
Why Pass-the-Hash Matters
PtH matters because it turns a single compromised host into a springboard for lateral movement across an entire network, especially in environments where local administrator passwords are reused across many machines — a shockingly common configuration in real-world networks. It’s also relevant because it demonstrates why “just changing the password” isn’t always a complete remediation: if the hash was captured and the account is reused elsewhere, the attacker’s window of opportunity can persist even after a partial cleanup.
How Pass-the-Hash Works: The Technical Breakdown
- An attacker gains initial access to a host, typically through phishing, an exploited service, or a misconfiguration.
- The attacker dumps password hashes from memory (LSASS) or a local SAM database using tools like Mimikatz or Impacket’s
secretsdump.py. - The attacker identifies where that hash is valid. This is usually the same account on other machines (common with shared local admin credentials) or a domain account with access elsewhere.
- The attacker authenticates to a target system using the hash directly, via tools that support NTLM authentication without needing the plaintext password.
- Once authenticated, the attacker has the same access the legitimate account holder would have — which, for a local admin account, often means full control of the target machine.
Step-by-Step Methodology for a Lab Pass-the-Hash Exercise
- Set up a lab environment with at least two Windows hosts sharing a local administrator account with the same password (a common real-world misconfiguration to practice against).
- Gain initial access to the first host in your lab (simulate this however fits your training scenario).
- Dump credentials from the compromised host using Mimikatz:
sekurlsa::logonpasswords
Purpose of this command: run inside a Mimikatz session, this pulls currently logged-on user credentials — including NTLM hashes — from LSASS memory, which is the data source most Pass-the-Hash attacks rely on. See our Mimikatz guide for a full breakdown of how this works.
- Alternatively, dump hashes remotely with Impacket’s secretsdump.py:
secretsdump.py labdomain/labuser:labpassword@10.0.0.20
Purpose of this command: it authenticates to the target host and extracts local SAM and domain-cached credential hashes remotely, without needing to drop any tooling onto the target machine directly.
- Use the captured NTLM hash to authenticate to a second lab host using crackmapexec:
crackmapexec smb 10.0.0.21 -u administrator -H <ntlm_hash>
Purpose of this command: the -H flag tells crackmapexec to authenticate using the supplied NTLM hash instead of a plaintext password, testing whether that hash is valid for the administrator account on the target host — this is the core Pass-the-Hash step. See our crackmapexec guide for more usage examples.
- If successful, use the authenticated session for further access, such as executing commands or dumping additional credentials from the newly reached host, continuing lateral movement.
- Document every hop, including which account and hash enabled each step, so the final report clearly shows the lateral movement chain.
Practical Example: Using the Hash with xfreerdp
Pass-the-Hash isn’t limited to SMB-based tools — RDP sessions can also be authenticated with a hash in certain configurations:
xfreerdp /v:10.0.0.22 /u:administrator /pth:<ntlm_hash>
Purpose of this command: it establishes an RDP session to the target using the NTLM hash for authentication instead of a plaintext password, demonstrating that PtH isn’t confined to SMB/WinRM-based lateral movement. More detail on this tool is available in our xfreerdp guide.
Useful Tools and Technologies
| Category | Tools |
|---|---|
| Credential dumping | Mimikatz, Impacket’s secretsdump.py |
| Hash-based authentication | crackmapexec, Impacket’s psexec.py/wmiexec.py, xfreerdp |
| AD context for target selection | BloodHound (to find where a compromised hash is actually valid) |
Common Mistakes and Troubleshooting Tips
- Assuming a hash works everywhere. PtH only works where that specific account (and its hash) is valid — always confirm which hosts share the compromised credential before attempting lateral movement.
- Ignoring NTLM restrictions. Some hardened environments enforce Restricted Admin mode differently or disable NTLM entirely in favor of Kerberos-only authentication, which can block PtH attempts.
- Confusing local vs. domain account hashes. A local administrator hash is only useful on hosts sharing that same local account and password — it won’t work against domain-only services.
- Not accounting for LAPS. If Local Administrator Password Solution (LAPS) is deployed, every machine has a unique, rotated local admin password, which defeats PtH’s core assumption of credential reuse.
- Overlooking detection risk. Repeated authentication attempts across many hosts using the same hash is a strong, well-known detection signature — pace lateral movement accordingly during stealth-focused engagements.
Security Risks and Defensive Recommendations
- Deploy LAPS (Local Administrator Password Solution) so every machine has a unique local admin password, eliminating the credential reuse PtH depends on.
- Enable Credential Guard on supported Windows versions, which helps protect LSASS memory from tools like Mimikatz.
- Restrict local administrator group membership and avoid unnecessary domain admin logons on lower-tier workstations.
- Use Restricted Admin mode carefully for RDP, and understand its interaction with PtH before relying on it as a mitigation.
- Monitor for NTLM authentication anomalies, such as a single account authenticating to many hosts in a short time window, or NTLM logons from unexpected source systems.
- Move toward Kerberos-only authentication where feasible, reducing reliance on NTLM across the environment.
Frequently Asked Questions
Q1: Do I need the plaintext password for a Pass-the-Hash attack? No — that’s the entire point of the technique. The NTLM hash itself is sufficient to authenticate, since Windows challenge-response authentication uses the hash directly.
Q2: Does changing the password stop a Pass-the-Hash attack? Yes, changing the password invalidates the old hash going forward, but if the attacker already has an active session or has moved laterally to other systems, a password change alone doesn’t undo that access.
Q3: Is Pass-the-Hash still effective against modern Windows environments? It can be, especially where local admin credentials are reused across machines and LAPS isn’t deployed — it’s less effective in environments with strong credential hygiene and Kerberos-only authentication.
Q4: What’s the difference between Pass-the-Hash and Pass-the-Ticket? Pass-the-Hash reuses an NTLM hash for authentication; Pass-the-Ticket reuses a captured Kerberos ticket (TGT or TGS) instead — both avoid needing the plaintext password, but they target different authentication protocols.
Q5: Does LAPS fully prevent Pass-the-Hash attacks? It significantly reduces the impact by eliminating local admin password reuse across machines, but it doesn’t address domain account hash reuse, so it should be paired with other controls like Credential Guard.
Q6: Can Pass-the-Hash be used against domain administrator accounts? Yes, if a domain admin’s hash is captured (for example, from a machine where they logged in and their session was cached), it can be reused the same way — which is why limiting where privileged accounts log in matters so much.
Q7: What’s the best single defensive control against Pass-the-Hash? Deploying LAPS for unique local admin passwords combined with Credential Guard to protect LSASS memory addresses both the credential reuse and the credential theft halves of the attack.
Conclusion
Pass-the-Hash is a reminder that authentication systems built around reusable secrets — even hashed ones — carry inherent risk if that secret is ever exposed. For penetration testers, it’s one of the most reliable lateral movement techniques once initial access and credential dumping succeed, and it’s a great technique to practice in a lab to understand just how far a single compromised local admin password can reach across a poorly segmented network. For defenders, LAPS, Credential Guard, and reducing unnecessary privileged logons remain the most effective ways to break the chain.
For the credential dumping techniques that feed into Pass-the-Hash attacks, see our Mimikatz guide, and for how this fits into a larger compromise chain, check out our Active Directory attack paths guide.
References: MITRE ATT&CK T1550.002 (attack.mitre.org), Impacket documentation, Microsoft LAPS and Credential Guard documentation.