An NTLM relay attack is a man-in-the-middle technique that forwards NTLM authentication messages from one system to another to impersonate a user or machine. It works by relaying challenge-response traffic to a target that accepts NTLM without protection such as signing, allowing unauthorised access without cracking the password.
What NTLM Relay Attack Actually Means
An ntlm relay attack abuses the protocol’s challenge-response flow by passing authentication messages to another system that will accept them, so the attacker can act as the user or machine without knowing the password.
What makes the technique dangerous is not password cracking, but trust abuse. If the target accepts NTLM without protections such as signing or related channel-binding controls, the relayed authentication can be accepted as valid even though the attacker only intermediated it.
How the Attack Works in Practice
relay attack usually begin with the attacker getting a victim to authenticate to the attacker’s listener, then forwarding those messages to a third system in real time. Name-resolution poisoning, forced authentication, or other coerced connections are common ways to create that first handshake.
The attacker’s value comes from timing and protocol acceptance. If the receiving service allows NTLM and does not enforce the checks that bind the authentication to the intended server, the attacker can reuse the authentication exchange to establish an unauthorised session.
This is why NTLM relay often appears alongside lateral movement techniques and adversary-in-the-middle activity: the attacker is not simply intercepting traffic, but using that interception to turn a valid authentication event into access.
Why NTLM Relay Matters for Windows Environments
NTLM relay becomes especially dangerous in Active Directory environments because so many services still accept NTLM for compatibility. That creates a wide attack surface across file shares, web applications, management tooling, directory services, and legacy integrations.
The risk rises when organisations still rely on weak defaults, allow unsigned SMB or LDAP sessions, or leave exposure paths open between workstations and higher-value systems. In those cases, a low-privilege foothold can sometimes be turned into access to administrative services, directory objects, or sensitive infrastructure.
For readers hardening Microsoft environments, NHIMG’s Active Directory and Entra ID Hardening Guide is the broader reference point for the surrounding identity attack surface, while the LDAP Security Deep Dive Guide explains why LDAP signing and channel binding matter so much in relay prevention.
Detection, Remediation, and Hardening Priorities
Detection should focus on suspicious NTLM authentication patterns, unusual source-to-target relationships, and unexpected use of high-value services immediately after a coerced authentication event. Post-incident review should also ask whether the relayed session reached directory services, management interfaces, or other systems that would materially expand access.
Remediation is usually about removing the relay opportunity rather than chasing the password. Enforcing SMB signing, LDAP signing, and LDAP channel binding, limiting NTLM where feasible, and reducing coercion opportunities all shrink the attack path. In parallel, teams should review service accounts, machine accounts, and delegated admin paths that may have been exposed during the attack chain.
NHIMG’s NTLM Relay Guide and MITRE ATT&CK T1557 Adversary-in-the-Middle both align with that defensive lens, because they connect the attack path to the concrete controls that stop relay from succeeding.
Risk and Threat Considerations
NTLM relay is dangerous because it turns an otherwise legitimate authentication event into a reusable access path. The impact is often highest where NTLM is accepted by privileged services, because the attacker can pivot from interception to privilege abuse without ever recovering the victim’s password.
Failure mechanism: The target trusts a relayed NTLM exchange that was not properly bound to the intended server or protected by signing, allowing the attacker to impersonate the authenticating principal.
Impact: Unauthorised access can lead to lateral movement, directory compromise, service abuse, or the theft of additional credentials and tokens from systems reached through the relayed session.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1557 — Adversary-in-the-Middle | NTLM relay is an adversary-in-the-middle technique that relays authentication traffic. |
| Recommendation — Map relay paths to T1557 and hunt for poisoning, coercion, and relayed authentication activity. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | NTLM relay abuses authentication material and the conditions around its use and protection. |
| IA-2 — Identification and Authentication (Organizational Users) | The attack impersonates users through accepted authentication flows in enterprise systems. | |
| IA-9 — Service Identification and Authentication | Relay attacks often target services and machine-to-service authentication flows. | |
| Recommendation — Enforce authenticator protections and reduce reliance on reusable authentication exchanges. Require stronger user authentication paths where NTLM relay would otherwise be accepted. Protect service authentication paths with stronger protocol binding and mutual trust checks. | ||
Practitioner Guidance
What to watch for: Treat NTLM relay as a protocol trust problem, not just a detection problem. The most effective response is to remove the conditions that make relay viable, especially where directory, file, or management services still accept NTLM without stronger protections.
Practitioner takeaway: If a service can be relayed, assume it can be impersonated, and prioritise signing, channel binding, and NTLM reduction before the next foothold reaches a privileged endpoint.