If you've spent any time in Windows security, you've probably seen both "NTLM" and "NTLMv2" thrown around. They sound similar, and they share the same underlying password hash, but they're fundamentally different authentication protocols with very different security properties.
Understanding the difference matters. If your organization is still using NTLMv1, you're exposed to attacks that NTLMv2 was specifically designed to prevent. Let's walk through what changed, why it matters, and what you should do about it.
NTLM Protocol Overview
First, let's clarify what we're talking about. The NTLM hash is the stored password hash format (MD4 of UTF-16LE encoded password). NTLM the protocol is the challenge-response authentication mechanism that uses that hash. These are related but distinct concepts.
The NTLM authentication protocol was introduced with Windows NT 3.1 in 1993. It uses a challenge-response mechanism where the client proves it knows the password without sending it over the network. Here's the basic flow:
1. **Negotiation:** The client tells the server it wants to authenticate using NTLM. 2. **Challenge:** The server sends a random 8-byte challenge (nonce) to the client. 3. **Response:** The client uses its NTLM hash to compute a response to the challenge and sends it back. 4. **Verification:** The server (or domain controller) computes the expected response and compares it to what the client sent.
The response computation in NTLMv1 involves DES encryption of the server challenge using keys derived from the NTLM hash. The server can verify the response because it also has the stored NTLM hash.
This sounds reasonable in theory. The password never crosses the network. But the protocol has serious weaknesses.
The Problems with NTLMv1
NTLMv1 (also called NTLM or NTLMv1) has several critical flaws:
**No Client Challenge:** The client response is based solely on the server's challenge. An attacker who captures the exchange can replay the response to authenticate as that user in a different session.
**Weak Response Computation:** The response is computed using DES, which is cryptographically obsolete. The keys are derived from the NTLM hash in a way that limits the effective key space.
**Susceptible to Relay Attacks:** Because the server doesn't prove its identity to the client, an attacker can position themselves between the client and server, relay the authentication exchange, and gain access to the server as the user.
**Rainbow Table Attacks:** The response computation is deterministic given the same challenge and hash, making pre-computed attacks feasible.
These weaknesses made NTLMv1 a prime target for attackers, and Microsoft needed to fix them.
NTLMv2: What Changed
NTLMv2 was introduced with Windows NT 4.0 SP4 in 1999 and became the default with Windows 2000. It addresses the core weaknesses of NTLMv1 while keeping the same underlying password hash format.
Here's what changed:
**Client Challenge (Nonce):** In NTLMv2, the client generates its own random 8-byte challenge in addition to the server's challenge. The response is computed using both challenges, which means each authentication session produces a unique response even for the same password.
**Timestamp Inclusion:** NTLMv2 includes a timestamp in the response computation. This means that even if an attacker captures a response, they can't replay it later because the timestamp will be too old. The server rejects responses with timestamps outside an acceptable window.
**HMAC-MD5 Response:** Instead of DES, NTLMv2 uses HMAC-MD5 to compute the response. The NTLM hash is used as the HMAC key, and the input includes the server challenge, client challenge, timestamp, and other session data. This produces a more robust, longer response.
**Target Information:** NTLMv2 includes information about the server (target) in the response computation, which helps prevent relay attacks by binding the response to a specific server identity.
The result is a protocol that resists replay attacks, is harder to relay, and produces responses that can't be pre-computed.
Why NTLMv2 Resists Relay Attacks Better
Relay attacks are one of the most dangerous threats in Windows environments. In a relay attack, the attacker intercepts an authentication exchange and forwards it to a different server, gaining access as the authenticated user.
NTLMv2 doesn't eliminate relay attacks entirely (channel binding and SMB signing are needed for that), but it makes them significantly harder:
The timestamp means a captured response has a limited shelf life. The attacker must relay it quickly before the timestamp expires. The client challenge means the response is unique to that specific session, so the attacker can't reuse it in a different context. The target information binds the response to a specific server, so relaying to a different server is more likely to fail.
That said, NTLMv2 relay attacks are still possible in certain configurations, which is why Microsoft continues to push for Kerberos and SMB signing as the real solutions.
The Hashes Are the Same
Here's a point that confuses many people: the stored password hash doesn't change between NTLMv1 and NTLMv2. Both protocols use the same NTLM hash (MD4 of UTF-16LE encoded password) as their starting point.
The difference is in how that hash is used during the authentication exchange. NTLMv1 derives DES keys from the hash. NTLMv2 uses the hash as an HMAC key. But the hash stored in the SAM or NTDS.dit is identical.
This means you can use the same NTLM Hash Generator to produce hashes for both protocols. The hash format is the same. For a deeper understanding of the hash itself, read our article on NTLM hash explained.
Configuring NTLMv2 in Modern Windows
Modern Windows versions default to NTLMv2, but it's important to verify your configuration:
**Group Policy:** Set "Network security: LAN Manager authentication level" to "Send NTLMv2 response only" or "Send NTLMv2 response only. Refuse LM & NTLM." The latter is more secure as it refuses the weakest protocols entirely.
**Registry:** The same setting can be configured via HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel. A value of 5 means "Send NTLMv2 response only. Refuse LM & NTLM."
**Event Logging:** Enable audit logging for NTLM to monitor which systems are still using older versions. Look for Event ID 8003 (NTLMv1) in the Windows event logs.
**Disabling NTLM Entirely:** The ultimate goal should be to disable NTLM altogether and use Kerberos. Windows Server 2019 and later include NTLM auditing and restriction policies that can help you identify and eliminate NTLM dependencies.
Why This Matters for Security
The difference between NTLMv1 and NTLMv2 isn't academic. Real-world attacks exploit NTLMv1 weaknesses:
Attackers use tools like Responder to capture NTLM challenges on the network. If clients respond with NTLMv1, the attacker can crack the captured exchange offline. NTLMv2 responses are much harder to crack because they include the client challenge and timestamp.
Pass-the-hash attacks work with both protocols, but the stronger response computation in NTLMv2 makes certain attack variations more difficult. Read more about this in our article on pass-the-hash attacks.
Relay attacks like SMB relay depend on the protocol version. NTLMv2's timestamp and target information make relay harder, though not impossible.
The Path Forward
Microsoft has been clear about the trajectory: NTLM (including NTLMv2) is being deprecated. Windows 11 and Windows Server 2022 include features for auditing and restricting NTLM usage. The long-term goal is Kerberos everywhere.
But until that happens, understanding the difference between NTLMv1 and NTLMv2 helps you: - Configure your systems to use the strongest available protocol - Identify and remediate legacy applications that force NTLMv1 - Understand why captured hashes can be used for pass-the-hash regardless of protocol version - Make informed decisions about when to accept NTLM and when to require Kerberos
For the full picture of how NTLM fits into the broader Windows authentication landscape, read our guide on Windows authentication: Kerberos vs NTLM.
