HolyGhost logoHolyGhost
← cd ..
Analysis

Pass the Hash: Why Stealing the Password Is Optional

In Windows networks an attacker often does not need your password, just its hash. Here is how pass the hash works, why it powers lateral movement, and how to break the chain.

HolyGhost··9 min read

Imagine you keep your house key under a rock by the front door. A burglar walks up, lifts the rock, and lets themselves in. Now imagine every house on your street hides an identical key under an identical rock. One burglar, one lucky lift, and suddenly the whole street is open. That is roughly the situation many Windows networks find themselves in, and the technique that exploits it is called pass the hash.

There is a moment early in learning Windows security where something clicks and feels deeply, uncomfortably wrong: in many cases an attacker does not need to crack your password at all. They can authenticate using the hashed form of it directly. No cracking, no guessing, no waiting. That technique is pass the hash, and it is one of the main reasons a single compromised machine can quietly turn into a compromised network.

This is a defensive explainer. The goal is to make the mechanism obvious so that the fixes make obvious sense too.

Credit and scope

Pass the hash is a long established technique, publicly demonstrated as far back as 1997 by Paul Ashton, and refined by the community for decades since. This explains how it works so defenders understand it. It is not my discovery.

Authorised testing only

Dumping credentials and reusing them belongs in systems you own or are engaged to test. Doing it elsewhere is unauthorised access.

What is a hash, in plain terms

Let us clear up the one word the whole technique hangs on, because everything else follows from it.

A hash is the output of a one way scrambling function. You feed in a password and it produces a fixed length string of gibberish. The important properties are that the same input always produces the same output, and that you cannot run the process backwards to recover the input from the output. Windows stores an NT hash of your password rather than the password itself, which sounds like good hygiene. If someone steals the stored data, they get scrambled gibberish, not your actual password.

So far so sensible. The problem is not the hash itself. The problem is what the hash is allowed to do.

The flaw is in how NTLM proves you

When you log in to Windows resources using the older NTLM authentication protocol, the system does not send your plaintext password across the network. Instead it proves you know the password using a challenge and response. The server sends a random challenge, your machine mixes that challenge with the NT hash of your password, and sends back the result. The server does the same calculation on its side and checks that the two match.

Notice what is missing from that description: at no point does anyone need the actual plaintext password. The calculation uses the hash. And that leads to the consequence that is so easy to miss and so devastating in practice: the hash itself is the thing that grants access. If an attacker gets hold of the NT hash, they can complete that challenge and response perfectly well without ever knowing or cracking the underlying password. In this world the hash is not a protected version of the password. The hash is a password equivalent.

Normal:   password -> hash -> authenticate
Attacker: (steal the hash)  -> authenticate      # the middle step is skipped

This is the whole trick. The attacker skips the part everyone assumes is hard, the cracking, because they never needed the plaintext in the first place. Pass the hash means literally passing the stolen hash into the authentication process as though it were the password.

A useful way to hold it in your head

Cracking a hash is like trying to reverse engineer a key from a photo of it. Pass the hash skips all that. It is more like finding the actual key already cut and lying on a table, then walking to the door and using it. Why reverse engineer a key you can simply pick up?

Where the hashes come from

If the hash is as good as the password, the attacker's real job is simply to find hashes lying around. Windows, unfortunately, leaves quite a few of them within reach.

An attacker who gains administrator rights on a single machine can pull hashes out of memory or out of local storage on that machine. The classic tool for this is Mimikatz, which reads credentials from the part of Windows that caches them for users who are currently logged in, a process usually called LSASS. Here is the part that turns a small problem into a big one: every account that has logged into that machine may have left a reusable credential behind in memory. That includes any administrators who connected to fix something, any service accounts, and any domain accounts that touched the box. A helpdesk admin who remoted in last week to sort out a printer may have left their hash sitting there for the taking.

So the attacker does not need to compromise the important accounts directly. They just need one machine where important accounts have been used.

