Pass the Hash Explained: Authenticating Without the Password

Pass-the-hash is the attack that made a generation of defenders realise their password policy was solving a different problem than they thought. You can require thirty-character passwords rotated weekly, and none of it matters to an attacker holding the hash, because the hash is what NTLM actually authenticates with. The plaintext password is a detail the protocol never asks for once it has the derived value.

That single fact reshapes how lateral movement works inside a Windows domain. An attacker who compromises one machine and lifts the hashes stored on it can reuse those hashes to log in elsewhere as the users they belong to, spreading across the network one credential at a time. The defense is not a stronger password. It is stopping the hash from being stolen, and stopping a stolen hash from being reusable where it matters.

Why the hash is enough

When an account authenticates with NTLM, the protocol proves knowledge of the account's password hash, not the password itself. The client uses the hash to answer the server's challenge. At no point does the plaintext password enter the exchange. This is a deliberate design that avoids sending or storing plaintext, and for decades it was considered a reasonable trade.

The consequence is that anyone who possesses the hash can complete the authentication just as the real user would. There is nothing to crack. The hash is a password-equivalent. Feed it into a client that supports NTLM authentication and you become that user for every service that accepts NTLM. This reuse is what MITRE ATT&CK T1550.002 describes.

Where the hashes come from

Pass-the-hash is the second half of a two-step story. First the attacker has to steal hashes, which they do from a machine they already control. The common sources:

Source	What it holds	ATT&CK
LSASS process memory	Hashes and secrets of logged-on users	T1003.001
Local SAM database	Local account hashes on the machine	T1003.002
Cached domain credentials	Hashes for domain users who logged on before	T1003.005
Credential material on disk	Secrets left by services or backups	T1003

Every one of these requires the attacker to already have significant access on the machine, usually local administrator. That is an important framing for defense. Pass-the-hash is a lateral-movement and escalation technique, so the goal is to ensure that landing on one machine does not surrender the hashes that unlock the rest.

Why reuse works so widely

Two properties of Windows environments make a stolen hash valuable across many machines.

The first is shared local accounts. If every workstation is built from the same image with the same local administrator password, they all share the same local hash. Steal it once and it authenticates to every machine in the fleet. This turns a single foothold into fleet-wide access with no additional theft.

The second is flat administrative access. In many networks the same privileged accounts are used to manage everything, from the lowest workstation to the domain controllers. When a high-privilege account touches a low-trust machine, its hash becomes exposed to whatever compromises that machine later. The privilege that made the account useful is exactly what makes its stolen hash catastrophic.

How Credential Guard changes the picture

The classic hash theft targets LSASS memory, where secrets of logged-on users sit. Credential Guard moves those secrets out of ordinary reach. It uses virtualization-based security to isolate the secrets in a protected memory space that the normal operating system, and therefore normal dumping tools, cannot read. Even an attacker with administrator rights on the running system does not have a straightforward path to the isolated secrets. Microsoft's Credential Guard documentation explains the isolation model.

Credential Guard does not make hash theft impossible in every scenario, and it does not protect local SAM hashes or every credential type. What it does is remove the easiest and most common source of freshly stolen domain hashes, which raises the cost of the whole technique.

A complementary strategic control is reducing the domain's reliance on NTLM at all. Recent Windows versions provide auditing that shows where NTLM is still in use, along with policies to restrict it. Every service moved to Kerberos is one fewer place a stolen NTLM hash can be spent directly. Retiring NTLM is a long project in most environments, but the auditing data alone is useful, because it reveals which systems still depend on the protocol that makes hash replay work.

How tiering breaks the cascade

The structural fix for pass-the-hash is administrative tiering. The idea is to define levels of trust and forbid credentials from crossing downward into less trusted territory.

In a tiered model, the accounts that manage domain controllers and identity infrastructure are used only on hardened administrative systems, never on ordinary workstations. Workstation and server administration use separate accounts that have no power over the tier above them. Because a domain-admin hash never lands on a user workstation, compromising that workstation cannot expose it. The cascade that turns one foothold into domain compromise is cut, because the credential that would enable it is never present where the attacker can reach it.

Tiering is organisational work more than a product setting, and it is the control that most reliably contains pass-the-hash at scale.

The overpass-the-hash variant

There is a closely related technique that starts from the same stolen hash and reaches further. Instead of replaying the hash directly through NTLM, an attacker can use the stolen hash to obtain a Kerberos ticket-granting ticket for the account, then operate through Kerberos as that user. This is often called overpass-the-hash or pass-the-key, and it matters for defenders because it means a stolen hash is not confined to NTLM-based access. It can be laundered into a Kerberos identity and used against services that only accept Kerberos.

