What Is NTLM? Windows NTLM Security Risks & Migration Guide

NTLM is a Windows authentication protocol with critical vulnerabilities. Learn about Pass-the-Hash attacks, relay risks, and migration before October 2026.

What Is NTLM?

NTLM (NT LAN Manager) is a Windows authentication protocol that validates users through challenge-response authentication without transmitting passwords across networks. According to Microsoft's official documentation, NTLM encompasses multiple protocol versions including the legacy LAN Manager, NTLMv1, and the current NTLMv2 standard. While Kerberos replaced NTLM as the preferred authentication method for Active Directory environments over two decades ago, NTLM remains active in enterprise networks for workgroup authentication, local logons on non-domain controllers, and scenarios where Kerberos negotiation fails.

The challenge-response process works through a straightforward exchange. When you connect to a network resource, the server sends your client a 16-byte challenge. Your system encrypts this challenge using your password hash and sends the response back to the server, which validates these credentials against the Security Accounts Manager database or Active Directory. Authentication completes with only encrypted hashes transmitted, never your actual password. This design choice, treating hashes as proof of identity, created the security vulnerabilities that attackers exploit today.

Why NTLM Is a Security Risk

Credential theft statistics show that 31% of all breaches over the past decade involved credential theft, according to the Verizon 2025 Data Breach Investigations Report. NTLM attacks represent a significant component of this persistent threat landscape because the protocol stores password hashes that attackers can steal and reuse without ever cracking the actual password.

Attackers extract NTLM hashes from memory or network traffic, then authenticate to file servers and domain controllers by passing stolen hashes directly to Windows. Your security controls see legitimate NTLM authentication while the attack unfolds invisibly.

CISA added CVE-2025-24054, a Windows NTLM hash disclosure vulnerability, to its Known Exploited Vulnerabilities catalog in March 2025 following confirmed active exploitation. Although Microsoft patched the vulnerability in March 2025, the attack surface persists because NTLM deprecation requires coordinated migration across identity infrastructure, applications, and network services. This timeline is particularly important given Microsoft's October 2026 deadline for automatic NTLMv1 enforcement.

How NTLM Authentication Works

NTLM's architecture reveals why attackers succeed against your environment and why migration presents significant complexity.

• Authentication package and hash storage: The MSV1_0 authentication package handles all NTLM authentication through the Msv1_0.dll component. Compromise LSASS memory and attackers extract password hashes directly. Your environment stores two hash types: LM hash uses broken DES encryption without case sensitivity, enabling trivial rainbow table attacks, while NT hash uses MD4 with case sensitivity. Both reside in SAM or Active Directory and function as authentication credentials themselves: no password cracking required.
• Challenge-response mechanism: The server generates a 16-byte random challenge, your workstation encrypts it using your password hash, and the server validates the response through the LsaLogonUser API. NTLMv2 uses HMAC-MD5-based response calculation with additional random data, providing stronger cryptographic protection. Both protocols share a fundamental vulnerability: password hashes function as authentication credentials themselves (MITRE ATT&CK T1550.002).
• LAN Manager authentication levels: Registry key HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel determines which NTLM versions your systems accept. Most enterprises run Level 3 (Send NTLMv2 response only) versus NIST-recommended Level 5 (refuse LM and NTLM entirely), creating exploitable gaps.

These architectural components, particularly hash storage in LSASS memory and the pass-through authentication mechanism, give attackers multiple opportunities to intercept or extract credentials.

NTLM Attack Tools and Techniques

Attackers use specialized tools to exploit NTLM vulnerabilities for credential theft and lateral movement. Understanding these tools helps defenders recognize attack patterns and implement appropriate controls.

• Credential extraction tools target LSASS memory where Windows stores password hashes during active sessions. Mimikatz remains the most recognized tool, using techniques like sekurlsa::logonpasswords to dump credentials from memory. Attackers also use Windows-native methods including reg save commands to export SAM and SYSTEM registry hives for offline hash extraction. Memory forensics tools like WCE (Windows Credentials Editor) provide additional extraction capabilities that evade some endpoint detection solutions.
• Pass-the-Hash frameworks enable authentication using stolen hashes without requiring password cracking. Impacket's Python-based toolkit includes psexec.py and wmiexec.py modules that accept NTLM hashes directly for remote command execution against Windows systems. CrackMapExec automates Pass-the-Hash attacks across multiple targets simultaneously, enabling rapid lateral movement through enterprise networks while logging successful authentications for further exploitation. These frameworks integrate hash spraying capabilities to identify systems accepting compromised credentials.
• NTLM relay toolkits intercept and forward authentication requests to unauthorized target systems. Responder captures NTLM authentication by poisoning LLMNR, NBT-NS, and MDNS name resolution responses on local network segments. When systems attempt to resolve hostnames, Responder answers with attacker-controlled IP addresses, capturing authentication attempts. The ntlmrelayx module from Impacket relays captured authentication to SMB, LDAP, HTTP, and MSSQL services, enabling privilege escalation when Extended Protection for Authentication remains disabled on critical services.
• Coercion techniques force target systems to initiate authentication toward attacker-controlled servers without user interaction. PetitPotam exploits the MS-EFSRPC interface to coerce domain controllers into authenticating to arbitrary destinations, enabling direct credential capture or relay attacks against Active Directory Certificate Services. PrinterBug (also called SpoolSample) abuses the Print Spooler service's remote interface to achieve similar coerced authentication. These techniques bypass traditional phishing requirements entirely, enabling credential theft from systems that never interact with malicious content.

