NTLM Relay: How Captured Authentication Becomes Access

NTLM relay is one of those attacks that feels like it should not work, and yet it has stayed effective for two decades. The attacker never learns a password. They never crack a hash. They simply take an authentication that one machine was performing and hand it, whole and unmodified, to a completely different service that is happy to accept it. The victim proves who they are, and the attacker spends that proof somewhere else.

For a blue team, understanding relay matters because the usual advice about strong passwords does nothing here. A relayed authentication is valid no matter how long or random the password behind it is. The defense lives at the protocol level, in signing and binding, and in the network patterns that give a relay away.

How NTLM authentication actually proves identity

NTLM is a challenge-response protocol. When a client authenticates to a server, the server sends a random challenge. The client combines that challenge with a value derived from its password hash and returns the result. The server checks the response against what it expects. If they match, the client is authenticated.

The important detail is what NTLM does not do. In its base form it does not bind that exchange to the specific connection it happened on. The response proves the client knows the secret, but it does not prove the response was meant for this server rather than some other one. That gap is the whole attack.

The relay itself

A relay attacker sits in the middle of two connections. On one side, a victim authenticates to a machine the attacker controls. On the other side, the attacker opens a connection to the real target and forwards every step of the NTLM exchange between the two.

The target sends its challenge. The attacker passes it back to the victim. The victim computes a valid response using its real secret. The attacker forwards that response to the target. The target validates it and grants a session. From the target's point of view, the victim authenticated normally. The attacker now holds an authenticated session on the target as the victim, without ever having seen the secret that made it possible.

This is why relay sits under MITRE ATT&CK T1557.001, grouped with the poisoning techniques that feed it. Relay on its own needs a victim authentication to forward. The interesting question is how the attacker gets one on demand.

Getting a victim to authenticate

Two families of techniques supply the relay with fresh authentications.

The first is poisoning. When a Windows host looks up a name and DNS fails, it can fall back to broadcast protocols like LLMNR and NBT-NS. An attacker on the same segment answers these broadcasts, claiming to be the host the victim was looking for. The victim then tries to authenticate to the attacker, and that authentication becomes relay fuel.

The second is coercion. Several Windows services can be asked, over their own remote protocols, to connect to an arbitrary host and authenticate. An attacker points one of these at their relay machine, and a privileged account, often a domain controller's machine account, authenticates to them on command. Coercion is powerful because it can target high-value accounts directly rather than waiting for a stray broadcast.

Where relayed authentication gets spent

A relay is only useful if the target accepts unsigned, unbound NTLM. Historically many services did. The common targets:

Target service	Why it was relayable	Blue-team fix
SMB file shares	Signing was optional and off by default on many hosts	Require and enforce SMB signing everywhere
LDAP and LDAPS on domain controllers	Channel binding and signing were not enforced	Enforce LDAP signing and channel binding
AD CS web enrollment	HTTP endpoints accepted NTLM without EPA	Enable Extended Protection for Authentication, prefer HTTPS
HTTP-based internal apps	Integrated auth without channel binding	Bind the token to the TLS channel

The pattern is consistent. Wherever NTLM was accepted without proof that the authentication belonged to that exact connection, relay worked. Where the connection is bound, relay breaks.

One detail sharpens the picture: relay is frequently cross-protocol. An attacker can capture an authentication that a victim performs over one protocol, say an HTTP request, and forward it to a completely different protocol on the target, such as LDAP on a domain controller. NTLM does not carry a strong indication of which service it was intended for, so the same captured authentication can be spent against whatever target will accept it. This is why hardening one service is not enough on its own. A poisoned or coerced authentication that a signed SMB target rejects may still be relayable to an LDAP or web enrollment endpoint that was left unbound, which is the reason the defenses below have to be applied across every service that speaks NTLM.

Why signing and binding defeat relay

The fix follows directly from the flaw. If the weakness is that an NTLM response is not tied to its connection, then tie it.

SMB signing stamps each message in a session with a signature derived from the session key. A relay attacker forwarding the authentication never possesses that session key material in a usable way, so it cannot produce valid signatures for the messages that follow. The session the attacker set up simply cannot be used. When signing is required rather than merely negotiated, the target refuses to proceed without it.

Channel binding, the mechanism behind Extended Protection for Authentication, ties the NTLM exchange to the outer TLS channel. The authentication carries a value that only matches if it was performed over that specific TLS connection. A relay runs two different connections, so the binding never matches and the target rejects the attempt. This is what protects LDAPS and HTTPS enrollment endpoints.

Both controls share the same logic. They make the authentication meaningless outside the exact connection it was created on, which is precisely what a relay needs to move it across.

How to detect and defend against NTLM relay

Defense here is a stack of network hardening and behavioural detection. No single setting covers everything, so treat these as layers.

Enforce signing and binding.

