FFoundationalActive Directory
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.
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.
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.
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
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."
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.