Net-NTLMv2 Relay Attack

What the attack does and why relay matters

A Net-NTLMv2 relay attack abuses the fact that the captured response is forwarded to a different service instead of being cracked. The danger is not password recovery, but reusing the victim's live authentication proof against another endpoint that will accept it.

This makes relay a trust-boundary problem. If a target service accepts NTLM without strong protections, an attacker can turn a single coerced or intercepted authentication exchange into unauthorized access, often with the victim's effective privileges on that service.

The technique is especially effective in environments where legacy compatibility keeps NTLM in use and where the receiving service does not require signing, channel binding, or equivalent protection. In practice, that means the attack succeeds by exploiting protocol acceptance, not cryptographic weakness in the password hash itself.

Where relay attacks usually succeed

Relay depends on a vulnerable path from authentication capture to target service acceptance. Common conditions include coerced authentication, name resolution poisoning, exposed SMB or LDAP endpoints, and web or directory services that still accept NTLM under weak policy.

Once the attacker has the challenge-response exchange, they only need a service that will trust the relayed proof. That can expose file shares, directory objects, administrative interfaces, or web endpoints that were never meant to be reached directly by the attacker.

NTLM Relay Guide is the most direct defensive companion for understanding SMB signing, LDAP signing, channel binding, EPA and NTLM auditing.

Physical Layer and Wireless Jamming Guide is useful for the broader idea of relay-style abuse where an attacker manipulates distance, transport or trust assumptions rather than breaking the underlying credential.

How organisations reduce exposure

The first step is to know where NTLM is still accepted and which services are reachable from untrusted segments or the internet. Exposure review should focus on SMB, LDAP, HTTP and other services that may authenticate without signing, binding or modern channel protections.

Controls that reduce relay risk usually work by removing one of the attacker's prerequisites: disable or constrain NTLM where possible, require signing and channel binding where supported, and harden services that can be induced to authenticate to a hostile endpoint.

Digital Car Key and Keyless Entry Security Guide provides a helpful analogue for relay prevention, because the same design logic appears in distance-bound authentication systems: if the verifier cannot trust the channel, the proof can be replayed or relayed.

Bluetooth, RFID and NFC Security Guide also helps readers compare relay-resistant design choices across proximity-based authentication systems.

Detection, response and post-compromise review

Detection is difficult because a relay attack can look like a legitimate authentication if defenders only inspect the final logon event. That makes correlation important: unusual authentication origins, repeated NTLM use, coerced service-to-service authentication, and sudden access to directory or file resources are all useful signals.

After suspected relay, review what the relayed session could do, not just whether the login succeeded. If the attack reached LDAP, SMB or HTTP administration surfaces, the response may need to include credential and session review, object permission review, and follow-up checks for directory changes or newly created persistence paths.

CISA cyber threat advisories are a useful source for tracking current abuse patterns and defensive priorities that affect exposed authentication services.

MITRE ATT&CK Enterprise Matrix is helpful for mapping the technique to credential access, lateral movement and related follow-on activity during investigations.

Identity impact after a successful relay

The identity impact is usually session-based rather than password-based. Because the attacker is relaying live authentication material, the most immediate concern is unauthorized action under the victim's identity context on the target service.

That can mean access to shares, directory objects, administrative actions or delegated service capabilities. Where relay led to meaningful access, organisations should assess whether the compromised session touched service accounts, privileged users, sensitive shares or directory-write paths, because those are the places where persistence and escalation are most likely to follow.

NTLM Relay Guide remains the best internal reference for the identity-specific defensive side of this attack, especially around blocking relay at the authentication layer rather than relying on after-the-fact cleanup.

Related resources from NHI Mgmt Group

• Why does CAP_NET_RAW create such a large attack surface in Kubernetes pods?
• What is the difference between authentication coercion and NTLM relay in an Active Directory attack path?
• How should security teams assess the attack surface of .NET MAUI apps that share logic across iOS and Android?
• What breaks when MFA is satisfied through a real-time relay attack?