1. Require SMB signing on all hosts, clients and servers alike, through Group Policy. Negotiated signing is not enough because relay can influence the negotiation. Required means the connection fails without it.
2. Enforce LDAP signing and LDAP channel binding on domain controllers so relayed LDAP is rejected.
3. Enable Extended Protection for Authentication on AD CS web enrollment and other HTTP endpoints that use integrated authentication, and move those endpoints to HTTPS.

Cut off the fuel.

4. Disable LLMNR and NBT-NS where they are not needed so poisoning has nothing to answer. Rely on DNS.
5. Reduce coercion surface by patching the coercion vectors your vendor has addressed and restricting which hosts can reach the vulnerable RPC interfaces.
6. Retire NTLM where you can. Auditing NTLM usage and moving to Kerberos removes the protocol relay depends on. Windows now offers NTLM auditing and restriction controls to guide this.

Detect the pattern.

7. Watch for coercion traffic, the RPC calls that ask a host to authenticate elsewhere, on the interfaces those calls ride.
8. Alert on authentication from unexpected sources. A machine account authenticating to a host it never touches, or a burst of NTLM logons landing on a single internal IP, is the relay footprint.
9. Correlate coercion then logon. The strong signal is the sequence: a coercion call, then moments later a successful NTLM logon on the attacker's relay host using the coerced account. Either event alone is weak; together they are the attack.

A step-by-step walkthrough of a coercion-to-relay chain

Following one full chain end to end makes the moving parts concrete. The attacker starts with a foothold on the internal network, a machine they control on a segment that can reach the targets.

First they choose where the borrowed authentication will be spent. Suppose an LDAP interface on a domain controller still accepts NTLM without channel binding. That is the destination. The attacker readies a relay that will listen for an incoming authentication and immediately open a connection to that LDAP service, forwarding each step.

Second they arrange to receive an authentication worth relaying. Rather than wait for a stray broadcast, they use coercion: they invoke a remote procedure call on a target that asks it to connect back and authenticate to a host of the attacker's choosing, which is the relay. When the target is a privileged machine, often a domain controller's own computer account, the authentication that arrives carries that account's privilege.

Third the relay does its work. The LDAP service sends its challenge. The relay passes it back to the coerced victim. The victim, using its real secret, computes a valid response. The relay forwards that response to LDAP. LDAP validates it and grants a session that, from its point of view, belongs to the coerced privileged account. The attacker now holds an authenticated LDAP session as a high-privilege account and can make directory changes from it, without ever having seen a password or a hash.

Every link in that chain is ordinary on its own. A coercion RPC is a legitimate protocol feature. An NTLM authentication is routine. A challenge-response completes normally. The attack is the arrangement, and it is why a defender watches for the sequence rather than any single event, and why hardening only one destination service leaves the chain intact through another.

NTLM relay compared with related credential attacks

Relay is often confused with other Active Directory credential techniques that share a goal and differ in method. Placing them together clarifies what relay uniquely needs and uniquely defeats.

Technique	What the attacker needs	What defeats it	Key distinction
NTLM relay	A live authentication to forward, in flight	Signing and channel binding, required	Never learns any secret, borrows one in transit
Pass the hash	An NT hash already stolen from a host	Credential hygiene, limiting where hashes land	Reuses a stolen hash, no live victim needed
Kerberoasting	A service account ticket to crack offline	Strong service passwords, managed accounts	Attacks Kerberos, cracks offline at leisure
LLMNR and NBT-NS poisoning	A victim resolving a name that fails DNS	Disabling the broadcast fallbacks	Supplies relay with fuel, often paired with relay

The row that separates relay from the rest is the second column. Pass the hash needs a hash the attacker already holds. Kerberoasting needs a ticket to crack. Relay needs neither, because it does not learn a secret at all. It borrows a live authentication and spends it before it expires, which is why password strength is irrelevant to it and why the fix lives at the protocol level in signing and binding. For the stolen-hash direction, see Pass the Hash Explained, and for the ticket-cracking direction, Kerberoasting Explained.

How it evolved

Relay is old, and it has survived because the fixes were slow to become defaults. The earliest form reflected an authentication straight back to the machine that produced it, letting an attacker authenticate as a victim to the victim's own host. That specific reflection was addressed, and the broader idea of forwarding an authentication to a different service kept working wherever a target accepted unsigned, unbound NTLM.

The history since has been a steady tightening of defaults rather than a single fix. SMB signing moved from optional toward required on more roles over successive releases. LDAP signing and channel binding gained enforcement options after relay to directory services proved damaging. Extended Protection for Authentication brought channel binding to HTTP endpoints like certificate enrollment. More recently, platform work has added NTLM auditing and controls to restrict or retire the protocol, since removing NTLM entirely is the fix that ends relay outright. The reason the attack persists in the field is that these controls are frequently available and left unenforced, so an attacker steers a negotiation toward the weakest option a target still allows.

Common misconceptions

Strong passwords help. They do nothing against relay. A relayed authentication is valid no matter how long or random the password behind it is, because the attacker never sees or cracks it. The defense is signing and binding, not password policy.

