NTLM Authentication Fundamentals Brief
What It Is
NTLM is a challenge-response authentication protocol that Active Directory keeps as a fallback to Kerberos. The client proves knowledge of the user's password without sending it: by computing a response from a server-issued random challenge and the password hash. Because member servers do not hold domain password hashes, they forward the response to a domain controller for verification (pass-through authentication).
Mental Model
Think of NTLM like proving you know a shared secret over the phone without saying it aloud. The other party reads you a random number (the challenge), you combine it with the secret using an agreed rule, and you read back the result (the response). If your result matches what they independently computed, they conclude you know the secret. The key weakness: this model stops replay (the number changes each time) but does not stop relay: someone who intercepts your response can pass it to a third party in real time, before it expires.
The Three NTLM Messages
- NEGOTIATE: client announces it wants to authenticate and its capabilities
- CHALLENGE: server replies with a random nonce (one-time pseudo-random number)
- AUTHENTICATE: client returns the response computed from the nonce + password hash
Key Security Properties
- No password on the wire, but the response derived from the hash is itself exploitable
- Nonce prevents simple replay, but not real-time relay by an in-the-middle attacker
- NTLMv2 is meaningfully stronger than NTLMv1 (HMAC-MD5 vs DES): version matters when assessing risk
- Signing (integrity) and sealing (encryption) are optional and must be enforced by policy, not defaults
- SMB signing being optional on member servers is the gap relay attacks live in
Interview Phrasing
NTLM is a challenge-response authentication protocol that Active Directory keeps as a fallback to Kerberos. The client proves it knows the user's password without sending it: by combining a random challenge from the server with the password hash and returning the result. The server can't verify that itself, so it passes the response through to a domain controller to confirm the identity. The security story has two sides. On one hand, the password never crosses the network. On the other, the response that does cross the network is derived from the secret, so it can be captured and cracked offline, or relayed live to another system that trusts it. That's why NTLM relay is such a common attack, and why message signing matters: signing binds the session so a relayed response gets rejected.
Common Pitfalls
- Assuming NTLM is gone because Kerberos exists: NTLM is the fallback and is enabled in the overwhelming majority of real environments
- Treating 'no password on the wire' as equivalent to security: the captured response is exploitable for cracking and relay
- Conflating capturing a challenge-response with capturing the raw hash: they are different; the captured NTLMv2 material requires cracking, relay bypasses cracking entirely
- Treating NTLMv1 and NTLMv2 as the same risk level: NTLMv1 is cryptographically weak and deprecated; the version matters
- Not mentioning signing when discussing relay: SMB signing is the single setting that most often decides whether relay succeeds
