NTLM relay succeeds because NTLM proves knowledge of a secret without mutual authentication, while many defenses protect only the session after authentication completes. If signing or channel binding is not required, an attacker can forward the challenge response to another service and authenticate as the victim. Default settings often leave enough gaps for this to work.
Why NTLM Relay Still Succeeds in Enterprise Networks
ntlm relay keeps working because it exploits a protocol design gap, not a single broken system. NTLM can prove that a client knows a secret, but it does not inherently bind that proof to the intended server. If an environment still allows NTLM in enough places, and if signing, EPA, or channel binding is not consistently enforced, an attacker can forward an authentication exchange to a different service and obtain access as the victim. That makes the weakness structural, not incidental.
Enterprises also inherit mixed estate behaviour: legacy servers, older applications, domain trusts, and compatibility exceptions often preserve NTLM as a fallback even when more secure authentication exists. In those conditions, a relay path can survive because one service trusts the response while another session later adds protection too late to stop the initial abuse. MITRE ATT&CK Enterprise Matrix provides useful context on how credential interception and relaying fit into broader adversary tradecraft. In practice, many security teams discover relay viability only after a misconfigured service account or legacy protocol path has already been abused.
How NTLM Relay Works in Practice
The practical sequence is straightforward. An attacker first gets a victim to authenticate to a system they control or influence, such as via coerced authentication, name resolution tricks, or an exposed service that accepts inbound SMB, HTTP, or LDAP traffic. The attacker then relays the captured NTLM exchange to another service that still accepts NTLM and does not require protections that would tie the session to the original channel or server identity.
If the target service accepts the relayed exchange, the attacker inherits the victim’s authenticated context. What happens next depends on the target’s privileges: LDAP relay can modify directory objects, SMB relay can reach file or admin paths, and web relay can expose management functions. The core issue is that NTLM validation is often treated as sufficient at the front door, while the environment only protects against misuse after the session is already established.
- Relay remains viable where NTLM is enabled for compatibility and not tightly restricted.
- Signing helps only when it is required on the relevant protocol path, not merely recommended.
- Channel binding and EPA reduce relay options by tying authentication to the transport or endpoint.
- Hardened settings on one service do not help if another reachable service still accepts relayed NTLM.
For defenders, this is not just a protocol issue but an exposure-management problem across hosts, applications, and directory services. The NHIMG Ultimate Guide to NHIs — Key Challenges and Risks is useful here because relay attacks often succeed where shared credentials, long-lived access paths, and weak visibility allow trust to persist beyond the point of first compromise. These controls tend to break down when legacy interoperability requirements leave multiple authentication paths active and only some of them enforce binding or signing.
Where the Attack Survives Compatibility Exceptions and Mixed Protections
Tighter authentication hardening often increases operational friction, so organisations balance security gains against application breakage and support burden. That tradeoff is exactly why NTLM relay persists: teams may disable NTLM in one segment, but retain it for printers, management tools, directory-integrated applications, or third-party systems that have not been modernised.
Current guidance suggests treating relay resistance as an estate-wide property, not a server-by-server toggle. A single weak service can still be enough if it is reachable from a coercion source and accepts relayed authentication without the right protections. This is especially true in mixed Windows environments where SMB, LDAP, and HTTP services differ in how consistently they enforce signing or endpoint binding.
Practitioners also underestimate how often the real failure is visibility. If teams do not inventory where NTLM is still accepted, they cannot distinguish a deliberate exception from an accidental exposure. The result is a security posture that looks improved on paper while practical relay paths remain open in older zones, delegated admin paths, or third-party integrated systems. The right question is not whether NTLM exists somewhere in the enterprise, but where it can still be used to reach something valuable.
Risk and Threat Considerations
NTLM relay is a privilege-abuse and trust-bypass risk because it turns an authenticated challenge-response into a transferable ticket when the target does not bind the session strongly enough. The exposure is highest where legacy compatibility, implicit trust between services, and weak directory or web hardening intersect.
Failure mechanism: An attacker coerces or captures an NTLM authentication exchange and relays it to another service that accepts NTLM without requiring signing, channel binding, or equivalent endpoint binding. The defender’s control fails because the protocol proves knowledge of a secret, not the intended recipient, so the attacker can impersonate the victim on the downstream service.
Impact: The attacker may gain unauthorized directory modification, lateral movement, file access, service impersonation, or privilege escalation, depending on the relayed target. In the worst case, a single reachable weak service becomes an entry point into broader domain control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1557.001 — Adversary-in-the-Middle: LLM/relay credential interception | NTLM relay is an adversary-in-the-middle credential abuse pattern. |
| Recommendation — Map relay observations to T1557.001 and hunt for coercion, interception, and forwarded authentication. | ||
| NIST CSF 2.0 | PR.AC-1 — Identity Management, Authentication, and Access Control | NTLM relay exploits weak authentication assurance and access gating. |
| PR.AC-3 — Remote Access | Relay commonly abuses reachable remote services that still accept NTLM. | |
| PR.AC-7 — Enforce Least Privilege and Privilege Separation | Successful relay often turns ordinary credentials into overbroad access. | |
| Recommendation — Strengthen authentication controls to prevent transferable access on weakly bound sessions. Restrict remote access paths that accept legacy authentication without strong binding. Limit account scope so relayed credentials cannot reach high-value administrative functions. | ||
| CIS Controls v8 | 6.3 — Require MFA for Externally-Exposed Applications | Legacy auth paths are safer when exposed access is hardened beyond NTLM alone. |
| 6.5 — Require Session Lock and Reauthentication | Relay abuses weak session establishment before later protections matter. | |
| Recommendation — Require stronger authentication on exposed services rather than relying on NTLM alone. Reauthenticate sensitive actions so a relayed login cannot freely perform follow-on actions. | ||
| NIST Zero Trust (SP 800-207) | SC-12 — Credential Protection | Relay succeeds when credentials are not sufficiently bound to the intended session. |
| Recommendation — Bind credentials and sessions tightly enough that forwarded authentication cannot be reused. | ||
Practitioner Guidance
What to prioritise: Treat every NTLM-accepting service as a potential relay target until proven otherwise. Prioritise the systems that can materially change directory state, grant administration, or broker access to sensitive data, because those are the places where relay becomes a real breach path rather than a nuisance.
What to verify: Confirm where NTLM is still accepted, where signing is mandatory, and where channel binding or EPA is actually enforced rather than merely configured. The key verification is not whether the policy exists, but whether the reachable service path rejects relayed authentication in practice.
Common mistake: Teams often harden a handful of high-profile servers and assume the protocol is effectively controlled. That leaves printers, legacy apps, management endpoints, and internal web services as quiet relay landing zones.
Practitioner takeaway: NTLM relay persists wherever compatibility is allowed to outrank binding and visibility, so the decisive control is not one stronger setting but consistent enforcement across every reachable authentication path.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
