NTLM Relay

How NTLM Relay Works

NTLM relay succeeds because the attacker does not have to crack NTLM, they only need to forward a valid challenge-response exchange to a service that will accept it. That makes the technique especially dangerous in Windows environments where the same authentication method is accepted across multiple protocols or endpoints.

The attack usually depends on a trusted session being coerced or intercepted first, then relayed quickly enough that the target treats the exchange as authentic. In practice, the weakness is not the password itself but the fact that some services will honor a replayed authentication flow without sufficient binding to the original connection or destination.

Why NTLM Relay Is Dangerous

NTLM relay turns a single authenticated interaction into unauthorized access on a different service, often without exposing the attacker to password reuse controls or offline cracking. That can let an intruder reach SMB, LDAP, HTTP, or other NTLM-accepting services with the victim’s authority, which is why relay is often a stepping stone to privilege escalation, directory tampering, or lateral movement.

The danger increases when high-value services accept NTLM without protections such as signing, channel binding, or endpoint protection features that tie the authentication to the intended service. When those protections are absent or inconsistent, the attacker can abuse trust boundaries rather than defeat the credential itself.

Common Conditions That Make Relay Possible

Relay generally becomes viable when an environment allows name resolution poisoning, coerced authentication, weak service binding, or unsigned protocols. Windows ecosystems are particularly exposed when legacy compatibility keeps NTLM enabled alongside services that do not enforce modern session-binding safeguards.

• Services that accept NTLM without signing or channel binding can be relay targets.
• Coerced authentication or poisoned name resolution can supply the attacker with a relayed session.
• Flat network paths and broad service reach make the relayed identity more useful once obtained.

Because the technique is opportunistic, the same initial capture path may lead to different outcomes depending on which service the attacker reaches first. That is why relay is as much an architectural problem as it is a protocol weakness.

Detection, Response, and Hardening Priorities

Detecting NTLM relay is partly about spotting the precursors, such as unexpected NTLM use, unusual authentication targets, coercion attempts, or directory and SMB access patterns that do not fit normal administrative behaviour. Post-incident review should also check whether the relayed session was used to create accounts, change directory objects, or access sensitive shares before the window closed.

Defensive priority usually falls on removing relayable conditions rather than treating relay as a single signature problem. The most effective controls are reducing NTLM exposure, enforcing signing and channel binding where supported, hardening directory and file services, and monitoring for relay primitives such as forced authentication and name resolution poisoning.

Risk and Threat Considerations

NTLM relay matters because it converts trust in an authenticated exchange into an attack path. The attacker is not trying to learn the password, only to reuse the victim’s authority against a different service that fails to bind the session tightly enough.

Failure mechanism: A service accepts a relayed NTLM exchange as if it originated from the intended client, so the attacker inherits the victim’s access without needing the secret itself.

Impact: Successful relay can enable unauthorized access, directory modification, lateral movement, or privilege escalation, especially where the relayed account has broad rights or the target service permits sensitive operations.

Practitioner Guidance

Why practitioners should care: NTLM relay is rarely the end goal, but it often creates the foothold that makes deeper Windows compromise possible. Treat it as a control-gap signal, not just a protocol nuisance.

What to watch for: Prioritise services that still accept NTLM without stronger protections, and review where coercion, unsigned LDAP, or SMB exposure could let an attacker reuse a captured session. The practical question is not only whether NTLM exists, but whether any reachable service will trust it too easily.

Practitioner takeaway: The best relay defence is to shrink the set of services that will accept a relayed authentication exchange in the first place.

Related resources from NHI Mgmt Group

• Guide: Active Directory and Entra ID Hardening Guide
• How should security teams reduce NTLM relay risk in Active Directory?
• Why do Windows environments still need anti-relay controls after NTLM is disabled?
• Why do mixed NTLM and Kerberos environments create more relay exposure?
• How do security teams detect NTLM relay activity before it leads to privilege escalation?