NTLM is the authentication protocol Kerberos was meant to replace, and it is still everywhere. Windows falls back to it whenever Kerberos cannot be used — when a host is reached by IP instead of hostname, when there is no SPN, in workgroup settings, and in countless legacy corners. Because it never fully went away, the attacks built on it — pass-the-hash, cracking, and relay — remain some of the most reliable techniques against Active Directory.
Two different things called "NTLM"
The single biggest source of confusion in this area is that "NTLM hash" can mean two completely different values. Getting this distinction right is essential, because it determines which attack is even possible.
| Value | What it is |
|---|---|
| NT hash | The MD4 hash of the user's password. Stored in the SAM (local) or NTDS.dit (domain). It is a password equivalent — this is what pass-the-hash uses |
| NetNTLM (v1/v2) | A challenge-response value produced during an authentication exchange, derived from the NT hash plus a server challenge. This is what Responder captures — you crack it or relay it, you cannot replay it |
The rule that follows from this: an NT hash can be passed directly (pass-the-hash). A NetNTLM hash cannot — it is challenge-response, tied to one exchange, so your only options are to crack it offline or relay it live to another service. Mixing these up is the classic beginner error.
The NTLM challenge-response flow
When a client authenticates to a server over NTLM, three messages pass between them:
| Message | Contents |
|---|---|
| NEGOTIATE (Type 1) | Client to server — announces NTLM support and capabilities |
| CHALLENGE (Type 2) | Server to client — a random nonce (the challenge) the client must respond to |
| AUTHENTICATE (Type 3) | Client to server — the response, computed from the NT hash and the challenge, plus the username and domain |
The server then verifies the response. In a domain, it forwards it to a domain controller (via the Netlogon secure channel) which holds the user's NT hash and can confirm the maths. The password itself is never transmitted, and neither is the NT hash directly — only a value derived from it and the challenge.
Pass-the-Hash
Here is the design flaw that makes NTLM so productive. The protocol proves the client knows the NT hash, not the password. But the NT hash is not salted and does not change unless the password changes — so if you steal the NT hash, you can authenticate as that user without ever knowing or cracking their password. You simply feed the hash to the same maths the legitimate client would.
# the NT hash IS the credential
netexec smb 10.10.10.0/24 -u Administrator -H <nthash>
psexec.py -hashes :<nthash> Administrator@10.10.10.10
evil-winrm -i 10.10.10.10 -u Administrator -H <nthash>NT hashes are harvested from LSASS memory (Mimikatz), the local SAM, or the domain NTDS.dit. Once you have one for a privileged account, pass-the-hash gives you that account's access everywhere NTLM is accepted — no cracking required.
Cracking NetNTLM
When you capture a NetNTLM hash — typically from Responder poisoning — you cannot pass it. You crack it offline:
hashcat -m 5600 netntlmv2.txt rockyou.txt # NetNTLMv2
hashcat -m 5500 netntlmv1.txt rockyou.txt # NetNTLMv1| Version | Security |
|---|---|
| NetNTLMv1 | Weak. Can be downgraded/converted toward the NT hash via known DES weaknesses — treat any v1 as near-broken |
| NetNTLMv2 | Stronger, includes client and server challenges and a timestamp. Only as strong as the password behind it — a weak password still cracks quickly |
NTLM Relay
If you cannot crack a captured NetNTLM hash, you can often use it anyway — while it is still valid — by relaying it. Instead of trying to verify the authentication yourself, you forward it, in real time, to a different service that will accept it. Because the relayed authentication carries the victim's identity, you act as the victim on the target.
This is significant enough to have its own page: Coercion & NTLM Relay. The short version is that relay works wherever a protection is missing — SMB signing off, LDAP channel binding off, or EPA not enforced on AD CS web enrolment — and the defences against it are exactly those three controls.
Why NTLM refuses to die
| Reason | Consequence |
|---|---|
| Kerberos needs an SPN and a hostname | Any access by raw IP falls back to NTLM automatically |
| Legacy applications hardcode it | Old software and appliances never learned Kerberos |
| The NT hash is unsalted and static | Pass-the-hash works indefinitely until the password changes |
| Backwards compatibility is sacred | Disabling NTLM outright breaks things, so most orgs never do |
Defences worth knowing
- SMB signing — cryptographically signs SMB sessions, breaking SMB relay. The single most effective control against relaying.
- LDAP channel binding and signing — the equivalent protection for LDAP, closing the RBCD and Shadow Credential relay paths.
- Disable NTLMv1 — removes the weakest challenge-response variant entirely.
- Credential Guard — isolates NT hashes from LSASS so they cannot be dumped, undercutting pass-the-hash at the source.
- Restrict NTLM — Group Policy can audit and then block NTLM in stages, the long road to removing it.
The takeaway
NTLM gives an attacker two distinct primitives from one protocol. The static, unsalted NT hash is a password equivalent you can pass directly, which is why credential dumping is so valuable. The NetNTLM challenge-response you capture on the wire is crack-or-relay material, which is why Responder and ntlmrelayx are internal-network staples. Keep the two straight and the entire family of NTLM attacks organises itself cleanly — see Coercion & NTLM Relay for the relay chain and theToolkit Vulns & Misconfigs for the tools.