Defensive detection focuses on monitoring for tool signatures in memory, abnormal LSASS access patterns, unexpected authentication flows, and network traffic indicating relay attempts. However, detection alone cannot address the underlying protocol weaknesses that make these attacks possible.

NTLM Vulnerabilities

The protocol's architectural weaknesses create persistent security gaps that defender-side controls alone cannot fully address without complementary network-level and identity-based protections.

• Pass-the-Hash attacks (MITRE ATT&CK T1550.002) exploit NTLM's reliance on password hashes as authentication credentials. Once attackers extract your hash from LSASS memory, the SAM database, or network captures, they authenticate as you without knowing your password. Credential Guard provides partial protection through virtualization-based security on Windows 10 Enterprise or Windows 11 systems with TPM 2.0 hardware. Network-level protections such as SMB signing, LDAP signing, and Extended Protection for Authentication stop NTLM relay attacks.
• NTLM relay attacks manipulate the challenge-response mechanism by intercepting authentication between client and server. The attacker receives your authentication attempt, relays it to a target system of their choosing, and obtains unauthorized access using your credentials in real time. Extended Protection for Authentication stops relay attacks through channel binding, but requires explicit configuration on Exchange Server, Active Directory Certificate Services, and LDAP. Most enterprises run these critical services without EPA enabled because Microsoft historically shipped products with EPA disabled by default.
• Cryptographic weaknesses in legacy versions persist in production environments. LM hashes use DES encryption, a cryptographically broken algorithm, while converting passwords to uppercase and splitting them into 7-character chunks. NTLMv1 improves cryptographic strength but remains vulnerable to offline brute-force attacks. Only NTLMv2 provides modern cryptographic protections, yet many organizations run mixed environments accepting NTLMv1 for backward compatibility.

The October 2026 enforcement deadline creates operational risk for organizations that delayed migration. Microsoft established a three-phase timeline:

1. Phase 1 (December 2024): Initiated deprecation
2. Phase 2 (September 2025): Enabled audit mode by default
3. Phase 3 (October 2026): Automatically transitions BlockNtlmv1SSO registry key to enforce mode without administrator intervention

Organizations that haven't started migration planning face significant risk of authentication disruptions when enforcement begins.

How to Migrate Away from NTLM

Enterprise NTLM migration requires structured phased execution with executive sponsorship. Complete implementation typically spans 18-22 months depending on environment complexity and legacy application dependencies.

Phase 1: Discovery and audit (months 1-3)

Enable complete NTLM auditing across all domain controllers and member servers before attempting any migration or blocking policies. Configure Network security: Restrict NTLM: Audit NTLM authentication in this domain to "Audit all" rather than blocking. Windows 11 24H2 and Windows Server 2025 provide enhanced audit events capturing process names, reason codes, username and domain information, and NTLM version. Collect audit logs for 30-90 days minimum to capture periodic services, scheduled tasks, and monthly processes. Analyze logs to build a complete dependency inventory categorized by system type, application, and remediation complexity.

Phase 2: Remediation planning (months 4-6)

Categorize NTLM dependencies by remediation approach and complexity. Workgroup-joined systems may require domain joining, Azure AD registration, or continued exception with network segmentation. Legacy applications need vendor engagement for Kerberos support timelines or application replacement planning if vendors cannot provide migration paths. Network devices with firmware limitations require upgrade scheduling, replacement procurement, or network segmentation strategies isolating NTLM traffic.

Phase 3: Pilot Kerberos deployments (months 7-9)

Select low-risk organizational units with minimal legacy dependencies for initial Kerberos-only enforcement. Configure Network security: Restrict NTLM: NTLM authentication in this domain to "Deny all" in pilot scope only. Monitor authentication failures and application issues closely, documenting all remediation procedures for production rollout reference. Validate that pilot systems maintain full functionality without NTLM authentication.

Phase 4: Production rollout (months 10-18)