The practical takeaway is that the controls which limit NTLM alone do not fully contain a stolen hash. The durable answer is still to protect the hash from theft and to constrain where privileged accounts appear, because both NTLM replay and the Kerberos-laundered path depend on possessing a credential that should never have been reachable in the first place. Once the ticket exists, the exposure overlaps with pass-the-ticket, which is why these techniques are usually studied together.

How to detect and defend against pass-the-hash

Defense is a stack: stop the theft, stop the reuse, and watch for the reuse that gets through.

Stop the theft.

1. Enable Credential Guard on supported systems to isolate the secrets attackers usually dump from memory.
2. Keep privileged accounts off low-trust machines. Every logon deposits reusable material, so a domain admin should never interactively log on to a workstation.

Stop the reuse.

3. Randomise local administrator passwords per machine with a tool that manages unique local passwords, so a stolen local hash unlocks exactly one host instead of the fleet.
4. Block network logon for local accounts so a stolen local hash cannot be used to authenticate remotely to other machines.
5. Implement admin tiering so privileged credentials never appear where lower-trust compromise can reach them.

Detect the reuse.

6. Watch for logons using explicit credentials, where a session on one host launches an authentication as a different account, a common footprint of hash reuse during lateral movement.
7. Alert on local accounts authenticating over the network, which should be rare and is a strong reuse signal.
8. Flag privileged accounts logging on to hosts they never normally touch, especially many hosts in quick succession, which is the lateral spread pattern.

A worked walkthrough of lateral movement

Following the technique end to end shows why a single compromised machine can unravel a whole domain, and why the defenses target specific links in that chain.

The attacker starts with code execution and administrative rights on one machine. That first foothold might come from a phishing payload, an exploited service, or a stolen local credential. The important property is administrative access on that host, because reaching the stored secrets requires it.

The next step is harvesting. The attacker dumps the credential material available on the machine: the hashes of users currently logged on, held in process memory, plus any local account hashes in the local database and any cached domain credentials from prior logons. Each of these is catalogued as a credential-access technique, and together they give the attacker a set of password-equivalent hashes belonging to every identity that has touched the machine.

The attacker then triages the haul. A hash for another ordinary user is a sideways step. A hash for an account with administrative rights on other machines is a lever for expansion. A hash for a domain administrator is the jackpot, because it authenticates everywhere. The value of the foothold is defined entirely by whose hashes were sitting on it.

With a useful hash chosen, the attacker performs the replay. They feed the hash into a tool that speaks NTLM and authenticate to a remote machine as the owning user, with no plaintext and no cracking involved. If the account has rights on that remote machine, the attacker now has a second foothold, and the cycle repeats: harvest the hashes present on the new machine, pick the most powerful, replay again. Each hop can surface fresh credentials, and a domain administrator hash encountered anywhere along the way collapses the remaining distance to full control.

The escalating version of this loop is what turns a single infected workstation into domain compromise within a short span. Nothing in the loop cracks a password. The whole chain runs on reusing secrets that were reachable where they should never have been.

Detection signals

Because the authentication itself is valid, detection looks for the shape of reuse rather than a malformed request.

• Logons with explicit credentials. An interactive session on one host that spawns an authentication as a different account is a common footprint of replaying a stolen hash during lateral movement. Baselining which accounts normally do this makes the anomalies stand out.
• Local accounts authenticating over the network. A local account, especially a local administrator, authenticating remotely to another machine should be rare in a healthy environment. It is a strong indicator that a stolen local hash is being reused across the fleet.
• Privileged logons on unusual hosts. A domain administrator appearing on a workstation it has no operational reason to touch, particularly several hosts in quick succession, is the lateral-spread pattern.
• NTLM authentication where Kerberos is expected. A rise in NTLM authentication to systems that normally use Kerberos can indicate tooling that defaults to NTLM replay.
• Authentication from hosts that never initiate it. A machine that suddenly originates authentications to many other machines, outside any management workflow, may be an attacker pivoting through it.

Each signal has benign causes, so the value is in correlation. A local administrator authenticating over the network, to a host it has never touched, shortly after that host logged an explicit-credential logon, is a far stronger story than any one event alone.

How the technique evolved

Pass-the-hash is old, and it endured because its root cause is a protocol design that treats the hash as the secret. The response has been layered rather than singular. Randomising local administrator passwords per machine removed the shared-hash shortcut that let one stolen local credential unlock an entire fleet. Credential Guard used virtualization-based isolation to move the most commonly dumped secrets out of ordinary reach. Administrative tiering reshaped operations so that powerful credentials never appear on low-trust machines. Auditing tools made the lingering dependence on NTLM visible, which is the first step toward retiring it.

None of these eliminated the technique, because the protocol still authenticates with the hash. What they did was remove the easy sources of fresh hashes and cut the paths a stolen one can travel. The attack persists in environments that skipped this hardening, and it is far weaker in environments that applied it.

Pass-the-hash next to related techniques

The credential-reuse family shares a theme: authenticate with stolen material rather than a typed password. Naming the neighbours prevents applying the wrong defense.

