FFoundationalActive Directory
NTLM Authentication Fundamentals
NTLM is the legacy challenge-response protocol that Active Directory still falls back on whenever Kerberos cannot be used. This lesson explains how NTLM proves identity without sending passwords, why its design leaves it exposed to capture and relay, and how to discuss those weaknesses clearly in interviews and with stakeholders.
This lesson builds on
Why it matters
Even in environments where Kerberos is the default, NTLM is almost always still reachable. Active Directory keeps it as a fallback for IP-based connections, local accounts, and older applications, which means an attacker rarely has to disable Kerberos to use NTLM, they just have to ask for it. Many of the highest-impact AD attacks, including credential capture and relay, exploit NTLM rather than Kerberos. If you can explain how NTLM authenticates a user, you can explain why those attacks work and why simply having Kerberos deployed does not make them go away.
Key Concepts
- Challenge-response authentication — a scheme where the server sends a random challenge and the client returns a response computed from that challenge and the user's password hash, proving knowledge of the secret without ever sending it
- NEGOTIATE / CHALLENGE / AUTHENTICATE — the three NTLM messages: the client requests authentication (NEGOTIATE), the server replies with a random challenge (CHALLENGE), and the client returns its computed response (AUTHENTICATE)
- Server challenge (nonce) — a one-time pseudo-random number the server generates for each authentication, designed to make every response unique and prevent simple replay of a captured exchange
- Pass-through authentication — because a member server does not hold user password hashes, it forwards the NTLM response to a domain controller to verify the user's identity on its behalf
- Signing and sealing — optional NTLM session security: signing adds message integrity (a MAC) to detect tampering and relay, while sealing adds confidentiality through encryption
- NTLMv1 vs NTLMv2 — two versions of the response calculation; NTLMv1 (and legacy LM) are cryptographically weak and deprecated, while NTLMv2 is the stronger, default modern variant
Theory
Core idea
NTLM is a challenge-response protocol. Instead of sending a password, the client proves it knows the password by performing a calculation that only someone with the password hash could perform. The secret never travels across the network, which sounds reassuring until you realize what does travel: a response that is mathematically derived from that secret.
The exchange is three messages. The client announces it wants to authenticate, the server replies with a random challenge, and the client returns a response computed from that challenge plus the user's password hash. Because a member server does not store everyone's password hashes, it cannot verify the response itself. It hands the response to a domain controller, which checks it and answers yes or no. This delegation step is called pass-through authentication.
Mental model
Think of NTLM like proving you know a shared secret over the phone without ever saying the secret out loud. The other party reads you a random number (the challenge), you combine that number with the secret using an agreed-upon rule, and you read back the result (the response). If the result matches what they independently computed, they conclude you must know the secret, even though you never spoke it.
The crucial detail is that the challenge is random and one-time. This is what stops an eavesdropper from simply recording your answer and replaying it later, because next time the number will be different. But notice what this model does not protect against: someone who can stand in the middle of the conversation and pass your response along to a third party in real time. The response is bound to the secret, but in plain NTLM it is not bound to who you thought you were talking to.
Common misunderstandings
- Assuming NTLM is dead because Kerberos exists. Kerberos is the default, but NTLM is retained as a fallback and is enabled in the overwhelming majority of real environments. Attackers exploit its continued presence, not its absence.
- Believing "no password on the wire" means "secure." NTLM does not transmit the password, but the response it transmits is derived from the password hash. That response can be captured and cracked offline, or relayed to another system without ever being cracked at all.
- Conflating capturing a hash with cracking it. The NTLMv2 material captured over the network is a challenge-response, not the raw password hash. It can be subjected to offline cracking, but relay attacks sidestep cracking entirely by reusing the live response.
- Treating NTLMv1 and NTLMv2 as interchangeable. NTLMv1 and legacy LM are cryptographically weak and deprecated; NTLMv2 is meaningfully stronger. When you discuss NTLM risk, the version matters, and so do the signing and sealing settings layered on top.
Real-world context
On an assessment, NTLM is where a lot of early movement happens. Tools that listen for or coerce NTLM authentication let an attacker capture responses from machines and users across the network. From there, two paths open: take the captured NTLMv2 response away and attempt offline password cracking, or relay the response in real time to another service that will accept it, authenticating as the victim without ever learning their password.
This is also why session security settings carry so much weight in findings. SMB signing is the single setting that most often decides whether a relay attack succeeds. Signing adds a message integrity check that an in-the-middle attacker cannot forge, because they do not hold the user's password hash. When signing is required, relay fails; when it is merely optional, relay frequently works. Domain controllers require signing by default, but ordinary member servers historically did not, which is exactly the gap relay attacks live in. When you explain an NTLM finding to a client, the conversation is rarely "NTLM is bad" and almost always "NTLM is reachable, signing is not enforced here, and that combination is what we exploited."
Communication
Interview answer
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. When signing isn't enforced, NTLM's fallback availability becomes a real attack surface.
Follow-up questions
- If NTLM never sends the password, how can an attacker still end up with valid access?
- What is the practical difference between cracking a captured NTLMv2 response and relaying it?
- Why does SMB signing stop relay attacks but not offline cracking?
- Why is NTLMv1 considered dangerous enough to disable, and how does NTLMv2 improve on it?
- In what situations will Active Directory fall back to NTLM even though Kerberos is available?
