NTLM Relay (T1557.001)

NTLM relay is an attack on NTLM, a Windows sign-in protocol: an attacker gets a client to start a login with them, passes it on to a different server, and is accepted there as the user. No password is needed. It works because the answer is genuine and NTLM alone does not tie it to one connection.

Explain It Like I'm 10

Think of a locker that opens only if you answer a question that changes every time you try it. Only the owner knows how to work out the answer. A kid who wants into Sam's locker can't answer, so the kid walks up to Sam, reads out the locker's question, and says the school is asking it. Sam, thinking he is talking to the school, works out the answer and says it. The kid carries Sam's answer to the locker, and the door opens. The kid never learned how Sam works out answers. He only carried one answer to the right place while it still counted.

What is NTLM, and how does its login work?

NTLM is a Windows sign-in protocol that Microsoft now calls a legacy one. It proves who someone is without the client sending the password itself. Microsoft says NTLM credentials include a one-way hash of the user's password, a value made from the password by a scrambling that is not meant to be undone. The client proves it has access to those credentials by doing a calculation with them.

A sign-in takes three messages. The client says it wants to sign in. The server replies with a challenge, a value the server generates. The client then sends back its user name, in plain text, and a response worked out from that challenge using credentials derived from the user's password. A legitimate client computes the response from those password-derived credentials, so a correct response shows that whoever computed it had them.

Who checks the answer

The server checks the response. For a domain account, the check is done by a domain controller, a server that keeps the network's account records and can check a response against them. The file or web server passes the user name, the challenge and the response to the domain controller, which says whether they match.

NTLM is not a network service of its own. Its messages travel inside whatever program is asking for the login, such as a file-sharing connection (SMB, the protocol Windows uses to share files over a network) or a web request. Microsoft describes NTLM as used most often as a fallback when Kerberos, the other Windows sign-in protocol, is unavailable.

How an NTLM relay attack works

Microsoft describes an NTLM relay attack as two steps: coercing a victim to authenticate to an endpoint the attacker chooses, then relaying that authentication against a vulnerable target. By forwarding the credentials, the attacker can authenticate and perform actions on behalf of the victim.

In the first step, a victim's machine starts an NTLM login with a machine the attacker controls. The attacker does not have the user's password-derived credentials and cannot work out a response. So the attacker opens its own connection to a second server, the target, and asks to sign in as that user. The target answers with a challenge.

The attacker passes that challenge to the victim's machine, which is already waiting for one. The victim's machine believes it is signing in to the attacker's server, so it works out the correct response from its user's password-derived credentials and sends it back. The attacker hands the response to the target. The target checks it, finds it correct, and accepts the session as the victim.

Why the attacker does not need the password

At no point did the attacker hold the user's credentials. Relaying does not require learning the cleartext password: the victim's own machine does the calculation, and the attacker only forwards messages between the two servers. Whether captured login material could support password guessing is a separate question, covered below. What the attacker gains is a session on the target that belongs to the victim.

Why does the server accept a forwarded login?

Because nothing in plain NTLM ties a login to the connection it travels on: Microsoft's documentation says NTLM does not inherently bind the authentication to a specific connection. The target checks that the response fits the challenge it sent. It does, because the real user's machine worked it out.

Web and directory connections often first set up a protected channel, called TLS, and the login then runs inside it. The login is not tied to that channel. Microsoft's explanation of the same weakness notes that there is no binding between the key that secures the encrypted channel and the key generated during authentication, so the server verifies the credentials without detecting that the channel they were sent over originated with the attacker and not the client.

The attacker can therefore keep one connection with the victim and another with the target, and pass the login between them. Without a binding, the target sees a correct answer arriving and cannot tell who delivered it.

How does the victim end up signing in to the attacker?

Windows can sign in on its own. MITRE ATT&CK, a globally accessible knowledge base of adversary tactics and techniques, describes the behaviour: when a Windows system connects to an SMB resource, it automatically attempts to authenticate as the current user, so people do not have to type credentials to reach network resources.

An attacker's job, then, is to get that connection pointed at a machine they control. Microsoft and MITRE between them describe several routes:

• A flaw or a network position: Microsoft's 2009 advisory says the attacker needs another vulnerability that puts them between the two machines (a man-in-the-middle attack), or must convince the victim to connect to a server under the attacker's control.
• A message or document: Microsoft says Office documents and emails sent through Outlook are effective entry points, because they can embed network paths that make a client reach out.
• Poisoned name lookups: MITRE describes an attacker answering the network's name lookups, so that victims communicate with a machine the attacker controls.

ATT&CK files the third route with SMB relay as T1557.001, Name Resolution Poisoning and SMB Relay. The title is narrower than the attack: the description says the relay step can happen in conjunction with poisoning but may also be independent of it, and that the forwarded login can be carried into other protocols besides SMB.

One documented case: an Outlook flaw in 2023

In March 2023 Microsoft reported limited, targeted abuse of a flaw in Outlook for Windows, CVE-2023-23397. A crafted message made Outlook contact a server the attacker controlled and send the user's NTLM negotiation message, with no user interaction. Microsoft says the attacker could then relay that message to other systems that support NTLM, and it later described the chain as an Outlook entry point relayed against an Exchange mail server. CISA lists the flaw as exploited. Microsoft's report gives no victims, count or period.

The Outlook fix changed how Outlook uses the path. It did not change whether a server accepts a forwarded login, which is what the defenses below address.

