During recent red-team engagements, I have consistently observed that NTLM (NT LAN Manager) remains the path of least resistance for lateral movement and credential theft, even in hardened Windows 11 environments. While Microsoft has made strides in promoting Kerberos, NTLM's backward compatibility ensures it remains active for IP-based connections, workgroup environments, and legacy application support.
The Persistence of NTLM in Modern Infrastructures
I often find that administrators assume NTLM is "off" because they have a functional Kerberos environment. This is a dangerous misconception. Windows defaults to NTLM whenever a hostname cannot be resolved via DNS or when a user connects via an IP address instead of a FQDN (Fully Qualified Domain Name). This "fail-back" mechanism is the primary facilitator for NTLM hash disclosure.
When a client attempts to authenticate via NTLM, it follows a three-way handshake: NEGOTIATE, CHALLENGE, and AUTHENTICATE. The vulnerability lies in the fact that a client will initiate this handshake with any server that requests it, including rogue servers controlled by an attacker. If I can trick a machine into connecting to my listener, I can capture the NTLMv2 response, which contains the user’s hashed credentials.
NTLMv2 Hash Structure and Cracking Difficulty
The NTLMv2 response is not a simple hash of the password. It is an HMAC-MD5 of the username, domain, and the server's challenge, keyed with the NT hash. While NTLMv2 is significantly more resistant to rainbow table attacks than NTLMv1, it remains highly susceptible to offline brute-forcing using tools like Hashcat or John the Ripper. In the Indian context, where many organizations still use weak, predictable passwords (e.g., "Company@123"), a captured NTLMv2 hash is often cracked within minutes on a modest GPU rig.
Common Attack Vectors for NTLM Hash Theft
The most frequent method I use to trigger NTLM leaks is through name resolution poisoning. In a default Windows environment, if DNS resolution fails, the system falls back to Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS). By spoofing these protocols, an attacker can convince a victim machine that they are the intended destination for a network resource.
LLMNR, NBT-NS, and mDNS Poisoning
I use tools like Responder to listen for these multicast queries. When a user mistypes a file share path (e.g., \\fileserber\share), the client broadcasts an LLMNR request. Responder answers, claiming to be "fileserber," and prompts the client for NTLM authentication. The client then dutifully sends its NTLMv2 hash to the attacker.
# Example: Running Responder to capture NTLM hashes on a local network
$ sudo responder -I eth0 -rdv [+] Listening for events... [] [LLMNR] Poisoned answer sent to 192.168.1.15 for name FILESERBER [] [NTLMv2] saved hash for USER1: 192.168.1.15:54321:CLIENT_CHALLENGE:RESPONSE...
Forced Authentication via CVE-2021-36942 (PetitPotam)
Coerced authentication is a more aggressive tactic. Vulnerabilities like PetitPotam, documented in the NIST NVD, allow an unauthenticated attacker to call the EfsRpcOpenFileRaw method on a remote system, forcing that system to authenticate against an arbitrary IP address. This is particularly devastating when targeting Domain Controllers to capture their machine account hashes, which can then be used in NTLM Relay attacks against the AD CS (Active Directory Certificate Services) web enrollment endpoints.
Outlook Leaks: CVE-2023-23397 and CVE-2024-21413
In 2023 and 2024, we saw a resurgence of "zero-click" NTLM leaks via Microsoft Outlook. CVE-2023-23397 exploited the PidLidReminderFileParameter, allowing an attacker to trigger an NTLM connection simply by sending a specially crafted email with a custom reminder sound path pointing to a remote UNC share. CVE-2024-21413 (MonikerLink) improved upon this by bypassing Protected View using the file:// URI scheme combined with a ! character, forcing the client to leak credentials when a link is clicked.
Detection Strategies: Analyzing Windows Event Logs
Effective detection starts with visibility. By default, Windows does not log successful NTLM authentications in a way that is easily auditable. I recommend enabling the "Audit NTLM Authentication" policy under Security Settings -> Local Policies -> Security Options.
Monitoring Event ID 4648 (Explicit Credentials)
This event is triggered when a process attempts to log on an account by explicitly specifying that account’s credentials. This is common in "RunAs" scenarios but is also a high-fidelity indicator of NTLM leakage if the Server Name field points to an external or unknown IP address. We can query these events using wevtutil:
# Query the last 10 instances of explicit credential usage
wevtutil qe Security /q:"*[System[(EventID=4648)]]" /f:text /c:10
Enabling NTLM Operational Logs
The Microsoft-Windows-NTLM/Operational log is the most granular source of NTLM data. Event ID 8001 records every successful NTLM authentication. I use this to identify which applications are still relying on NTLM and where they are sending those credentials. To view these logs via PowerShell:
# PowerShell command to extract NTLM authentication details
Note: Requires NTLM auditing to be enabled via GPO first
Get-WinEvent -LogName 'Microsoft-Windows-NTLM/Operational' | Where-Object {$_.Id -eq 8001} | Select-Object -First 5 | Format-List
Detecting LLMNR/NetBIOS Spoofing with Canary Entries
A proactive detection technique I implement involves "Canary" service records. I create a non-existent DNS entry (e.g., SRV-PROD-BACKUP-01) and monitor for any LLMNR or NBT-NS traffic requesting that name. Since the name doesn't exist, any broadcast request for it is either a typo or an attacker's tool probing the network. If I see a response to that request from an unauthorized IP, I know a poisoning attack is in progress.
Implementing SIEM Rules for Real-Time Detection
A SIEM is only as good as its logic. For NTLM leak detection, I focus on outbound SMB traffic (Port 445) destined for non-internal IP ranges. In many Indian SMEs, I observe that egress filtering is non-existent, allowing internal workstations to initiate SMB connections directly to the public internet.
Sigma Rule: Outbound SMB NTLM Leak Detection
This rule monitors for Sysmon Event ID 3 (Network Connection) where the destination port is 445 and the destination IP is not within the standard RFC1918 private ranges. This is a high-confidence indicator of an NTLM leak occurring via a malicious UNC link. For more advanced detection logic, see our guide on implementing SIEM rules to detect C2 traffic.
title: Outbound SMB NTLM Leak Detection
status: experimental description: Detects outbound SMB connections to non-private IP addresses, often indicating NTLM hash leakage. logsource: product: windows service: sysmon detection: selection: EventID: 3 DestinationPort: 445 filter_internal_ips: DestinationIp|startswith: - '10.' - '192.168.' - '172.16.' - '172.17.' - '172.18.' - '172.19.' - '172.20.' - '172.21.' - '172.22.' - '172.23.' - '172.24.' - '172.25.' - '172.26.' - '172.27.' - '172.28.' - '172.29.' - '172.30.' - '172.31.' condition: selection and not filter_internal_ips level: high
Identifying Anomalous Authentication Spikes
I also look for "Authentication Volatility." If a single source IP initiates NTLM handshakes with 50 different internal hosts within a 5-minute window (Event ID 4624, Logon Type 3), it is a clear sign of an NTLM Relay attack or an internal scan using tools like CME (CrackMapExec). I set thresholds in the SIEM to trigger an alert when the unique count of TargetMachineName exceeds a baseline for a given SourceIp.
The Indian Context: Legacy Infrastructure and Compliance
In the Indian market, particularly within Tier-2 and Tier-3 cities, I frequently encounter infrastructures built around legacy accounting software like older versions of Tally or localized ERP systems. These applications often require SMBv1 or NTLMv1 for inter-departmental data sharing. This creates a significant security gap.
The Impact of DPDP Act 2023
With the enforcement of the Digital Personal Data Protection (DPDP) Act 2023, Indian organizations are now legally obligated to implement "reasonable security safeguards" to prevent personal data breaches, similar to those outlined in the OWASP Top 10. Allowing NTLM hashes to leak to the internet—which can lead to full domain compromise—could be interpreted as a failure to maintain such safeguards. Fines for non-compliance under the DPDP Act can reach up to ₹250 crore, making NTLM security not just a technical requirement but a financial imperative.
ISP Egress Realities
I have observed that many local Indian ISPs (Internet Service Providers) do not block outbound Port 445 at the gateway level. In more mature markets, ISPs often block this port by default to prevent the spread of worms like WannaCry. Because of this lack of ISP-level filtering, a single mistyped UNC path in a Mumbai office can result in a hash being captured by a listener in Eastern Europe.
Advanced Detection: Network-Level Analysis
While host logs are valuable, network-level detection provides an independent layer of verification. I use Network Intrusion Detection Systems (NIDS) like Zeek or Suricata to identify anomalous NTLM handshakes.
Analyzing Handshake Metadata
Zeek's ntlm.log provides visibility into the domainname, hostname, and success status of every NTLM attempt. I look for NTLM authentications where the hostname field does not match the SourceIp's known hostname, which often indicates a spoofing tool like Responder is in use. Additionally, seeing NTLM traffic over non-standard ports (e.g., 80, 8080) suggests NTLM-over-HTTP, a common technique for bypassing simple firewall rules.
# Using Nmap to audit SMB security modes across a subnet
This identifies hosts where SMB signing is NOT required, making them targets for NTLM Relay
$ nmap -p 445 --script smb-security-mode 10.0.0.0/24 PORT STATE SERVICE 445/tcp open microsoft-ds | smb-security-mode: | account_used: guest | authentication_level: user | challenge_response: supported |_ message_signing: disabled (dangerous, but default)
Mitigation and Prevention: Moving Beyond Detection
Detection is a reactive measure. To truly secure an environment, I advocate for a "Disable by Default" approach to legacy protocols. The goal is to shrink the NTLM attack surface until the protocol can be decommissioned entirely. For organizations moving toward zero-trust, implementing secure SSH access for teams can reduce the reliance on legacy protocols for administrative tasks.
Disabling LLMNR and NetBIOS
These protocols are the primary source of internal hash disclosure. I disable them via Group Policy (GPO):
- LLMNR: Computer Configuration -> Administrative Templates -> Network -> DNS Client -> "Turn off Multicast Name Resolution" (Set to Enabled).
- NetBIOS: This must be done per interface or via DHCP Option 46. In the registry, it can be disabled by setting
NetbiosOptionsto 2 underHKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\{InterfaceID}.
Restricting Outbound NTLM
Introduced in newer versions of Windows 10 and 11, the "Restrict usage of NTLM: Outbound NTLM traffic to remote servers" policy is a game-changer. I configure this to "Audit All" first to identify dependencies, then move to "Block All." This prevents the OS from even attempting an NTLM handshake with an external IP.
# Check the current registry status of outbound NTLM restriction
reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 /v RestrictSendingNTLMTraffic
Enforcing SMB Signing
NTLM Relay attacks are only possible if SMB signing is not enforced. I ensure that "Microsoft network server: Digitally sign communications (always)" is set to Enabled on all workstations and servers. While this introduces a minor CPU overhead (usually negligible on modern hardware), it completely neutralizes the threat of NTLM relaying to SMB.
Transitioning to Kerberos and Modern Auth
The long-term solution is the elimination of NTLM. I recommend implementing "Protected Users" security groups in Active Directory. Members of this group are prohibited from using NTLM, Digest Authentication, or CredSSP, forcing the use of Kerberos. I start by adding Domain Admins to this group, as their hashes are the highest-value targets for any attacker.
For external-facing applications, I push for the adoption of modern authentication protocols like SAML or OIDC (OpenID Connect). These protocols do not rely on password hashes and are inherently resistant to the relay and disclosure attacks that plague NTLM.
# Final check: Monitor active connections to Port 445 to find NTLM outliers
powershell.exe -Command "Get-NetTCPConnection -RemotePort 445 | Select-Object LocalAddress, RemoteAddress, State"
By combining granular event logging, SIEM-based behavioral analysis, and aggressive GPO-driven protocol hardening, we can transform NTLM from a silent liability into a highly visible and defensible component of the enterprise network.