Why it means lateral movement

Lateral movement is the security term for an attacker spreading sideways from one machine to another inside a network, as opposed to breaking in from outside. Pass the hash is one of the great engines of lateral movement, and the chain looks like this:

1. Compromise one workstation and get local admin.
2. Dump the hashes of accounts that have logged in there.
3. Find an account, often a local admin or a domain account, that
   also has access to other machines.
4. Pass that hash to those machines to authenticate as that user.
5. Land on new machines, dump more hashes, repeat.

Each loop through that cycle can widen the attacker's reach. Tools such as Impacket and CrackMapExec collapse steps four and five into a single command, so the attacker can spray a stolen hash across dozens of machines in seconds to see where it works.

Now here is the single misconfiguration that ends more internal assessments than almost anything else. If the same local administrator password is used on every workstation, then every workstation has the same local admin hash. One hash dumped from one machine unlocks the entire fleet, because it is the identical key under the identical rock on every house on the street. The attacker does not even need a domain account for this. They just reuse the one local admin hash everywhere and walk from machine to machine at will.

Shared local admin password across all machines:
 
  PC-01 hash  ==  PC-02 hash  ==  PC-03 hash  == ...
 
  Steal it once  --->  authenticate to all of them

The shared local admin password is the classic disaster

If you take nothing else from this article, take this. A single local administrator password reused across your whole estate means one dumped hash equals total lateral movement. Attackers know this and check for it first, because it works so often. It is the flat tyre that has stranded countless organisations.

Breaking the chain

You cannot easily change how NTLM works under the bonnet, so the defence is not to fix the protocol. Instead you deny the attacker useful hashes in the first place, and you make sure that any hash they do steal cannot be reused anywhere that matters.

  1. Unique local admin passwords everywhere. Microsoft's LAPS (Local Administrator Password Solution) automatically sets a different random local administrator password on every machine and stores it securely. A hash stolen from one machine is then useless on the next, because the key under each rock is different. This is the single highest impact fix, and it directly kills the shared password disaster described above.
  2. Protect credentials in memory. Credential Guard uses virtualisation to lock secrets away in a protected area that ordinary tools, including Mimikatz, cannot read. If the hashes are not sitting in reachable memory, they cannot be dumped.
  3. Tier your admins. Do not log high privilege domain accounts into ordinary workstations. If a Domain Admin never logs into a helpdesk laptop, then their hash is never sitting on that laptop to be stolen. This is the core idea of the administrative tiering model, and it is about denying the attacker the valuable hashes rather than trying to protect every machine equally.
  4. Reduce NTLM. Prefer Kerberos, which does not carry the same pass the hash weakness in the same way, and disable NTLM entirely wherever your environment can tolerate it. Less NTLM means fewer opportunities for the technique to apply.
  5. Use the Protected Users group for sensitive accounts. Membership in this group restricts the weaker credential caching that pass the hash relies on, so those accounts leave far less behind on any machine they touch.

Where to start if the list feels long

Deploy LAPS first. Reusing local admin passwords is the most common and most catastrophic weakness, and LAPS closes it directly with minimal disruption. Then tackle admin tiering so your most valuable hashes stop appearing on low value machines. Those two moves remove the bulk of the risk before you touch the protocol level fixes.

The takeaway

Pass the hash works because in NTLM the hash is as good as the password, so an attacker who steals a hash can authenticate without ever cracking anything. It becomes genuinely devastating when the same credential is reachable across many machines, above all a shared local admin password that turns one theft into full lateral movement. You beat it not by fixing the protocol but by making stolen hashes worthless: unique local admin passwords with LAPS, protected credentials in memory, and disciplined admin tiering so that privileged hashes are never left lying around on ordinary machines.

It pairs naturally with the offline cracking world of Kerberoasting, the other classic path through an Active Directory network, and if you want the deeper background on why hashes behave the way they do, the primer on how password hashing works fills in the picture.