1. Introduction
NTLM (NT LAN Manager) is the challenge-response authentication protocol Windows used before Kerberos, and despite being decades old it is still present in nearly every enterprise. Microsoft is actively deprecating it because its design predates modern threat models: it has no mutual authentication by default, it is trivially relayable, and the credential material it uses — the NT hash — is password-equivalent. If an attacker steals an NT hash, they do not need to crack it to authenticate. That single property is why Pass-the-Hash has survived twenty years of patching.
2. How It Works
NTLM is a three-message challenge-response exchange. The client never sends the password or hash over the wire; instead it proves knowledge of the hash by encrypting a server-supplied challenge.
Client Server Domain Controller
| 1. NEGOTIATE ------------------> | |
| 2. CHALLENGE (server nonce) <--- | |
| 3. AUTHENTICATE (response + | |
| username + domain) ---------> | 4. Netlogon: pass creds ----> |
| | for validation | validates
| | 5. Allow / Deny <------------ |
| 6. Access granted / denied <---- | |The server sends a random challenge; the client returns a response computed from the challenge and the user’s NT hash. The server cannot validate it alone, so it forwards the material to a domain controller over the Netlogon secure channel (pass-through authentication). Crucially, the server never learns the hash — it only relays.
3. The Security Problem
NTLMv1 vs NTLMv2: NTLMv1 uses a weak DES-based response and no client nonce contribution, making captured NTLMv1 responses crackable to the NT hash and enabling downgrade attacks. NTLMv2 adds a client challenge, timestamp and HMAC-MD5, which is much stronger against cracking — but both versions share the fatal architectural weakness: NTLM does not bind the authentication to the specific server (no default channel binding or signing), so it can be relayed. And because the NT hash itself is the secret, stealing it once yields reusable access.
4. How Attackers Abuse It
Pass-the-Hash (concept): After compromising a host, an attacker extracts NT hashes from memory or the local SAM and reuses them to authenticate as those users to other systems — no plaintext password required. Shared local administrator passwords make this laterally explosive.
NTLM Relay (concept): Because the client authenticates to whatever server it connects to, an attacker who can coerce or intercept a victim’s NTLM authentication can forward it to a third system and act as the victim there. If SMB signing or LDAP channel binding is not enforced, the relayed session is accepted. (The SMB and LDAP articles cover the transport-specific defences.)
In an authorized assessment, these are demonstrated in a lab to prove that, for example, a machine account can be relayed to an unsigned service — the deliverable is the list of unsigned services and coercion vectors to fix.
5. How to Detect / Identify NTLM Usage
Command
Get-WinEvent -LogName 'Microsoft-Windows-NTLM/Operational' -MaxEvents 100 | Select-Object TimeCreated, Id, MessageWhat it does: Reads the dedicated NTLM operational log (populated once NTLM auditing is enabled via policy).
What to look for: Entries showing NTLM being used for accounts or applications you expected to be Kerberos-only, and any NTLMv1 usage.
Defensive use: Builds the inventory of what still depends on NTLM before you restrict it — restricting blindly breaks apps.
Command
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 500 | Where-Object { $_.Properties[10].Value -eq 'NTLM' } | Select-Object TimeCreated, @{n='Account';e={$_.Properties[5].Value}}, @{n='Workstation';e={$_.Properties[11].Value}}What it does: Filters successful logons (4624) to those whose authentication package (event property index 10) is NTLM, and projects the account and source workstation.
What to look for: NTLM logons to servers that should only see Kerberos logons, or NTLM from service accounts.
Defensive use: Identifies systems and callers still relying on NTLM so you can migrate them.
Command
nltest /dsgetdc:corp.localWhat it does: Locates a domain controller and shows the secure-channel and capability flags for the domain.
What to look for: Use it alongside auditing to confirm which DCs are servicing pass-through authentication.
Defensive use: Helpful when validating that clients are reaching the intended, hardened DCs.
6. Where NTLM Still Appears in an Enterprise
- Access to resources by IP address instead of hostname (no SPN, so it falls back to NTLM).
- Local accounts and non-domain-joined systems.
- Legacy line-of-business apps, appliances, scanners and old SMB clients.
- Cross-forest scenarios without proper name resolution.
- Backup, monitoring and vulnerability-scanner service accounts.
7. How to Audit the Environment
- Enable “Network security: Restrict NTLM: Audit NTLM authentication in this domain” and “Audit Incoming NTLM Traffic” to log without blocking.
- Collect the NTLM operational logs from DCs and key servers for a representative period.
- Identify any NTLMv1 usage — it should be eliminated as a priority.
- Confirm SMB signing and LDAP channel binding are enforced (relay defences).
- Check for shared local admin passwords; deploy LAPS so each machine has a unique, rotated local admin password.
8. How to Fix / Harden It (Migration Strategy)
- Audit first, then restrict: move from “Audit” to “Deny” on the “Restrict NTLM” policies once you know what breaks.
- Kill NTLMv1 via “Network security: LAN Manager authentication level” set to Send NTLMv2 response only. Refuse LM & NTLM (level 5).
- Deploy LAPS to make Pass-the-Hash non-transferable between machines.
- Enforce SMB signing and LDAP channel binding/signing to defeat relay.
- Enable Credential Guard to protect NT hashes in memory from theft.
- Prefer Kerberos by using hostnames (with SPNs) rather than IP addresses.
9. Detection & Monitoring
- Event ID 4624 / 4625 with authentication package = NTLM — baseline and alert on anomalies.
- Microsoft-Windows-NTLM/Operational events — especially NTLMv1.
- Event ID 8004 (NTLM blocking/audit) in the NTLM log identifies the exact client, server and account for each NTLM attempt.
- Behavioural: a workstation authenticating to many hosts via NTLM in a short window can indicate lateral movement or relay.
10. MITRE ATT&CK Mapping
| Technique | ID |
|---|---|
| Use Alternate Authentication Material: Pass the Hash | T1550.002 |
| Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay | T1557.001 |
| OS Credential Dumping: LSASS Memory | T1003.001 |
| OS Credential Dumping: Security Account Manager | T1003.002 |
11. Practical Lab
In an isolated lab:
- Enable NTLM auditing via Group Policy on a member server and a DC.
- Access a share by IP address and observe the resulting NTLM event; then access by hostname and observe Kerberos instead.
- Set the LAN Manager authentication level to level 5 and confirm legacy NTLMv1 clients are refused.
- Deploy LAPS on two lab workstations and verify their local admin passwords differ, breaking hash reuse between them.
- Build a SIEM rule from Event 8004 that surfaces NTLMv1 and validate it in the lab only.
12. Key Takeaways
- The NT hash is password-equivalent — stealing it is enough; cracking is optional. LAPS and Credential Guard are the structural fixes.
- NTLM’s lack of server binding makes it relayable; SMB signing and LDAP channel binding are the transport defences.
- Audit NTLM usage before restricting it, then eliminate NTLMv1 first (LAN Manager level 5).
- Prefer Kerberos by using SPNs/hostnames; NTLM fallback is often just a name-resolution or IP-access habit.
Continue learning: Active Directory security
This guide is part of our Active Directory Security series. Related guides: