Pass-the-Hash

What is Pass-the-Hash?

Pass-the-Hash (PtH) is an attack technique where an attacker logs in to another system with the hash of a Windows password, without ever cracking that password. It works because NTLM, the old Windows authentication protocol, verifies with the hash under the hood and not with the password itself. Whoever holds the hash logs in as if they were that user.

MITRE ATT&CK tracks the technique as T1550.002, part of Use Alternate Authentication Material. Pass-the-Hash skips the step that asks for a readable password and goes straight to the part of authentication that uses the hash. The technique has existed since 1997, when Paul Ashton published a modified Samba client that accepted hashes instead of passwords. Today it shows up in nearly every Active Directory pentest.

How does it work?

Windows does not store a password as plaintext. It stores a hash. The NT hash is an MD4 hash of the password in UTF-16 LE, without a salt. That missing salt is the whole point. There is no per-user variation, so two identical passwords always produce the same hash, on every machine and in every session. The hash is a fixed key that keeps working until the password changes.

During NTLM authentication, the client does not send a password. It sends an answer to a challenge from the server, computed from the hash. Anyone who holds the hash reproduces that answer without ever knowing or cracking the password. A stolen NT hash is in practice just as valuable as the password itself.

That hash comes from three places. On a workstation where an administrator has just logged in, their hash sits in LSASS memory, and attackers pull it out with tools like Mimikatz or Lsassy. On a system without active sessions, the hashes of local accounts live in the SAM database. On a domain controller, all of the domain’s hashes live in the NTDS.dit. Pass-the-Hash works against NTLM, not directly against Kerberos. For Kerberos there are the Overpass-the-Hash and Pass-the-Ticket variants, where the NT hash serves to request a Kerberos ticket.

Pass-the-Hash in a pentest

Once we have a hash, we try it across the rest of the network with NetExec. Against a local account we use --local-auth, against a domain account we drop that flag.

# Try a local admin hash against a whole range. (Pwn3d!) means local admin
nxc smb 10.0.0.0/24 -u administrator -H 32ed87bdb5fdc5e9cba88547376818d4 --local-auth

# Or within the domain, with a domain account
nxc smb 10.0.0.0/24 -u jdoe -H 32ed87bdb5fdc5e9cba88547376818d4 -d acme.local

# If we find admin rights, immediately run a command on every host where the hash works
nxc smb 10.0.0.0/24 -u administrator -H 32ed87bdb5fdc5e9cba88547376818d4 --local-auth -x "whoami"

NetExec’s -H accepts the NT hash directly. If you prefer to work with Impacket, it wants the full hash pair LMHASH:NTHASH, with the LM half left empty.

# Impacket: an interactive shell via Pass-the-Hash, empty LM half
psexec.py -hashes :32ed87bdb5fdc5e9cba88547376818d4 acme.local/[email protected]

One workstation is usually enough to start. The hash of a logged-in administrator sits there in LSASS, and with that hash we log in to other machines where the same administrator has rights. On each new machine we read LSASS again, for example with NetExec’s Lsassy module (-M lsassy), and grab the hashes of the users logged in there. Step by step we work our way up until we reach a domain admin. At that point the whole domain is ours.

What makes Pass-the-Hash attractive to an attacker is that the obvious alarms stay quiet. We do not guess passwords, so there are no failed logins and no account lockouts. We only replay an existing hash. It is not invisible, though. An environment with decent logging, an EDR, or an MDR service spots LSASS being read and the unusual NTLM logons (LogonType 3) just fine. Whether it stands out mostly depends on whether anyone is watching.

How do you prevent Pass-the-Hash?

You can only fully disable Pass-the-Hash by retiring NTLM, and in a network that has grown over the years that is rarely feasible. You can still break the chain an attacker walks through in several places.

• LAPS (or Windows LAPS) gives each workstation a unique, random local admin password. One cracked machine then no longer grants access to the rest, because that hash does not work there. That removes the classic problem where every workstation built from the same image shares the same local admin hash.
• A tiering model keeps privileged accounts away from workstations. A domain admin belongs on a domain controller, not on a laptop, so that their hash never ends up in the memory of a less trusted machine.
• Credential Guard isolates the NTLM hashes and Kerberos tickets in a hardware-protected part of Windows, separate from LSASS. Note that it does not protect the SAM of local accounts, which is why you still need LAPS alongside it.
• Restricting NTLM through the GPO “Network security: Restrict NTLM” removes the protocol that Pass-the-Hash abuses. Start in audit mode, review the event log, and build up exceptions before you enforce. The Protected Users group blocks NTLM for its members, but it can lock accounts out, so test before you add it to admin accounts.
• Monitoring catches what prevention misses. An EDR or SIEM that correlates LSASS access with unusual NTLM logons sees the chain where a single isolated event looks harmless.

Two commonly suggested fixes do not work here. Rotating passwords only stops the old hash. The new one is ready again right away as long as the compromised machine has not been cleaned up. And MFA does not help, because NTLM has no second factor at the protocol level, so hash replay goes right past it. In practice, a layered approach with tiering and LAPS at its core prevents by far the most incidents.