Attackers use NTLM relay attacks to capture an NTLM authentication attempt and relay it to another service that accepts the same authentication. This lets them authenticate as the victim without cracking the password. Defenders should prefer protocols that resist relay, require signing where supported, and reduce places where NTLM authentication is accepted.
How NTLM relay works as an attack path
ntlm relay is not about breaking NTLM mathematically. It is about abusing the protocol flow: the attacker captures an NTLM authentication exchange and forwards it in real time to a different service that accepts the same kind of authentication, so the target service treats the attacker as the victim. The attack succeeds when the destination service is reachable, accepts NTLM, and does not enforce protections that break relaying.
That makes the technique attractive in Windows environments where NTLM is still accepted for legacy compatibility. If the attacker can trigger or intercept authentication, they can often turn a single credential presentation into access to another host, share, directory service, or management interface without ever learning the password.
Why relaying is effective against exposed trust relationships
Relay attacks work because authentication and authorization are not always tightly bound to the original channel, target, or context. If a service accepts NTLM without channel binding, signing, or other protections, it may trust a relayed proof of identity even though the attacker is in the middle. That is why relay is usually discussed alongside name-resolution poisoning, coercion of authentication, and lateral movement rather than as a standalone flaw.
The practical security issue is the trust gap, not the hash itself. Once the attacker can induce the victim system to authenticate outward, the attacker can pivot that authentication to a more valuable service, often one that has higher privilege or broader reach than the original source system.
For a deeper attack-path view of where NTLM relay sits in Windows movement chains, see the Lateral Movement Guide. It places NTLM relay alongside the adjacent techniques defenders usually see in the same intrusions.
What defenders should change first
The first priority is to reduce the number of services that still accept NTLM, then harden the ones that must remain. Signing, channel protections, and protocol choices that resist relay matter because they remove the attacker’s ability to reuse a captured authentication exchange against a second service. Where legacy support is unavoidable, the goal is to constrain where relay can succeed and make the attack noisy enough to detect.
Defenders also need to look at the conditions that let attackers harvest authentication in the first place. That includes coercion paths, weak name resolution, and overly permissive Windows service exposure. A system that still accepts NTLM can be a target even if the password is strong, because the attacker is not trying to crack it, only reuse the authentication attempt.
For hardening patterns around NTLM, delegation, and hybrid Windows identity exposure, the Active Directory and Entra ID Hardening Guide is the most direct companion. When you need to map relay risk into the broader Windows attack surface, that guide is the right place to start.
How to think about detection, compromise checks, and response
Relay attacks are often fast and opportunistic, so the question is not only whether relaying was possible, but whether it was attempted successfully. If you see NTLM authentication used where Kerberos or stronger options were expected, or you find suspicious remote service access immediately after a coerced authentication event, assume the attacker may already be moving laterally. The evidence chain matters because relay often produces legitimate-looking authentication records at the destination.
If a relay likely succeeded, review the destination service for privileged actions performed with that relayed identity, then determine whether that identity had rights that were broader than expected. In practice, the blast radius often depends on whether the relayed account was local admin, a service account, or a directory-adjacent identity that could be reused for further movement.
For identity-focused detection and response patterns that fit this attack chain, the Identity Threat Detection and Response (ITDR) Guide helps frame what to inspect after suspicious authentication reuse. If your environment already has lateral movement exposure, the Cisco Active Directory credentials leak 2025 case study is a useful reminder that credential exposure and Windows relay-style abuse often travel together.
Risk and Threat Considerations
NTLM relay becomes materially dangerous when legacy compatibility is left in place across many systems, because one successful interception can be replayed against multiple targets. The risk is highest where authentication can be triggered remotely, service signing is inconsistent, or high-value systems still accept NTLM alongside stronger protocols.
Failure mechanism: The attacker captures a valid NTLM exchange and forwards it to another service before the challenge-response context expires or is bound to the original channel. If the target accepts that relayed proof, the attacker inherits the victim’s authenticated session without knowing the password.
Impact: Successful relay can enable unauthorized access, privileged remote actions, lateral movement, and follow-on credential theft. In larger Windows estates, the real consequence is often not the first login, but the speed with which a low-friction authentication abuse becomes domain-wide compromise.
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 |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | NTLM relay abuses authenticated user context on Windows services. |
| IA-5 — Authenticator Management | Relay attacks depend on reusable authentication material and weak handling. | |
| AC-6 — Least Privilege | Relay impact depends on how much access the relayed identity already has. | |
| Recommendation — Enforce stronger user authentication and reduce reliance on NTLM where possible. Restrict authenticator reuse and manage credentials so captured exchanges cannot be relayed. Limit account privileges so a relayed session cannot perform broad administrative actions. | ||
| MITRE ATT&CK | T1187 — Forced Authentication | NTLM relay commonly follows coerced authentication to harvest a usable login exchange. |
| T1021 — Remote Services | Relayed authentication is often used to access remote services for lateral movement. | |
| Recommendation — Detect and disrupt forced authentication paths that let attackers capture relayable credentials. Monitor and constrain remote service access paths that can be abused after relay. | ||
Practitioner Guidance
What to verify: Confirm which services still accept NTLM, which of them allow unsigned or unbound authentication, and which high-value paths can be reached from a coerced outbound authentication. The most useful inventory is not “where NTLM exists,” but “where NTLM can be relayed into impact.”
Decision rule: If a service can be reached with relayed authentication and the resulting identity can perform administrative or infrastructure-changing actions, treat that path as a priority fix even if no abuse has been observed yet. If the service is legacy-only, isolate it and constrain the accounts that can reach it rather than assuming low exposure.
Practitioner takeaway: NTLM relay is a trust-boundary problem, not a password-cracking problem, so the right response is to remove relay conditions, shrink NTLM acceptance, and verify where relayed identities can still do damage.