¶ KBA-027 - NTLM Authentication and Security Risks
Summary: NTLM is a legacy challenge-response protocol used as Kerberos fallback; it carries significant security risks including pass-the-hash, relay attacks, and offline cracking.
¶ What is NTLM and When It Is Used
NTLM (NT LAN Manager) is Microsoft's pre-Kerberos authentication protocol. While AD environments prefer Kerberos, NTLM is used as an automatic fallback in:
- Direct IP address connections (no DNS name → no SPN → no Kerberos)
- Missing or incorrect SPN registration
- Workgroup computers (no domain membership)
- Standalone servers without DC connectivity
- Cross-forest or external trust scenarios without transitive trust
- Some legacy applications hardcoded to use NTLM
- Response computed using DES from the NT hash and the server challenge
- Vulnerable to offline brute force and rainbow table attacks
- Should be disabled in all modern environments
- Not enabled by default on Windows 10/2016+
- Response uses HMAC-MD5
- Includes a client challenge and timestamp, preventing replay attacks
- Stronger than v1 but still inferior to Kerberos
- Still vulnerable to pass-the-hash and relay attacks
1. Client → Server NEGOTIATE_MESSAGE (client capability flags)
2. Server → Client CHALLENGE_MESSAGE (8-byte server nonce)
3. Client → Server AUTHENTICATE_MESSAGE (response computed from hash + challenge)
4. Server validates response (locally or via DC pass-through)
The server never receives the plaintext password — only the hash-derived response. This is the source of the pass-the-hash vulnerability: if an attacker has the hash, they can compute a valid response.
- Attacker extracts the NT hash from LSASS memory or SAM database
- Uses hash directly in AUTHENTICATE_MESSAGE without knowing the plaintext password
- Grants access to any service accepting NTLM with that account
Mitigations:
- Enable Credential Guard (Windows 10 1507+ with UEFI Secure Boot) — isolates LSASS in a virtualisation-based security enclave
- Apply Protected Users security group — members cannot authenticate with NTLM, only Kerberos
- Enable LSA Protection (
RunAsPPL) — prevents LSASS memory dumps by unprivileged processes
- Restrict local admin account reuse across machines (unique local admin passwords per machine via LAPS)
- Attacker intercepts an NTLM authentication attempt and relays it to a target server
- Target believes the connection is from the legitimate client
- Common tools: Responder, ntlmrelayx
Mitigations:
- Enable SMB Signing on all domain members (required by default on DCs, optional on workstations)
- Enable LDAP Signing and Channel Binding on DCs
- Use EPA (Extended Protection for Authentication) for HTTP services
- Block LLMNR and NetBIOS-NS to prevent hash capture
- Captured NTLM hashes can be cracked offline using GPU-accelerated tools
- NTLMv2 is slower to crack than NTLMv1 but weak passwords remain vulnerable
Mitigations:
- Enforce strong password policy (minimum 12+ characters, complexity)
- Use account lockout policy
- Rotate service account passwords regularly or use gMSA
Navigate to: Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options
Network security: LAN Manager authentication level
Set to: Send NTLMv2 response only. Refuse LM & NTLM
This disables NTLMv1 and LM completely, enforcing NTLMv2 minimum.
Network security: Restrict NTLM: Incoming NTLM traffic
Deny all domain accounts — servers reject NTLM from domain users (must use Kerberos)Deny all accounts — all NTLM rejected (aggressive; test before deploying)
Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers
Deny all — clients cannot initiate NTLM connections
¶ Domain-Wide NTLM Restriction
Network security: Restrict NTLM: NTLM authentication in this domain
Deny for domain accounts to domain servers — forces Kerberos for all domain trafficAudit all — log all NTLM usage first before blocking (recommended first step)
Enable NTLM audit logging before restricting — identifies services that still rely on NTLM:
auditpol /set /subcategory:"Audit Logon" /success:enable /failure:enable
Enable NTLM operational log:
wevtutil set-log Microsoft-Windows-NTLM/Operational /enabled:true
Key Event IDs:
- 4776 (DC) — NTLM authentication attempt; shows source workstation
- 4624 (member server) — successful logon; check Authentication Package field
Review DC Security log for event 4776 to build a list of systems and services still using NTLM before deploying restrictions.