How NTLM Authentication Works: Challenge, Response & Pass-the-Hash (Animated)

NTLM is the older Windows login method that is still everywhere: whenever Kerberos can’t be used (connecting by IP address, workgroup machines, legacy apps), Windows falls back to NTLM. It proves you know the password without sending it, but the proof is built from the password hash, which is its biggest weakness.

1. Negotiate & challenge: the server sends a random challenge

The client says it wants NTLM; the server replies with an 8-byte random challenge.

1. NEGOTIATE (User PC → File server): The client lists what it supports.
2. CHALLENGE (File server → User PC): A fresh random challenge, different every time, so old answers can’t be replayed.

Wireshark filter:

ntlmssp.messagetype == 0x00000001 || ntlmssp.messagetype == 0x00000002

2. Authenticate: answer the challenge with the password hash

The client combines the challenge with the user’s password hash and sends the result. The file server passes it to a domain controller, which knows the hash and checks the answer.

1. AUTHENTICATE (User PC → File server): The password never crosses the network, but the response is calculated from its hash.
2. NETLOGON (File server → Domain controller): The file server doesn’t know Priya’s hash, so it asks a domain controller (pass-through authentication).
3. NETLOGON (Domain controller → File server): Valid.
4. SUCCESS (File server → User PC): Priya can open the share.

Wireshark filter:

ntlmssp.messagetype == 0x00000003

3. Pass-the-hash: attack: the hash works like a password

Because the response is calculated from the hash, not the password, an attacker who has stolen a hash from a compromised computer’s memory can answer challenges without ever knowing the password. That is how one infected PC often leads to many.

1. NEGOTIATE (Attacker → File server): The attacker starts a normal NTLM login.
2. CHALLENGE (File server → Attacker): The server sends a challenge as usual.
3. AUTHENTICATE (Attacker → File server): The answer is correct, so the domain controller approves it.
4. SUCCESS (File server → Attacker): The attacker is in as Priya, from a different machine, with no password.

Wireshark filter:

ntlmssp.auth.username

4. Reduce ntlm: defence: protect hashes, limit ntlm

Prefer Kerberos and audit then restrict NTLM; turn on Credential Guard so hashes can’t be read from memory; give every machine a unique local admin password (LAPS); put admins in the Protected Users group; require SMB signing.

1. AUTHENTICATE (Attacker → File server): With NTLM restricted the stolen hash is refused, and the attempt is logged for the SOC.

Group policy:

Network security: Restrict NTLM: Audit, then Deny
Network security: LAN Manager authentication level = Send NTLMv2 response only. Refuse LM & NTLM

FAQ