We enabled SMB signing, so we are safe. Enabling and requiring are different. If signing is negotiated but not required, an attacker can influence the negotiation so the session proceeds without it. Only required signing turns away a client that will not sign, and relay commonly crosses protocols, so an SMB-only fix still leaves LDAP or web enrollment exposed.

Only SMB is relayable. Relay is cross-protocol. An authentication captured over HTTP can be forwarded to LDAP on a domain controller, because NTLM does not strongly bind to the service it was meant for. Every service that accepts unsigned, unbound NTLM is a potential destination, which is why the hardening has to be applied everywhere NTLM is spoken.

Kerberos is on, so NTLM is not a concern. Environments that primarily use Kerberos often still allow NTLM as a fallback, and a fallback that is available is a fallback an attacker can force. Auditing where NTLM actually occurs is the prerequisite to reducing it.

Detection in more depth

The strongest detections combine network position with authentication telemetry. On the network, the coercion calls ride specific remote procedure interfaces, and monitoring the interfaces those calls use surfaces an attacker asking a host to authenticate elsewhere. On the authentication side, a machine account logging on to a host it has no operational reason to touch, or a cluster of NTLM logons converging on a single internal address, is the shape a relay leaves behind.

The signal to prize is the sequence. A coercion call, then within moments a successful NTLM logon on the attacker's relay host using the coerced account, is the attack in two events. Either alone is weak: coercion calls can have benign explanations and a single NTLM logon is ordinary. Correlated in time and tied to the same account, they are the coerce-then-relay pattern and little else. Building that correlation, rather than alerting on either event in isolation, is what turns a noisy environment into one where relay stands out.

Frequently asked questions

Does NTLM relay require the attacker to know a password? No, and that is the defining trait. The attacker never learns, cracks, or possesses any secret. They forward a live authentication that a victim performs with its own real secret, and spend the resulting session on a different service. Password strength is therefore irrelevant to the attack.

How is relay different from pass the hash? Pass the hash reuses a hash the attacker has already stolen from a host, with no live victim required at the moment of use. Relay borrows an authentication that is happening in real time and forwards it before it expires, without ever holding a hash. Different inputs, different fixes: credential hygiene for the former, signing and binding for the latter.

Why is required SMB signing better than negotiated? Because relay can influence the negotiation. If signing is merely negotiated, an attacker can steer the session toward proceeding without it. Required signing means the target refuses to continue with any client that will not sign, which removes the attacker's ability to drop it.

What makes machine accounts such valuable relay targets? Coercion can force a computer account to authenticate on command, and domain controller machine accounts sit in high-privilege groups. Relaying a coerced domain controller authentication to a service that trusts it can escalate straight into domain-wide access, which is why authentication from machine accounts to hosts they never normally touch deserves an alert.

Can we just turn NTLM off? Retiring NTLM ends relay outright, and getting there takes work. The path is to audit where NTLM actually occurs, move those flows to Kerberos, and use the platform's NTLM restriction controls to block it where it is no longer needed. Because many environments still have hidden NTLM dependencies, the auditing step comes first so you do not break legitimate flows.

Does disabling LLMNR and NBT-NS stop relay? It removes one common way an attacker obtains a victim authentication, poisoning name resolution on the local segment. It does not stop coercion, which forces authentication through legitimate remote protocols. Disabling the broadcast fallbacks is worthwhile and it is one layer, so it pairs with signing, binding, and coercion-surface reduction rather than replacing them.

Is channel binding the same as signing? They are related and distinct. Signing stamps each message with a signature derived from the session key, so a relayed session cannot produce valid signatures for the traffic that follows. Channel binding ties the authentication to the specific outer TLS channel it ran on, so an authentication performed on one connection does not validate on the attacker's separate connection. Signing protects SMB and similar sessions, and channel binding, through Extended Protection for Authentication, protects LDAPS and HTTPS endpoints.

Where should a defender start if the environment is large? Begin with the highest-value destinations and the controls that fail closed. Require SMB signing across clients and servers through Group Policy, then enforce LDAP signing and channel binding on domain controllers, since directory services are the most damaging place to be relayed into. In parallel, reduce the fuel by disabling LLMNR and NBT-NS where DNS suffices and restricting which hosts can reach the coercion-prone RPC interfaces. Confirm each control with your own tooling: a client that refuses to sign should be turned away in practice, because a control you have not tested is a control you do not have.

Relay attacks are a favourite of intrusion sets that live inside Active Directory, because they convert ordinary network position into privileged access without touching a single password. You can review which groups lean on credential-relay and coercion tradecraft in our Threat Groups directory, which is a useful way to prioritise the hardening above against the actors you actually face.

NTLM relay rewards patience and network access, and it ignores password policy entirely. The controls that stop it are old and well understood: require signing, enforce channel binding, kill the poisoning and coercion that feed it, and watch for the coerce-then-relay sequence. Turn those on and confirm they are enforced, and the attack that borrows your users' authentication has nowhere left to spend it.

Related guides

• Pass the Hash Explained
• Kerberoasting Explained
• Active Directory Security Basics
• Man-in-the-Middle Attacks Explained