What is a pass-the-hash attack and how to prevent it

Windows has several ways to verify a user's identity on a network. One of the older methods is the New Technology LAN Manager (NTLM) protocol. It converts a password into a cryptographic value known as a hash and uses that hash during authentication instead of sending the password itself.

In networks where NTLM is enabled, that hash can become a target. If an attacker steals it, they can use it to authenticate as that user without knowing the password. This technique is known as a pass-the-hash attack.

Ahead, we cover how pass-the-hash works, how attackers obtain and reuse credential hashes, and what organizations can do to detect and prevent it.

What is a pass-the-hash attack?

A pass-the-hash (PtH) attack happens when an attacker uses a stolen NTLM hash to sign in as a legitimate user. Instead of entering the user’s password, the attacker submits the hash during the NTLM sign-in process. If NTLM is enabled and the account is allowed to use it, the system accepts the login.

The attacker doesn't need to know or crack the password. The hash alone can satisfy the NTLM verification check.

How pass-the-hash differs from password theft and relay

Password theft, PtH, and relay attacks all involve authentication, but they work in different ways.

With password theft, the attacker obtains a user’s actual password. This can happen through phishing, malware, data breaches, or other forms of credential exposure. If the account allows it, they can use that password to sign into systems that accept those credentials.

In relay attacks, the attacker intercepts a live authentication attempt and forwards it to another system in real time. They don't extract or store the password or the hash. They redirect an active authentication attempt to a different target.

Each method requires a different defense. Disabling NTLM prevents PtH but not password theft, while anti-phishing controls can reduce password compromise but don't address relay attacks.

How NTLM authentication works and why it’s vulnerable

PtH works because of how NTLM handles authentication during sign-in.

What NTLM is and how Windows uses it

NTLM is an older sign-in method built into Windows. It’s used when a person logs into a computer or connects to a shared folder, printer, or server.

In many organizations, computers are organized into a Windows domain. A domain is a centrally managed network where user accounts and permissions are controlled through Active Directory (AD). Active Directory stores account information and handles authentication across multiple machines.

NTLM uses a challenge-response process:

1. The server sends a random value, called a challenge.
2. The user’s computer calculates a response using a stored version of the password, known as a hash.
3. The server verifies the response by performing the same calculation with the hash it has on file. In a domain, that verification is handled by a domain controller, the server responsible for validating user accounts across the network.
4. If the values match, the user is authenticated. The password itself is never transmitted.

During an active session, Windows may temporarily retain authentication data in memory so the user doesn’t have to re-enter their password for every request. That behavior supports normal use but can create risk if the machine is compromised.

In most modern domain environments, Windows uses a different authentication method called Kerberos by default. Kerberos is considered to be more secure than NTLM because it requires mutual authentication and doesn’t transmit password hashes, helping to protect against interception.

However, in situations where Kerberos can’t be used (for example, in legacy systems), Windows falls back to NTLM.

What NTLM stores and why it matters

NTLM involves three related pieces of data:

The password

This is what the user types when signing in. Windows immediately converts it into a hash and discards the original. The password itself isn't stored for authentication.

The NT hash

This is the stored version of the password. It’s created using the MD4, an older cryptographic hashing algorithm. On a local machine, it’s stored in the SAM (Security Accounts Manager) database, where Windows stores local account credentials. For domain accounts, it’s stored in Active Directory.

The NT hash isn’t salted. Salting means adding random data before hashing so identical passwords don’t produce identical hashes. Because NTLM doesn’t use salting, the same password always produces the same hash. The hash remains valid until the password is changed.

The NTLM response (NetNTLM)

This is the value sent during sign-in. It’s calculated using the NT hash and the server’s challenge. This is the only value transmitted during authentication.

Security limitations of NTLM

NTLM was designed decades ago, before many modern identity protections were common. Several design choices increase risk today.

The hash remains valid until the password changes

The NT hash doesn't expire on its own. A stolen hash remains usable for as long as the account's password stays the same, which in some environments can be months or years.

The same hash can work across multiple systems

NTLM doesn't limit authentication to a single machine. Any system that accepts NTLM for that account will validate the same hash. If the account can access multiple machines, a stolen hash can be reused on each of them.

NTLMv2 improves cracking resistance but not hash reuse

NTLM has two main versions: NTLMv1 and NTLMv2. NTLMv1 uses weaker cryptography and is considered insecure. NTLMv2 strengthens the authentication process, which makes password guessing more difficult. However, both versions still rely on the same underlying techniques. This means that a stolen hash can still be reused if NTLM is accepted.

Kerberos reduces this risk by issuing temporary authentication tickets instead of relying on a reusable password hash. Those tickets expire, which limits how long stolen authentication material can be reused.

How pass-the-hash attacks work

A PtH attack has two stages: obtaining a usable NTLM hash and then using that hash to authenticate to systems that accept NTLM for that account. How the hash is obtained varies, but the authentication step works the same way regardless of the source.

How attackers obtain NTLM hashes

