NTLM relay still works in a modern AD estate

Of all the techniques that survive into "modern, patched" environments, NTLM relay is among the most stubborn. It cracks no passwords and exploits no CVE. It simply takes an authentication that was meant for one service and relays it to another — and in a default-ish Active Directory, that's often enough to read the entire directory.

The mechanism, briefly

When a Windows machine authenticates over NTLM, an attacker positioned in the middle can forward that authentication to a different server and be accepted as the victim. Two things make it devastating: attackers can coerce machines into authenticating on demand (via a range of built-in RPC methods), and if the receiving service doesn't require signing, it can't tell the authentication was relayed.

Relay to LDAP: reading the whole directory

The highest-value target is usually the domain controller's LDAP service. If LDAP signing and channel binding aren't enforced, a relayed machine-account authentication yields a full authenticated directory read — users, groups, policies, the lot — without cracking a single password. From there, the attacker has the map they need for everything that follows. On real internal tests, this is frequently the fastest route from "on the network" to "knows everything about the domain."

The settings that stop it

• Require SMB signing everywhere, by GPO. This removes the relay primitive for SMB targets.
• Enforce LDAP signing and channel binding on domain controllers — this specifically defeats relay-to-LDAP.
• Disable multicast name resolution. Turn off LLMNR, NBT-NS and mDNS so attackers can't poison name lookups to capture or coerce authentications in the first place.
• Reduce NTLM. Where feasible, restrict or disable NTLM in favour of Kerberos, and monitor NTLM authentication for anomalies.
• Patch the coercion vectors and restrict the RPC interfaces attackers use to trigger authentications.

Relay persists because the defences are configuration, not patches — and configuration drifts, gets excepted "temporarily," and never gets revisited. The fix is to set signing and channel binding as non-negotiable baselines, and to test that they're actually enforced.

Coercion: authentication on demand

Relay needs an authentication to relay, and capable attackers don’t wait around hoping one happens — they coerce it. A family of built-in Windows RPC methods can force a target, often a domain controller, to authenticate to an attacker-chosen host on command. That turns relay from “wait for a privileged machine to talk to us” into “make it talk to us now.” Patch the known coercion vectors, restrict the RPC interfaces that expose them, and never rely on “nothing important will authenticate to an attacker” as a control — the attacker decides what authenticates, and to whom.

Why patching alone won’t save you

Relay persists because it’s configuration, not a single CVE. You can patch every coercion vector and still be fully relayable if signing isn’t enforced — and you can enforce signing and still be coerced if the vectors are open. The two defences work together, and neither is a patch you install once. Treat signing and channel binding as baselines you actively verify, because the day they drift is the day relay works again.

Cross-protocol relay: why the target rarely matches the source

The quiet strength of NTLM relay is that the protocol a victim speaks and the protocol an attacker relays into need not be the same. A credential coerced over SMB can be presented to an HTTP listener; one captured from a web client can be driven at LDAP. NTLM is an application-layer authentication package that rides on top of whatever transport is to hand, so the authentication blob is portable across every service that accepts it. This is why mitigations have to be reasoned about per destination, not per source.

HTTP endpoints deserve particular attention because they are everywhere and are frequently left unauthenticated at the channel layer. The most instructive example is AD CS web enrolment (the issue commonly catalogued as ESC8). Conceptually: a web enrolment front end accepts NTLM authentication over HTTP, and if that front end does not insist on channel binding, a relayed machine authentication can be used to request a certificate as that machine. A certificate is a durable, portable credential — it survives password changes and can be used for onward authentication — which turns a fleeting coerced login into long-lived access. Other HTTP-fronted services (management consoles, intranet apps using Integrated Windows Authentication, Exchange-style endpoints) present the same shape of risk. The lesson is that an HTTP relay target is often more valuable than the obvious SMB or LDAP one, precisely because defenders forget it speaks NTLM at all.

Signing, MIC and channel binding are not the same control

These three defences are routinely conflated, yet they stop different things and protect different services. Understanding the distinction explains why a single setting never closes the whole class.

• Session signing (SMB signing, LDAP signing) cryptographically binds each message to the authenticated session, so an attacker who has relayed the handshake cannot then inject or tamper with traffic on that session. It defeats the use of a relayed session, but only where the protocol supports signing and both ends enforce it.
• The MIC (Message Integrity Code) protects the integrity of the NTLM authentication exchange itself, preventing an attacker from stripping fields — such as the flags that would request signing — out of the messages in transit. Historic relay techniques worked precisely by removing these protections mid-flight; the MIC exists to make that tampering detectable.
• Channel binding / Extended Protection for Authentication (EPA) ties the NTLM authentication to the outer TLS channel it arrived on. Because a relayed authentication reaches the target over a different TLS channel than the one the victim established, the binding no longer matches and the server rejects it. This is the control that protects TLS-fronted services — LDAPS and HTTPS endpoints including web enrolment — where signing alone does not apply.

Put plainly: signing stops relayed sessions being used, the MIC stops the handshake being downgraded, and channel binding stops the relay landing at all on a TLS endpoint. You need the relevant combination at every destination.

Which services signing can and cannot save

Signing is only available where the protocol defines it and both parties enforce it. SMB and LDAP support it; many HTTP-based services do not sign at all and must rely on channel binding instead. Legacy and appliance services that speak NTLM but implement neither signing nor EPA — print services, older management interfaces, third-party web apps with Integrated Windows Authentication — are frequently the weak link, because no transport-layer integrity control is even on the table for them. Treat any such service as relayable until proven otherwise, and front it with TLS and channel binding or remove its NTLM acceptance entirely.

victim host  --(coerced auth, channel A)-->  attacker relay
attacker relay  --(same auth, channel B)-->  target service
target service  grants session as victim identity