NTLM Relay (T1557.001)

An NTLM relay attack forwards a victim's NTLM authentication to a different service instead of answering it. The attacker never learns the password or the hash; they use the live exchange to act as the victim against SMB, LDAP, AD CS or another NTLM-accepting service. MITRE ATT&CK tracks the poisoning-plus-relay path as T1557.001.

Two statements are circulating about this attack, and both are true. Microsoft has begun mitigating NTLM relay by default, and published a post saying so. Penetration testers keep relaying successfully in estates that have already deployed the products that carry those defaults.

The gap between those statements is not marketing. It is three scopings, each written in Microsoft's own documentation, that decide whether a default applies to a given system. This page covers what changed, how each change is bounded, which technique and analytic your detection content is probably mapped to, and what the two circulating identifiers in CISA's exploited-vulnerability catalogue actually say.

One note on the identifier itself. MITRE renamed this sub-technique: T1557.001 is now titled Name Resolution Poisoning and SMB Relay, at version 2.0, last modified 12 May 2026, under Credential Access and Collection.

Explain It Like I'm 10

A guard at a door asks you to prove who you are. You hand over a sealed envelope that only proves it for that door. Someone standing next to you takes the envelope, walks to a different door in the same building, and hands it in there. The second guard opens it, sees a valid proof, and lets them in as you. Nothing inside the envelope says which door it was meant for. That missing detail is the whole attack.

How the relay actually works, and why NTLM is still here

NTLM authentication is a three-message exchange: the client negotiates, the server challenges, the client answers with a response computed from its password hash. The response is valid proof that the client knows the secret. What it does not contain is any statement about which connection it was produced for. Forwarding it to a different service is therefore not an exploit of a bug. It is the protocol working as specified, in a direction nobody wanted.

That leaves the attacker one problem: getting a victim to authenticate to them in the first place. There are two documented families, and a defender should recognise both by name.

• Name-resolution poisoning. MITRE's description covers responding to LLMNR, NBT-NS and mDNS traffic to "spoof an authoritative source for name resolution to force communication with an adversary controlled system". This is the lane the sub-technique's title describes.
• Coercion. Something makes a machine authenticate outward on demand. Microsoft is explicit about one of them: "PetitPotam is a classic NTLM Relay Attack." The mechanics of triggering coercion are out of scope here; what a defender needs is that the vector exists, that it is patched and named, and that it produces no name-resolution traffic at all.

Once the exchange is in hand, the target is whatever accepts NTLM. MITRE notes that adversaries "may encapsulate the NTLMv1/v2 hashes into various other protocols, such as LDAP, MSSQL and HTTP". Microsoft's own advisory adds the two AD CS services that matter most in practice, Certificate Authority Web Enrollment and Certificate Enrollment Web Service. Read that as an inventory of things to protect, not as a route.

Why NTLM is still enabled at all

Precision matters here, because the tone of most coverage implies negligence. Microsoft's own explanation lists three properties that made NTLM useful and hard to remove: it "doesn't require local network connection to a Domain Controller", it "is the only protocol supported when using local accounts", and it "works when you don't know who the target server is". The consequence, again in Microsoft's words, is that "these benefits have led to some applications and services hardcoding the use of NTLM". An estate still running NTLM is usually running someone else's design decision.

Which technique is NTLM relay, actually?

The identifier attached to this attack is almost always T1557.001 - Bing's own generated answer names it - and that mapping is defensible. It is also narrower than the attack the term describes, and the sub-technique says so itself: the relay step "can happen in conjunction with poisoning but may also be independent of it."

Read the published analytics next to that sentence.

That third row is a comparison of published analytic text, not a claim that nobody detects coercion. Vendor rules exist, and the observable events are listed further down. The point is narrower and checkable: a coverage matrix that ticks T1557.001 has covered the lane its analytic watches, and the coercion chain Microsoft itself documents generates neither of the signals that analytic describes.

Did Windows Server 2025 fix NTLM relay?

Microsoft's December 2024 announcement is real progress and deserves to be read as such. It records that a February 2024 Exchange Server update "enabled Extended Protection for Authentication (EPA) by default for new and existing installs of Exchange 2019", and that Windows Server 2025 shipped the same idea for two more services: EPA on by default for AD CS, and LDAP with channel binding enabled by default. Microsoft's summary is that these changes "mitigate risk of of NTLM relaying attacks by default across three on-premise services" - Exchange Server, AD CS and LDAP. The doubled word is in the original.