Technique	Material reused	Protocol	Core defense
Pass the hash	NTLM password hash	NTLM	Credential Guard, per-machine local passwords, tiering
Overpass the hash	NTLM hash turned into a ticket	Kerberos	Protect the hash, tier admin access
Pass the ticket	An existing Kerberos ticket	Kerberos	Protect tickets, limit privilege
Kerberoasting	An offline-cracked service password	Kerberos	Managed or long service passwords
Golden ticket	The krbtgt key to forge tickets	Kerberos	Protect and rotate krbtgt

The row that matters most alongside pass-the-hash is overpass-the-hash, because it shows that the same stolen NTLM hash can be laundered into a Kerberos ticket and spent against services that only accept Kerberos. Controls that restrict NTLM alone do not fully contain a stolen hash, which is why protecting the hash from theft and constraining where privileged accounts appear are the durable answers.

Common misconceptions

The first misconception is that a strong password protects against pass-the-hash. It does not. NTLM authenticates with the hash, so once the hash is stolen, the length or complexity of the password behind it is irrelevant. The defense protects the hash and constrains its reuse, and password strength addresses a different attack.

The second misconception is that Credential Guard makes the environment immune. Credential Guard isolates the secrets most commonly dumped from memory, which removes the easiest source of fresh domain hashes. It does not protect local database hashes or every credential type, and it does not undo shared local passwords or flat administration. It is one strong layer in a stack.

The third misconception is that rotating passwords cleans up a compromise. Because the hash is what authenticates, an attacker who already holds a hash keeps their access until the password is actually changed, and a change only helps for accounts whose hashes were exposed. Rotation matters, and it has to be paired with removing the attacker's foothold and the machines where powerful credentials landed.

The fourth misconception is that pass-the-hash is a Windows-only curiosity with no modern relevance. Any environment that relies on NTLM authentication remains exposed, and NTLM lingers in many networks for compatibility. Until the last services move to Kerberos or are otherwise hardened, the replay path stays open.

Frequently asked questions

Does pass-the-hash require cracking the password?

No, and that is the point of the technique. NTLM authenticates with the password hash, so an attacker who holds the hash can complete the authentication exactly as the real user would. There is nothing to crack, which is why password length gives no protection once the hash is stolen.

How does the attacker get the hash in the first place?

From a machine they already control, usually with administrative rights. The common sources are the memory of the process that holds logged-on users' secrets, the local account database, and cached domain credentials from earlier logons. Pass-the-hash is the second half of the story, and credential theft is the first.

Does Credential Guard stop it completely?

Credential Guard isolates the secrets attackers usually dump from memory, which removes the easiest and most common source of fresh domain hashes. It does not protect local database hashes or every credential type, and it does not fix shared local passwords or flat administration. Treat it as a strong layer within tiering and per-machine local passwords rather than a complete cure.

How is overpass-the-hash different?

Overpass-the-hash starts from the same stolen NTLM hash and uses it to obtain a Kerberos ticket, then operates through Kerberos as that user. It reaches services that only accept Kerberos, which plain NTLM replay cannot. It shows why containing a stolen hash means protecting the hash itself rather than only restricting NTLM.

Why does randomising local admin passwords help so much?

If every machine shares the same local administrator password, they share the same local hash, and stealing it once unlocks the whole fleet. Giving every machine a unique, managed local password means a stolen local hash unlocks exactly one host. It turns a fleet-wide skeleton key back into a single door.

What is administrative tiering?

Tiering defines levels of trust and forbids credentials from crossing downward. Accounts that manage domain controllers are used only on hardened administrative systems and never on ordinary workstations. Because a domain-admin hash never lands where a low-trust compromise can reach it, the cascade that turns one foothold into domain compromise is cut at the source.

Can I detect pass-the-hash reliably?

You can detect the shape of reuse rather than the replay itself, since the authentication is valid. Logons using explicit credentials, local accounts authenticating over the network, and privileged accounts appearing on hosts they never normally touch are the strongest signals, and correlating them tells a far stronger story than any single event.

Pass-the-hash is a staple of intrusion sets that live inside Active Directory, because it converts one compromised host into a passkey for the next. You can review which actors rely on credential theft and reuse tradecraft in our Threat Groups directory, which helps you weigh whether Credential Guard rollout or tiering is the more pressing gap for the adversaries you face.

The lesson of pass-the-hash is that a password you never send is a password whose strength stops mattering the moment its hash is stolen. The controls that hold up protect the hash and constrain its reuse: isolate secrets with Credential Guard, give every machine its own local password, block local-account network logon, and tier your administration so no single foothold reaches the crown jewels. Then a stolen hash unlocks one machine instead of the domain.

Related guides

• Pass the Ticket Explained
• Kerberoasting Explained
• Lateral Movement Explained
• Windows Event IDs for Security