What can the attacker do after the relay?

Once relayed, the target treats the attacker's session as the victim's. What that is worth depends on the target and on what the victim's account is allowed to do. Microsoft says this gives attackers a foothold from which to compromise more of the network, and that it has observed threat actors exploiting services that lack relay protections. The targets Microsoft names fall into a few kinds:

• File sharing: an SMB server that accepts the victim's NTLM login lets the attacker act as the victim there.
• The directory: Active Directory keeps the network's user accounts, and LDAP is the protocol used to authenticate users and retrieve directory information from it. A relayed login to it carries the victim's standing in the directory.
• The certificate service: Active Directory Certificate Services (AD CS) issues certificates used to prove identity. Microsoft's guidance says a server running its web enrollment services is potentially vulnerable to NTLM relay, and gives Extended Protection for Authentication (explained under channel binding below) together with disabling HTTP as the primary mitigation.

How does it differ from password cracking and from pass the hash?

All three involve NTLM login material, but the attacker uses different material in each, and only a relay needs the victim's login to be happening while the attacker uses it.

A captured response is not the password hash. It is the result of a calculation that used the hash and one particular challenge, so it is not what pass the hash uses. Cracking is not certain to work either: guessing may fail to recover the password. A relay needs neither, so it gives the attacker a live session on the target, not a password.

What stops an NTLM relay, and where does each defense stop working?

Each defense takes away a different thing the attacker needs, and each works only where it applies.

Signing

SMB signing adds a signature to every message. Microsoft's documentation says all of its keys derive from the session key, a short-lived key the client and server establish for the session, that the signature confirms the sender's and receiver's identities, and that it prevents relay attacks.

The session key is itself derived from the user's password, and a relay-only attacker, who only forwards messages, never holds it. Without the session key, the attacker cannot generate valid signatures for requests it chooses, so where the target requires signing, it rejects what follows the forwarded login. Microsoft's 2009 advisory lists signing as a mitigating factor: applications that use session signing are not affected by credential forwarding.

The limits are in where the rule sits:

• SMB: a relay is aimed at a server, so the server's rule about incoming traffic is what matters. Windows 11 version 24H2 Enterprise, Pro and Education require signing in both directions, Windows Server 2025 requires it on outbound traffic only, and the Home edition requires neither. Requiring signing has a cost: Microsoft notes that a client cannot connect to a third-party server that does not support signing.
• LDAP: signing covers only sessions that do not use TLS. Windows Server 2025 requires it by default for new Active Directory deployments, while on Windows Server 2022 and earlier it is optional, and an upgrade keeps the existing policy.

Channel binding

Channel binding puts back the missing link. The client and server each derive a token from the TLS session, the client includes its token in the login, and the server compares it with its own. Microsoft explains that the attacker's separate TLS session to the server produces a different token, so, where the server checks the token, the relayed login carries one that does not match and is rejected. Microsoft's name for the wider mechanism is Extended Protection for Authentication (EPA).

It also has limits. LDAP channel binding applies only to encrypted (TLS) sessions that use SASL authentication, which includes NTLM and Kerberos logins. Windows Server 2025 turned on EPA for AD CS and, in new Active Directory deployments, channel binding for LDAP by default, in a mode Microsoft calls "When supported": clients that cannot send a binding are still accepted, and the stronger setting is "Always". On Windows Server 2022 and earlier, the LDAP policy is set to "Never" by default.

Kerberos and switching NTLM off

Microsoft says Kerberos reduces the risk of credential relay, because it has its own way for both sides to prove who they are and built-in detection of replayed logins. Where NTLM is switched off, the exchange the attack depends on is gone, but NTLM is still in use for reasons covered below.

Closing entry points

Fixing a flaw like the Outlook one removes one way to steer a victim, and MITRE lists disabling unneeded name-lookup protocols as a mitigation for another. Neither changes whether a target accepts a forwarded login, so they complement signing and binding rather than replace them.

What can a defender see?

Some records show where protection is missing. Microsoft's domain controller logs summarise the unsigned LDAP binds the controller permitted, and channel binding auditing logs clients that connect without a token. Microsoft presents both as a way to check client compatibility before enforcing the requirement.

MITRE's detection analytic for the poisoning technique looks for odd name-lookup traffic combined with SMB relay attempts, registry changes and suspicious service creation. A relay that starts another way, such as a crafted message, does not depend on name lookups, so an analytic built on that traffic describes only part of the picture. Microsoft's roadmap adds enhanced NTLM auditing, which shows where and why NTLM is still used.

Why is NTLM still in use, and what is changing?

NTLM persists where Kerberos cannot be used. Microsoft says it remains prevalent in environments where Kerberos is not feasible because of legacy dependencies, network limitations or ingrained application logic.

Microsoft's three-phase plan, set out in a post dated 29 January 2026, starts with auditing, which the post describes as available now. The second phase brings Kerberos fixes for the common reasons NTLM is needed, planned, as of that post, for the second half of 2026. In the next major Windows Server release and matching client releases, network NTLM would be disabled by default and re-enabled only by explicit policy. Microsoft says this does not remove NTLM from Windows and that timelines are subject to change. Windows Server 2025 and Windows 11 24H2 already removed NTLMv1 and deprecated NTLMv2, the more commonly used version of the two.

Until NTLM is off, a target that neither requires signing nor checks channel binding can still accept a forwarded login.