NTLMv2 is targeted by relay, pass-the-hash, credential capture and downgrade attacks when better authentication is unavailable or misconfigured. Attackers exploit systems that still accept NTLM, especially where signing, channel protection or mutual authentication is weak. Defenders should inventory NTLM use, restrict where it is allowed, and investigate unexpected NTLM authentication flows.
How NTLMv2 gets attacked
NTLMv2 is rarely the real target by itself. It is targeted because it still appears in legacy or misconfigured environments, and because attackers can abuse it as an authentication bridge when stronger methods are unavailable, disabled, or inconsistently enforced. The practical question is not whether NTLMv2 is “broken” in the abstract, but where it remains reachable and what trust assumptions it still inherits from the surrounding Windows environment.
Relay attacks are the most important pattern to understand. If a system accepts NTLM authentication without strong channel protections or mutual authentication, an attacker can relay the victim’s authentication exchange to another service that trusts NTLM. That makes the weakness less about cracking the protocol and more about abusing a valid authentication flow before it reaches the intended service.
Pass-the-hash attacks are related but different. In that case, the attacker reuses captured NTLM material to authenticate without knowing the underlying password. Credential capture techniques, including coercion, endpoint compromise, or traffic interception where protections are weak, can feed into this. Downgrade attacks matter because environments that still permit weaker negotiation paths can be pushed toward the least resistant option, exposing older authentication flows that defenders thought were already retired.
For broader identity hardening, Active Directory and Entra ID Hardening Guide is the most useful starting point because NTLM exposure is usually a directory and trust-boundary problem, not just a protocol problem.
Where NTLMv2 exposure usually comes from
The common failure mode is not one dramatic NTLMv2 flaw, but inconsistent control enforcement. Systems that still accept NTLM for fallback, applications that depend on integrated Windows authentication, and service paths that do not require signing or mutual authentication all widen the attack surface. In those conditions, an attacker does not need to “break” NTLMv2, only to find a place where the environment still treats it as an acceptable proof of identity.
Inventory is the first practical step because many organisations underestimate how much NTLM is still in use. Some authentication flows are buried in line-of-business apps, legacy file access, printer services, or older domain dependencies. If defenders only look at user logons, they can miss machine-to-service or service-to-service flows that still rely on NTLMv2 and are easier to abuse than modern federated or certificate-based paths.
Where NTLM must remain enabled, its risk is highest when the environment allows weak negotiation, lacks signing, or does not bind the authentication to the target service. That is why unexpected NTLM authentication should be treated as a signal, not just a compatibility event. It can indicate legacy fallback, misconfiguration, or an active attempt to coerce a weaker path for relay or credential capture.
For threat context around observed abuse patterns, The State of NHI & AI Agent Breach Report 2026 is useful because the same attacker logic, stolen credentials, lateral movement, and misuse of trust also shows up in identity abuse more broadly.
What defenders should do about NTLMv2 attacks
The most effective response is to reduce where NTLM exists, then constrain the places where it cannot yet be removed. That means identifying the systems and services that still negotiate NTLM, restricting where it is allowed, and forcing stronger authentication where the business process can support it. The goal is not a symbolic ban, but a controlled retirement path that does not break critical dependencies overnight.
When patching or redesign cannot happen immediately, focus on making relay and credential abuse harder. Enforce signing where supported, harden channel protection, prefer mutual authentication where the protocol stack allows it, and remove unnecessary fallback paths. Also watch for repeated NTLM attempts from unusual hosts, services that should never speak NTLM, and authentication patterns that move across trust boundaries in ways the application owner cannot explain.
Unexpected NTLM flows deserve incident-style triage if they appear in places that should already be using modern authentication. They can reveal compromise, shadow dependencies, or a failed migration that has left a hidden path open for relays or replay of captured material. If the authentication path exposes reusable secrets or cached credentials, rotate the affected credentials and review whether the same identity is trusted in more than one system.
Risk and Threat Considerations
NTLMv2 becomes materially risky when it is allowed to survive as a fallback trust path. Attackers prefer it because relay and pass-the-hash techniques can turn a valid authentication exchange into unauthorized access without needing to defeat the password directly. The danger increases when the environment lacks signing, channel binding, or mutual authentication, because the protocol then gives the attacker more room to reuse trust.
Failure mechanism: A host or service accepts NTLMv2 where stronger authentication should have been required, allowing the exchange to be relayed, replayed, or reused after capture.
Impact: The attacker may gain authenticated access to downstream services, move laterally, or abuse the same identity across multiple systems until the fallback path is removed and the exposed credential material is rotated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | NTLMv2 abuse targets how users and admins authenticate across systems. |
| IA-5 — Authenticator Management | NTLMv2 attacks often involve captured or reusable credential material. | |
| IA-9 — Identification and Authentication (Non-Organizational Users) | NTLMv2 relay and reuse issues affect service and external trust paths too. | |
| Recommendation — Require strong user authentication and restrict legacy NTLM fallback paths. Rotate and manage authenticators so captured NTLM material loses value quickly. Apply mutual authentication and tighter trust checks for non-human authentication paths. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Reducing NTLM exposure requires constraining where legacy authentication is allowed. |
| CIS-8 — Audit Log Management | Unexpected NTLM flows are a detection signal that needs review in logs. | |
| Recommendation — Restrict legacy authentication paths and remove unnecessary access routes. Log and review NTLM authentication events to spot abnormal use and relay attempts. | ||
Practitioner Guidance
What to verify: Confirm which applications, services, and administrative paths still negotiate NTLMv2, and separate true business-critical dependency from accidental legacy fallback. If you cannot name the owner of the NTLM dependency, you do not yet have enough control over it.
Decision rule: If NTLMv2 is only present for compatibility, prioritise deprecation and replacement. If it is unavoidable, treat signing, channel binding, strict scoping, and alerting on unusual NTLM usage as the minimum compensating controls.
Practitioner takeaway: NTLMv2 is less a protocol to “secure” than a trust path to shrink, because the real risk is not the handshake itself but the places where legacy authentication still allows an attacker to inherit trust they should never have had.