NTLM - NT LAN Manager

What is NTLM?

NTLM (NT LAN Manager) is a family of Microsoft challenge-response authentication protocols that verify passwords without sending them over the wire. The family consists of four versions: LM, LMv2, NTLMv1 and NTLMv2. Since Windows Vista (2007) LM is disabled by default. NTLMv2 is the common variant on modern systems.

NTLM is not a standalone network protocol. It is embedded in other protocols such as SMB, HTTP, MSRPC and LDAP. An SMB client requesting access to a file share exchanges three NTLM messages with the server: Negotiate, Challenge and Authenticate. Those same messages can also sit in an HTTP header when an internal web server supports NTLM authentication.

Microsoft formally marked NTLM as deprecated in June 2024. It gets no more functional updates and is being disabled step by step from Windows 11 24H2 and Server 2025. Kerberos has been the standard in Active Directory environments since 2000, but NTLM stubbornly lives on in practice through legacy applications and local workgroup authentication. For the official protocol family and current status, see the NTLM overview from Microsoft.

How does NTLM work?

The NT hash, also called the NTLM hash, is an MD4 hash of the password in UTF-16LE encoding. Without a salt. Two users with the same password therefore get the same hash, and that makes offline cracking and credential stuffing a lot cheaper.

The authentication itself runs in three messages:

1. NEGOTIATE_MESSAGE: the client tells the server which NTLM features it supports (version, signing, sealing).
2. CHALLENGE_MESSAGE: the server sends back a random 8-byte nonce, the “challenge”.
3. AUTHENTICATE_MESSAGE: the client computes a response from the challenge and its NT hash and sends it back. The server (or the domain controller) verifies by performing the same computation.

The compute function differs per version. NTLMv1 pads the 16-byte NT hash with zeros to 21 bytes, splits that into three 7-byte keys, and encrypts the 8-byte server challenge with each key using DES. The three blocks are concatenated into a 24-byte response. NTLMv2 folds a client challenge, a timestamp and target information into a “blob” on top of that, and computes HMAC-MD5 over the server challenge plus that blob. That is what Responder captures and what hashcat cracks in mode 5600 (Net-NTLMv2 format: username::domain:challenge:ntlmv2-hash:blob). For a full breakdown with hex examples, see our blog The difference between NTLM, NTLMv2 and LM.

For offline cracking NTLMv2 is heavier than NTLMv1, but without a salt brute-force stays feasible. An 8-character lowercase password falls on an average GPU in minutes.

The domain controller does the verification through a process called netlogon. If it says “correct”, the user gets their access token and is logged in.

What can an attacker do with NTLM?

Three attack paths come back in nearly every Active Directory pentest.

The first is Pass-the-Hash. Whoever holds the NT hash of an account does not have to crack that hash. The challenge-response computation works directly with the hash as the key. Attackers pull hashes from LSASS memory (through Mimikatz or NetExec) or from the SAM database of a compromised workstation. With NetExec or psexec they then log in to other systems.

A Net-NTLMv2 response captured through Responder or a similar tool is different. The server challenge is baked into the computation, so replaying the same response a second time fails as soon as a real server hands out a new challenge. That leaves two paths: relay the authentication in real time to another server, or crack the response offline to still get hold of the password (and with it the usable NT hash).

The second is NTLM-relay. NTLM proves that the client holds the right hash, but it does not tie that authentication to the server the client thought it was talking to. An attacker who positions himself between client and server can forward the challenge-response messages to a third server and log in as that user. Responder captures authentication through LLMNR/NBT-NS poisoning, Mitm6 through DHCPv6 spoofing, and ntlmrelayx (from Impacket) does the relay step. Targets are SMB shares, LDAP for object changes, and AD CS HTTP endpoints for certificate issuance. SMB signing is the best-known defense against relay to SMB. If it is required on the target server, every packet has to be signed with a session key derived from the NTLM authentication. The attacker does not hold that key, so the relayed session dies right after the login. For LDAP something similar applies with LDAP signing and channel binding.

The third is offline cracking, possibly combined with an NTLMv1 downgrade. An NTLMv2 challenge-response pair intercepted through Responder goes into hashcat against a wordlist or brute-force. If cracking does not work within reasonable time, an attacker tries to force NTLMv1, because NTLMv1 responses can be reversed completely with DES rainbow tables in minutes.

NTLM in a pentest

In an AD pentest we usually start by setting up a Responder listener and waiting for what comes in. A workstation looking for a mistyped share or a misconfigured printer yields an NTLMv2 response within minutes, because Windows responds without further checks to any host that presents itself as the wanted server. A full capture-and-crack walkthrough with Responder and hashcat is in our blog Responder, SMB signing and relay.

What happens next depends on the account we catch. An ordinary user with a long password goes against hashcat and we wait it out. If we catch a service account, or a user where the target server does not enforce SMB signing, we skip the cracking and relay directly with ntlmrelayx. On LDAP in that scenario we add an attacker account to a privileged group, on SMB we dump hashes from the SAM or the NTDS of the destination.

How do you prevent NTLM abuse?

Removing NTLM entirely from a grown AD environment is a multi-year effort. Microsoft now provides migration help: NTLM auditing in Windows 11 24H2 and Server 2025 shows where NTLM is still active, and IAKerb makes Kerberos authentication possible even without line of sight to the domain controller. See Advancing Windows security: Disabling NTLM by default for the official migration roadmap. In the meantime you break the attack chain in several places:

• Turn off LLMNR and NBT-NS through Group Policy. Responder loses its primary channel to harvest hashes.
• Require SMB signing on all servers and clients. NTLM relay to SMB then no longer works.
• Turn on LDAP signing and channel binding on your domain controllers. This blocks relay to LDAP, otherwise a fast route to AD object changes.
• Set “Network security: LAN Manager authentication level” to level 5 (NTLMv2 only). NTLMv1 responses are trivial to crack with rainbow tables.
• Limit NTLM use through the “Network security: Restrict NTLM” GPO set. This way you identify which applications still depend on NTLM before you disable it completely.
• Microsoft LAPS gives each system a unique local admin password. A stolen NTLM hash on one machine is then no longer usable on other systems.
• Credential Guard places LSASS in an isolated container, so tools like Mimikatz can no longer read the NTLM hashes from memory.