Pass-the-hash

NTLM authentication never sends the password. The server issues a challenge, the client computes a response using the NT hash of the password, and the server verifies it against the hash it holds. Nowhere in that exchange does anyone need the plaintext. If an attacker has the hash, they can compute the response, and the server accepts them.

This is not a flaw in an implementation. It is what a challenge-response protocol built on a stored hash means. The consequence is the part that surprises people: the hash is not a protected form of the password, it is a password equivalent, and it should be handled with exactly the same care.

Getting the hash requires local administrator rights on a machine where the account has authenticated, which is what credential dumping means in practice. The material sits in the memory of the local security authority process, in the local account database for local accounts, or in credential caches. Once an attacker holds it, they use it against any system that accepts NTLM and where that account has rights.

The variants matter because the fixes differ. Pass-the-hash uses the NT hash against NTLM. Pass-the-key uses the same material to obtain a Kerberos ticket instead, which produces normal-looking Kerberos activity and is what an attacker chooses in an estate that monitors NTLM. Pass-the-ticket steals an already-issued Kerberos ticket and replays it, needing no hash at all.

The single condition that makes this the fastest movement technique in a Windows estate is credential reuse. One local administrator password baked into an image, cloned across every workstation, produces one hash that authenticates to all of them. We take it from the first machine we compromise and we have the estate, without escalating anything, without cracking anything, and without a single failed login.

The second condition is where privileged credentials land. A domain administrator who opens a remote session to a compromised workstation leaves material on that workstation. So does a service running under a privileged account, a scheduled task, and a support engineer connecting to help a user. The attacker does not need to reach the domain controller; they need to wait on a machine the administrator will visit. On engagements we routinely compromise an ordinary workstation and then simply wait, and the estate comes to us.

The third is that it is quiet. A successful authentication with a valid credential produces a successful logon event, which is the most common event in the estate. There is no failure to alert on and no malware to detect. What distinguishes it is context that a rule has to be written for: this account, on this machine, at this hour, when it has never done that before.

The reason the technique survives twenty-five years after it was described is that removing NTLM entirely breaks things. Estates keep it enabled for a handful of applications, and a handful is enough.

These three are used interchangeably in incident reports and they need different responses.

The row worth reading twice is the last one. Resetting a compromised account’s password invalidates the hash immediately, and does nothing to a ticket already issued. Incident response that resets passwords and declares the account clean, without accounting for ticket lifetime, leaves the intruder authenticated.

Believing a password change fixes everything. It invalidates the hash. Issued tickets survive, and so does any other credential the same intrusion collected.

Using the same local administrator password across an image. This is the precondition. Randomised per-host passwords remove the technique’s main value in a single change.

Letting administrators log on interactively to ordinary workstations. Every such session leaves material on a machine that is easier to compromise than anything the administrator is protecting.

Assuming Kerberos-only estates are immune. They are immune to pass-the-hash and not to pass-the-ticket or to overpass-the-hash, which use the same stolen material through a different protocol.

Treating it as a malware problem. No malicious binary is required. The technique is a protocol being used as specified, with a credential the attacker holds.

The structural fix is to stop the same credential being valid in two places. Randomise local administrator passwords per host so a recovered hash is worth exactly one machine. Then decide where privileged credentials are allowed to appear: administrative accounts that cannot log on to workstations, dedicated administrative machines, and remote sessions that do not leave reusable material on the target. That last point is what the restricted administration mode for remote desktop exists for.

Protect the material at rest and in memory. Credential Guard isolates the secrets from the operating system in supported configurations. The Protected Users group prevents the caching that makes several of these techniques work. Both are effective and both need testing against real workloads before a wide rollout.

Reduce NTLM deliberately: audit where it is still used, which the operating system will tell you, retire the applications that require it, and restrict it by policy rather than switching it off estate-wide on a Friday.

For detection, the useful signals come from correlation rather than from any single event. An account authenticating from a machine it has never used. A local account authenticating over the network, which in a well-run estate should be rare. Authentication to many hosts in a short window from one source. And explicit-credential logon events on hosts where nobody should be doing that. These are the patterns that make lateral movement visible when the individual events look perfectly normal.

In an internal report, pass-the-hash is written as the movement step it is, inside a path: this is where we obtained the material, this is what the material was, this is where it was valid, and this is what that reached. Written as an isolated finding it is close to meaningless, because the technique is not the problem. Credential reuse and credential exposure are the problem.

The evidence is the account, the source host, the destination hosts where it was accepted, and the timestamps, so the client can locate their own events. Hash values are not printed in the report body.

Severity is decided by reach. A local account hash valid on one machine is an observation. The same hash valid on four hundred machines is critical before it is used for anything, and the finding is written against the image and the process that produced it, not against the machine we happened to start on. Where the recovered material belonged to an account with rights over the directory, the finding is written as full domain compromise with the path shown.

Recovering and reusing credential material is a routine part of testing what an attacker reaches from a single foothold.

Is pass-the-hash still possible in 2026? Yes. It is a property of NTLM rather than a bug, and NTLM remains enabled in most Windows estates for compatibility. Credential Guard, the Protected Users group and per-host local administrator passwords reduce it substantially, and few estates have all three everywhere.

Do you need to crack the hash? No, and that is the point. The protocol proves knowledge of the hash, so the hash is sufficient. Cracking is only needed when the plaintext itself is required, for example to authenticate somewhere that does not accept NTLM.

Does multi-factor authentication stop it? Not for this path. Multi-factor authentication applies to interactive sign-in flows; NTLM authentication between machines does not present a second factor, which is why network-level movement is unaffected by a policy that covers the front door.

What single change helps most? Randomising the local administrator password on every host. It is a well-supported change, it does not break workflows, and it converts the estate-wide version of this attack into a single-machine one.