Expand Kerberos enforcement systematically by organizational unit based on pilot learnings. Prioritize high-security environments containing sensitive data and privileged access systems. Maintain documented exception lists for legacy dependencies with compensating controls including network segmentation, enhanced monitoring, and restricted access scope. Implement network segmentation for systems requiring continued NTLM access to limit lateral movement exposure.

Phase 5: Enforcement (months 19-22)

Enable BlockNtlmv1SSO before Microsoft's October 2026 automatic enforcement deadline. Validate complete migration through thorough audit log review confirming zero NTLM authentication in production scope. Document remaining exceptions with formal risk acceptance and compensating controls for compliance and audit purposes.

While planning migration, organizations must also address immediate defensive gaps. Many security teams inadvertently leave their environments exposed through incomplete or misconfigured protections.

Common NTLM Defense Mistakes

Failing to implement layered NTLM defenses creates exploitable security gaps.

1. Enabling SMB signing without requiring it. You configure Group Policy to enable the "Microsoft network server: Digitally sign communications" setting across your file servers while overlooking the complementary client-side requirement. The configuration audit shows compliant on servers, yet your penetration tester demonstrates successful NTLM relay attacks because "enable" permits downgrade to unsigned connections when clients don't request signing. Both configurations must be set to "Enabled" simultaneously: server-side (Microsoft network server: Digitally sign communications (always)) AND client-side (Microsoft network client: Digitally sign communications (always)). According to Microsoft SMB security guidance, configuring only servers creates an exploitable gap where attackers relay through misconfigured clients.
2. Assuming Credential Guard stops NTLM relay attacks. You deploy Credential Guard to high-value administrative workstations and domain controllers, then present Credential Guard coverage to executive leadership as complete NTLM attack protection. An attacker compromises your environment through NTLM relay against an unprotected LDAP service on a domain controller. Credential Guard protects credentials at rest in LSASS memory using virtualization-based security, preventing credential theft from compromised systems, but provides zero protection against network-level NTLM relay attacks. Organizations must implement both endpoint credential protection and network-level relay prevention simultaneously.
3. Implementing EPA inconsistently across critical services. Your security team enabled Extended Protection for Authentication on Active Directory Certificate Services following PetitPotam in 2021, yet attackers relay NTLM authentication to your LDAP service, which runs without EPA enabled. EPA must be configured across all NTLM-capable services including AD CS, LDAP, Exchange Server, and any custom applications using Windows Integrated Authentication.

Avoiding these mistakes requires a systematic approach to NTLM defense that addresses all attack vectors simultaneously.

NTLM Defense Best Practices

Stop credential-based lateral movement through layered controls that address protocol weaknesses at network, endpoint, and identity layers.

• Implement complete NTLM audit logging immediately. Enable NTLM auditing policies across all domain controllers and member servers before attempting any migration or blocking policies. Configure Network security: Restrict NTLM: Audit NTLM authentication in this domain to "Audit all" rather than blocking. Collect audit logs for 30-90 days minimum to capture periodic services and scheduled tasks, then analyze logs to build a complete dependency inventory.
• Enforce SMB signing universally across your environment. Configure dual Group Policy requirements at Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options. Set both Microsoft network server: Digitally sign communications (always) and Microsoft network client: Digitally sign communications (always) to Enabled. The dual configuration stops downgrade attacks where clients and servers use different signing settings.
• Configure Extended Protection for Authentication on all critical services. EPA adds channel binding to NTLM authentication, preventing credential relay by binding authentication to the TLS session. EPA implementation priority should focus on Active Directory Certificate Services, LDAP on all domain controllers, and Exchange Server. Windows Server 2025 enables EPA by default for these services.
• Deploy Credential Guard to high-value systems. Implement Credential Guard on domain controllers, administrative workstations, and systems processing sensitive data. Credential Guard requires TPM 2.0, UEFI Secure Boot, processor virtualization extensions, and Hyper-V support.
• Require LDAP signing on all domain controllers. Configure Domain controller: LDAP server signing requirements to "Require signing" through Group Policy applied to the Domain Controllers organizational unit. Windows Server 2025 adds LDAP channel binding by default.
• Implement event correlation for Pass-the-Hash identification. Configure your SIEM to correlate Windows Security Event IDs across multiple domain controllers and member servers. Alert on Event ID 4624 (successful logon) with Logon Type 3 (network logon) and authentication package "NTLM" for privileged accounts WITHOUT corresponding Event ID 4624 Logon Type 2 (interactive logon) within the prior 10 hours from the same source IP.

These manual controls provide essential protection, but credential-based attacks often move faster than human investigation cycles. Behavioral AI can identify and stop Pass-the-Hash activity in real time.