Attackers can obtain NTLM hashes in several ways, each with different access requirements.

• From compromised systems: On a Windows machine, credential material can sometimes be recovered from active memory or disk storage. This method typically requires administrative privileges on the compromised machine.
• From previous breaches or leaks: NTLM hashes can also come from credential dumps. These are collections of stolen usernames and password hashes that are shared after data breaches.
• Via legacy or misconfigured authentication: On older or poorly set up systems, WDigest, a legacy authentication feature, may store credentials in cleartext in memory. This exposes the actual password, not just the hash. Microsoft addressed this with security update KB2871997, which allows organizations to disable WDigest credential caching.
• Via legacy or misconfigured networks: If an attacker gains access to a network that uses older or wrongly configured methods for device connections, they can sometimes intercept connection requests and steal the associated hash.

How attackers use a stolen NTLM hash to authenticate

Once an attacker has an NT hash, they use it to generate the required NTLM authentication response instead of deriving it from a typed password. If the target system accepts NTLM for that account, the authentication can succeed.

Log records will show a valid NTLM sign-in from the source system, but they don’t indicate whether the response was generated from a typed password or a reused hash.

The attacker doesn't need to already be inside the target network. If they've obtained a valid hash from any source, they can use it to authenticate remotely. This makes PtH a possible initial point of entry, not only a lateral movement technique.

How access spreads across systems

Once authenticated, the attacker can access the systems and data that the affected account is permitted to use. The impact depends on the type of account that was compromised.

Local account hash

A local account exists only on one computer. However, if multiple machines share the same local administrator password, a hash from any one of them works on the rest.

Domain user hash

A domain user account can authenticate to multiple systems across the network. The attacker can reuse the stolen hash to reach each system that the account is permitted to access. On some machines, the account may have full control, while on others it may only have limited access.

Domain administrator hash

These hashes carry the widest impact. Domain administrators typically have access across the entire Active Directory environment, including domain controllers. Compromising a single domain admin hash can give the attacker effective control over the whole network.

Each successful sign-in can leave credential data in memory on that system. If the attacker extracts those credentials, they gain material to authenticate to additional machines, chaining one compromise into the next.

What's at risk after a pass-the-hash attack

The immediate consequence is unauthorized access under a legitimate account. If the attacker reaches a domain administrator account, the impact grows significantly. Domain administrators can reset passwords, create new accounts, change security settings that apply across the network, and access domain controllers directly.

Without monitoring sign-in activity and credential use, organizations may not notice the compromise until data has already been copied or account settings have been changed.

Conditions that make pass-the-hash attacks possible

These environmental factors determine how far a PtH attack can spread.

NTLM enabled across the environment

The number of systems that accept NTLM directly determines how far a stolen hash can reach. Organizations that have restricted NTLM to a small set of legacy systems limit the attacker's options. Those who haven't audited NTLM usage may not know how many systems still accept it.

Credential reuse and broad authentication scope

The impact of a stolen hash depends on how widely the account can sign in.

A domain account that can sign in to multiple machines creates more exposure than a local account that exists on only one machine. What determines risk isn't the account's privilege level on any single system. It's how many systems accept those credentials.

Shared local administrator passwords are also a concern. If every workstation uses the same local admin credentials, a single hash works across all of them.

Lack of credential isolation

Whether an attacker can extract hashes from a compromised system depends on how that system protects credential data in memory.

Windows includes a feature called Credential Guard that stores credential data in an isolated area of the operating system where standard processes can't reach it. Without Credential Guard, an attacker with administrative access to a machine may be able to read hashes directly from memory.

Network segmentation also limits how far an attacker can move. When systems are divided into separate network segments, a compromised account can’t automatically reach every machine. Without segmentation, a single stolen hash may provide access across large parts of the environment.

How to detect a pass-the-hash attack

Detection is difficult because the login itself follows normal NTLM authentication steps. Instead of looking for failed or malformed sign-ins, detection focuses on behavioral patterns that don't match the account's normal activity.

Unusual NTLM authentication patterns

NTLM is typically restricted to specific legacy scenarios in modern AD environments. If it appears in situations where it isn’t normally used, it warrants investigation.

Other warning signs include:

• The same account signing into several systems within a short period of time.
• An account accessing machines it doesn’t normally use.
• A remote sign-in from another system when the user would normally be working directly on that machine.
• Failed sign-in attempts on one system followed by a successful NTLM sign-in on another.

Legitimate administrative activity can produce similar patterns. They’re usually only treated as suspicious when they differ from how the account is normally used.

Correlating authentication and endpoint activity

Security information and event management (SIEM) systems collect sign-in records from servers, workstations, and directory systems such as Active Directory into one place. This makes it easier to see where an account signs in and how it moves between systems over time.

Endpoint detection and response (EDR) tools focus on individual machines. They show which programs were running, whether any process attempted to access lsass.exe (where Windows stores sign-in data in memory), and what happened around the time of suspicious logins.