Then come the qualifiers, all of them from Microsoft's own pages.

The direction row is where the most expensive misunderstanding lives. Relay is blocked by the target requiring signing, not by the client offering it. SpecterOps, whose 2025 research is the most detailed treatment on either engine's first page, states it directly: "configuring SMB clients to require SMB signing does not affect NTLM relay attacks."

It also helps to know what an upgraded domain kept. Before Server 2025, Microsoft's documented defaults were LDAP signing "Optional by default; domain controllers accept both signed and unsigned LDAP binds" and LDAP channel binding "Set to 'Never' by default". If your domain controllers were upgraded rather than newly deployed, those are the settings still in force unless somebody changed them.

Why signing and channel binding are the fix

Channel binding closes the exact gap the analogy describes. A token derived from the TLS channel - in practice the server's certificate hash - is carried inside the authentication message, so the receiving server can compare it against its own certificate and reject anything that arrived over a different connection. SpecterOps describes the mechanism this way, and it is the reason EPA is a structural fix rather than a patch.

The idea predates the attack tooling

RFC 5929, "Channel Bindings for TLS", published in July 2010, defines the binding types that make this possible, "in accordance with RFC 5056 (On Channel Binding)". Neither engine's first page for this term cites it.

That also explains a line in Microsoft's AD CS guidance that otherwise looks like belt and braces. EPA is available over HTTPS and not over plain HTTP, because HTTP has no secure channel to bind to. Which is why the Microsoft advisory prescribes both halves: "enabling EPA and disabling HTTP on AD CS servers", plus "Enable Require SSL".

Signing and channel binding are answering different halves of the same structural gap. Signing protects the session after authentication; channel binding protects the authentication itself.

The CVEs, checked against the primaries

Three identifiers circulate in coverage of this attack. Checked in NVD and in CISA's Known Exploited Vulnerabilities JSON feed rather than in a summary, they do not all say what the coverage implies.

Two things follow from that table. Two of the three are in the KEV catalogue, with federal remediation dates that have already passed - which is a far more defensible statement of urgency than any vendor estimate. And CISA's own entry for CVE-2025-33073 describes the coercion half in plain terms, noting that an attacker "could execute a specially crafted malicious script to coerce the victim machine to connect back to the attack system".

The third is the correction. A widely circulated headline calls CVE-2025-54918 an LDAP authentication bypass; NVD records it as improper authentication in Windows NTLM, by an authorized attacker, and it is not in the exploited-vulnerability catalogue.

How do you detect an NTLM relay attack?

Start from what the published analytics observe, because that determines what your existing coverage claim is worth: `AN1274` describes name-resolution traffic on the LLMNR and NBT-NS ports, and `AN0065` describes a lure file followed by outbound authentication. Both are real signals. Neither is present in an RPC-coerced relay.

The observable evidence a defender can work with sits in three places.

• Authentication that does not match its origin. An account authenticating from a host that is not its usual host is the generic shape of a relayed logon, because the authentication is genuine and only the source is wrong.
• Machine accounts reaching destinations they have no business reaching. Coercion makes a server or domain controller authenticate outward on demand, which is exactly the behaviour that the KEV description of CVE-2025-33073 characterises.
• Certificate enrolment from an unexpected requester on the two AD CS endpoints Microsoft names, since a relayed enrolment produces a legitimate certificate issued to the wrong requester.

One piece of platform help should be switched on before you enforce anything: on Windows Server 2025, LDAP channel binding auditing is enabled by default, which is how you find the clients that cannot support the control you are planning to require.

Now the limits, in the same section rather than at the end. A relay that happens between two hosts nobody is auditing produces nothing central to find. The analytic behind that mapping watches ports the coercion lane never touches. And there is no published measurement of how common any of this is, so nothing here should be turned into a percentage.

NTLM relay vs pass-the-hash vs coercion

These three appear in the same reports, and the difference is easiest to hold by asking one question: what does the attacker actually hold?

• Relay: a live authentication exchange, and nothing else. No password, no hash. The exchange is forwarded while it is still valid.
• Pass-the-hash: a stolen hash, already extracted from somewhere, replayed later at will.
• Coercion: neither. It is the step that produces an authentication exchange for someone else to relay, which is why Microsoft treats a coercion vector and a relay target as two halves of one problem.

