Research published this week shows that a long-trusted defence against NTLM relay, enforced message signing, could be sidestepped against Windows servers and domain controllers. Microsoft has quietly fixed both the SMB and LDAP variants, but every Windows Server built since 2016 was exposed until the patches landed.
What happened
Two pieces of research released within 48 hours of each other have unsettled one of the oldest assumptions in Active Directory security: that turning on message signing closes the door to NTLM relay. On 21 October 2026 the researcher Lydéric Lefebvre published a note, “Defeating enforced SMB signing”, showing how a signing-required SMB server, domain controllers included, could still accept a relayed privileged authentication. On 23 October 2026 Raj Patel of SpecterOps published a companion write-up carrying the same idea to LDAP signing on domain controllers.
Microsoft has addressed both. According to SpecterOps, the SMB behaviour was fixed quietly in the September 2026 cumulative update (KB5122882) and the LDAP behaviour in the 13 October 2026 update (KB5126646). Neither fix carries a CVE identifier the researchers could find; both read as silent hardening rather than tracked vulnerabilities. SpecterOps says it reported the LDAP issue to Microsoft on 6 October 2026, never received a reply, and cannot say whether its report influenced the fix that shipped a week later.
The technical picture
NTLM relay is a decades-old attack in which an adversary positioned between a client and a server forwards an authentication exchange to a third system and ends up acting as the victim. For years the standard mitigation has been message signing: an attacker who lacks the victim’s session key has no way to produce valid signatures, and a server that insists on them should drop the connection. Microsoft’s own documentation says signing “prevents relay attacks”.
The research does not break signing itself. It exploits the gap left by session re-authentication: the SMB specification deliberately retains the original session key, a behaviour meant for a principal renewing its own expired session, but the server never confirms the re-authenticating identity still matches the original principal. That missing check, not the key retention, is what lets a different identity be layered onto a connection the attacker already signs.
Patel’s LDAP variant applies the same logic to the way LDAP bundles signed messages, letting a relayed domain controller authentication run with the victim’s privileges over plain LDAP on port 389. Crucially, SpecterOps reports this worked even when both LDAP signing and channel binding were enforced, because channel binding only protects LDAP over TLS and has nothing to bind to on the unencrypted port. The consequence is severe: a relay to LDAP can enable computer-takeover primitives such as resource-based constrained delegation and shadow credentials, a recognised path to full domain compromise. I will not reproduce the mechanics here, and both researchers stress their tooling is for authorised testing only.
Microsoft is also tightening NTLM more broadly, including moves to retire the legacy NTLMv1 protocol, which we have covered elsewhere; those are distinct changes, not this fix.
Why it matters for UK organisations
Active Directory underpins identity in the overwhelming majority of UK enterprises, government departments and public sector bodies. NTLM remains stubbornly present because legacy applications and appliances still depend on it, and plain LDAP on port 389 is still widely used internally. The uncomfortable message is that two controls many UK security teams spent years rolling out, believing they neutralised relay, did not fully do so between September and October 2026.
The exposure window matters. Every Windows Server release between 2016 and 2025 was affected until patched. Organisations slow to patch domain controllers, or still running end-of-life Windows that may never receive the fix, remain in scope. In my experience, domain controllers are often among the last systems patched, precisely because they are seen as too critical to touch quickly, which is exactly the wrong instinct here.
There is a near-term tempo risk too. On 23 October 2026, the same day the LDAP research appeared, a pull request was opened against the widely used Impacket toolkit to add a cross-user re-authentication option to its ntlmrelayx relay tool, and a feature request was filed against Metasploit for equivalent functionality. Neither had been merged at the time of writing, but the direction is clear: techniques that start as proof-of-concept forks tend to reach mainstream frameworks within weeks, lowering the skill bar considerably.
Expert view
When we test internal networks, NTLM relay to LDAP is already one of the most reliable routes from a foothold to domain dominance. What is notable here is not that relay is possible, but that it punctures a specific reassurance many organisations relied on. Telling a client “we enforce SMB and LDAP signing, so relay is handled” was, for a window of weeks, no longer strictly true, a useful corrective to treating a single control as a finished answer.
I would caution against overstating the immediacy. Both researchers are explicit about the limits. Defeating signing on its own achieves nothing: the attacker still needs to capture and relay the authentication of a privileged identity, typically through coercion or name-resolution poisoning, and needs the other relay preconditions to line up. There is no mainstream reporting yet and no evidence of in-the-wild abuse. This is, for now, a research finding and a tooling trend, not an active campaign, so the right response is prompt patching and defence in depth, not alarm.
What to do now
- Patch domain controllers first. Apply the October 2026 update (KB5126646) to every domain controller to close the LDAP bypass, and the September 2026 update (KB5122882) to all other servers to close the SMB variant. This maps to the Security Update Management control under Cyber Essentials.
- Enforce LDAP signing and channel binding together, because enabling just one still leaves a route open. With both required, an attacker cannot pivot to LDAPS or plain LDAP to dodge the missing control.
- Restrict plain LDAP on port 389 where you can. The LDAP technique ran over 389; where applications allow, favouring LDAPS reduces the attack surface.
- Reduce NTLM usage. Audit where NTLM is still used, move toward Kerberos and phishing-resistant authentication, and plan for Microsoft’s ongoing NTLM deprecation. Every NTLM authentication removed is one less thing to relay.
- Harden against coercion. Relay still depends on coercing or capturing an authentication, so apply existing coercion mitigations, disable the WebClient service where it is not needed, and monitor for unexpected authentication from domain controllers and servers.
- Retire end-of-life Windows. Systems that will never receive the same-user check should be prioritised for replacement or isolation.
Bottom line
This is a textbook example of why layered defence matters. Message signing was never meant to be the single wall that stopped relay, and for a few weeks this autumn it demonstrably was not. Microsoft has now patched both variants, so organisations that keep their servers current are, on the researchers’ own testing, no longer exposed. The task for UK security teams is unglamorous but urgent: confirm the September and October 2026 updates are deployed across the estate, enforce signing and channel binding together, and keep chipping away at NTLM. The tooling is already being updated, so defenders should assume the knowledge is now public.
Sources
- SpecterOps: Signed, Sealed, and Relayed, NTLM-style: Bypassing LDAP Signing Through Reauthentication
- Blackfield: Defeating enforced SMB signing: a note
- GitHub: Add SMB and LDAP signing bypass to ntlmrelayx (Impacket pull request #2345)
- GitHub: Add NTLM Signing and Seal Bypass functionality (Metasploit issue #22048)