Neither tool labels an event as pass-the-hash. It comes down to correlating authentication patterns across both sources to identify credential reuse.

How to contain and recover from a pass-the-hash attack

Suspected PtH attacks should always first be reported to an organization’s IT or security team for immediate investigation.

Containment should assume the stolen credentials have already been used on other systems. The goal is to stop further access, identify how far the compromise has spread, and prevent reuse.

Immediate containment

Containment usually starts with limiting what the compromised account can access.

Accounts showing signs of misuse should be disabled or restricted during investigation. Systems that appear compromised should also be isolated so they can’t communicate with the rest of the network.

If NTLM is still broadly accepted across the environment, access can be tightened during the investigation to reduce how far the stolen hash can reach. These are often emergency restrictions, not long-term policy changes, so they’re usually documented and reviewed once the incident is resolved.

Credential reset and access review

Passwords should be reset for any account whose credential material may have been exposed. Priority normally starts with accounts that have broad access, including administrative accounts.

Password resets alone aren't enough. Investigations should review where those accounts are allowed to sign in, remove unnecessary group memberships and privileges, and limit sign-in rights to only the systems required for the account's role. Recent sign-in activity is also usually checked to confirm the account hasn't been used on other systems during the compromise.

When a full rebuild is required

If the attacker had extended access to high-privilege systems, there may be no reliable way to verify what was changed or left behind. In those cases, rebuilding affected systems from clean sources may be safer than attempting to clean them in place.

How to prevent pass-the-hash attacks

Restrict NTLM to systems that require it

Identify which systems still depend on NTLM and limit its use to those systems. In domain environments, configure policies to restrict or block NTLM where it isn’t required. Roll changes out gradually and monitor for compatibility issues.

Use separate accounts for administrative tasks

Accounts used for system-level changes shouldn’t also be used for email, browsing, or routine work. Keeping administrative and everyday accounts separate reduces how often privileged credentials are exposed on general-purpose machines.

Deploy unique local passwords per machine

Microsoft’s Local Administrator Password Solution (LAPS) automatically generates a unique local administrator password for each system and stores it centrally. This prevents a hash from one machine from being reused against others.

Limit service account scope

Service accounts are used by applications or automated services instead of individual users. Because they often authenticate to multiple systems automatically, their credentials can appear in memory across the environment.

Limit each service account to only the systems and permissions it requires. Broadly scoped service accounts increase the number of systems where a stolen hash could be reused.

Disable LLMNR and NBT-NS

When a Windows computer connects to another device, it first uses the Domain Name System (DNS) to translate the device’s name into an IP address. This is called name resolution. If DNS doesn’t resolve the name, Windows may fall back to older name-resolution methods: Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS).

These older methods were designed for small or local networks. Instead of contacting a specific DNS server, they send a broadcast message to all devices on the same local network segment (a group of devices connected to the same local network). These messages can be vulnerable to spoofing, allowing an attacker to intercept any credentials then sent over the connection.

If a DNS is in place, these fallback name-resolution protocols are usually unnecessary. Disabling them removes one of the most common methods attackers use to capture NTLM hashes on a local network.

Enable Credential Guard and LSA protection

Credential Guard should be enabled on supported systems. LSA (Local Security Authority) protection adds another layer by restricting which programs can interact with lsass.exe. When LSA protection is enabled, only trusted, digitally signed programs can access that process.

Apply multi-factor authentication

Multi-factor authentication (MFA) requires a second verification factor beyond the password. It reduces the risk of initial compromise and lowers reliance on password-only authentication.

MFA doesn’t block PtH directly. If a system accepts NTLM without requiring a second factor, a reused hash can still succeed. MFA works best alongside the other protections listed here.

Related: What is two-factor authentication (2FA)?

Review account access regularly

Permissions tend to expand over time as roles change and temporary access isn't revoked. Scheduling regular audits of account scope helps identify unnecessary access before it becomes a path for credential misuse.

How network security and VPNs relate to pass-the-hash risk

A virtual private network (VPN) doesn't change how NTLM authentication works, but it can reduce certain network-level risks that sometimes lead to credential capture.

Reducing exposure on untrusted networks

On networks the user doesn't control, such as public Wi-Fi, attackers on the same network can sometimes intercept NTLM authentication data. For example, they can exploit the name-resolution fallback methods that Windows uses when DNS is unavailable.

A VPN encrypts traffic between the device and the VPN server. If a user connects to corporate resources through a VPN, it reduces the chance that someone on the same local Wi-Fi network can observe or tamper with that traffic in transit.

What a VPN can't prevent

A VPN doesn't stop LLMNR or NBT-NS from broadcasting on the device itself. Those protocols must be disabled separately through system settings or domain policies.

A VPN also doesn't protect credentials stored on the device. If the device is already compromised, an attacker can extract hashes from memory regardless of whether a VPN is active.

Lastly, a VPN doesn't change what happens after a hash is stolen. Once an attacker has a valid hash, the VPN has no effect on the authentication itself.