The sibling attack on the Kerberos side of the same directory makes the contrast sharp: those attacks end with material you still have to crack offline, while relay never needs the credential at all. That comparison, and the wider question of what replaces NTLM, deserve their own pages.

What it costs to turn this on

Enforcement has a real price, and Microsoft states it rather than hiding it: "if your environment uses third-party servers and the third-party server doesn't support SMB signing, you can't connect to the remote share." Put that sentence in the change request. It is the one that predicts the incident.

Microsoft's own recommended path is staged rather than immediate. Its LDAP guidance says to "Start with 'When supported' for channel binding and 'Negotiate signing' for signing, then move to full enforcement after validating compatibility", with event monitoring in between. The vendor that shipped the hardened defaults is telling you to audit before you enforce.

Where "disable NTLM" really sits

In Windows Server 2025 and Windows 11 24H2, NTLMv1 has been removed and NTLMv2 is deprecated, and administrators can now configure SMB to block NTLM. Deprecated is not disabled, and the replacement work is still landing: Microsoft's answer to the cases where Kerberos could not previously be used is IAKerb and a local KDC, and its claim for the first is that it "relies on the cryptographic security guarantees of Kerberos to protect the messages in transit through the server to prevent replay or relay attacks".

Disabling NTLM is a programme, not a Friday afternoon. It starts with the inventory, which is the same inventory the audit data above produces.

What we do not know

There is no published prevalence figure. No measured share of estates missing inbound SMB signing, EPA or LDAP channel binding exists with a sample size and a method attached. If a number is needed for a risk conversation, produce it from your own estate rather than borrowing one.

There is a government primary this article does not draw on. Six agencies, led by the Australian Signals Directorate and including CISA and the NSA, published "Detecting and Mitigating Active Directory Compromises" on 25 September 2024, covering "the 17 most common techniques used by adversaries and malicious actors to compromise Active Directory". The document itself was not retrievable from where this research was carried out, so nothing here is taken from it. Read it first-hand.

The detection limits stated above belong in the same list: unaudited host-to-host relay is invisible centrally, and the published analytics watch signals the coercion lane does not produce.

Frequently asked questions

Does NTLM relay work even though the attacker never learns my password? Yes, and that is the point of it. Nothing is cracked and nothing is stolen from memory. The authentication exchange is genuine, and it is forwarded to a different service while it is still valid, which is why password complexity has no bearing on whether the attack succeeds.

Is NTLM relay the same as pass-the-hash? No. Pass-the-hash replays a hash the attacker already extracted from a system. Relay uses a live exchange the attacker never possesses in reusable form. The practical consequence is that relay has a short window and needs a victim to authenticate now, while a stolen hash keeps working until the password changes.

We are on Windows Server 2022. Does any of the new default protection apply? No. The defaults described here ship with Windows Server 2025 and, for Exchange, with the 2019 update from February 2024. On Windows Server 2022 the same protections are available but have to be configured, which is what the Microsoft advisory on AD CS describes.

If we upgrade a 2019 domain controller to Server 2025, do the new LDAP defaults apply? No. Microsoft's documentation is explicit that upgrade installations maintain their current LDAP security settings to prevent disruption. The hardened defaults are for new deployments, so an upgraded domain controller keeps whatever it had unless somebody changes it deliberately.

Should we just block NTLM in SMB? The option exists and it is not a first move. Applications hardcode NTLM, and blocking it before an inventory turns a security change into an outage. Use the auditing first, find what depends on it, then decide per service.

What to check this week

Five checks, in order, each drawn from the sources above rather than from general advice.

1. Check inbound SMB signing on the systems that would be relay targets, not the clients. The direction is the part that gets missed.
2. Check the EPA setting level on AD CS web enrollment and on LDAP, rather than whether EPA exists at all. "When Supported" and "Always" are different controls.
3. Establish whether each domain was newly deployed on Server 2025 or upgraded into it. Upgrades kept their old LDAP settings.
4. Confirm the two KEV entries are patched - CVE-2025-24054 and CVE-2025-33073, both past their federal due dates.
5. Check what your detection content is mapped to, and whether that analytic would fire for the lane you care about.

For the applications and endpoints that cannot lose NTLM, what remains is the target-side controls, the audit data the platform now produces, and the inventory that tells you which is which. Microsoft published the qualifier in the same paragraph as the headline. Reading both is the difference between a finding and a plan.