Stop NTLM Attacks with SentinelOne

Your response latency determines whether you stop lateral movement or investigate the breach aftermath. SentinelOne finds credential-based attacks through behavioral AI that recognizes Pass-the-Hash techniques classified as MITRE ATT&CK T1550.002.

Singularity™ Identity also provides end-to-end visibility across hybrid environments to detect exposures and stop credential abuse. It reduces identity risks and offers real-time identity protection. You can correlate endpoint and identity activity for context-driven detection and faster triage. It also eliminates blind spots across siloed environments and can harden Active Directory and cloud identity providers, including Okta, Ping, SecureAuth, Duo, and Entra ID. It can gather insights from attempted attacks to stop repeated compromises and prevent privilege escalation.

SentinelOne is recognized as a Gartner Magic Quadrant Leader for Endpoint Protection Platforms for five consecutive years. In MITRE ATT&CK evaluations, SentinelOne generated only 12 alerts while a leading competitor generated 178,000, representing 88% fewer alerts. This noise reduction consolidates thousands of security events into single actionable incidents, transforming credential abuse investigation from reviewing thousands of authentication events to analyzing complete forensic context in seconds.

The Singularity Platform delivers unified XDR capabilities through a single agent and console, consolidating endpoint, cloud, and identity security into one data lake. Patented Storyline technology automatically monitors, tracks, and contextualizes event data across your enterprise environment to reconstruct attacks in real time.

Purple AI accelerates threat investigations through natural language queries that correlate authentication events across your environment. With up to 80% faster threat hunting as reported by early adopters, security analysts can search logs without knowing query languages and receive complete attack context with suggested next steps.

Request a demo to see how SentinelOne's behavioral AI stops credential-based attacks before privilege escalation.

Key Takeaways

NTLM attacks exploit credential theft to enable lateral movement before traditional response can stop them. The October 2026 enforcement deadline requires immediate migration planning: Microsoft will automatically enforce NTLMv1 blocking by changing the BlockNtlmv1SSO registry key from audit mode to enforce mode without administrator intervention.

Effective defense demands complementary layered controls: SMB signing on both servers and clients, Extended Protection for Authentication on critical services including AD CS, LDAP, and Exchange Server, Credential Guard for endpoint credential protection (noting it protects credentials at rest but does NOT stop network relay attacks), and complete audit logging to identify dependencies before enforcement.

Behavioral AI that correlates authentication patterns across endpoints and identity infrastructure finds credential abuse before privilege escalation occurs.

FAQs

What is NTLM?

NTLM (NT LAN Manager) is a Windows authentication protocol that validates users through a challenge-response mechanism without transmitting passwords across networks. The server sends a random challenge, the client encrypts it with the user's password hash, and the server validates the response. 

While Kerberos replaced NTLM as the preferred authentication method for Active Directory, NTLM remains active in workgroup environments, local logons, and legacy application scenarios.

What is the difference between NTLMv1 and NTLMv2?

NTLMv1 uses weaker cryptography vulnerable to offline brute-force attacks and known-plaintext attacks. NTLMv2 incorporates HMAC-MD5-based response calculation with random data and channel binding capabilities, providing significantly stronger cryptographic protection. 

Microsoft will automatically enforce NTLMv1 blocking in October 2026, requiring all systems to use NTLMv2 minimum or migrate to Kerberos.

Can you completely disable NTLM in enterprise environments?

Complete NTLM elimination remains difficult due to dependencies on workgroup-joined systems, legacy applications lacking Kerberos support, network devices with firmware limitations, and cross-forest authentication scenarios. 

Windows Server 2025 introduces the capability to disable SMB NTLM entirely for remote outbound connections. Complete deprecation requires application remediation, hardware replacement, and thorough testing over 18-22 month migration timelines.

How do Pass-the-Hash attacks work?

Attackers use tools like Mimikatz to extract NTLM hashes from LSASS memory. The hash, a 16-byte MD4 representation of your password, functions as an authentication credential itself. When Windows authenticates using NTLM, it compares encrypted challenge responses, not passwords. 

Since the attacker possesses the hash that generates valid responses, Windows cannot distinguish between legitimate authentication and Pass-the-Hash attacks without additional controls like Credential Guard or EPA.

What is Extended Protection for Authentication and why does it matter?

Extended Protection for Authentication adds channel binding to NTLM authentication by binding authentication tokens to the TLS session between client and server. This binding makes relayed credentials unusable even if intercepted because the channel binding tokens won't match when the attacker attempts to relay them to different servers. 

EPA stops NTLM relay attacks targeting AD CS, LDAP, Exchange Server, and other Windows-integrated authentication services. Windows Server 2025 enables EPA by default on critical services.