NTLM relay past required signing: SpecterOps and Blackfield re-authenticate a signed LDAP or SMB session with a relayed victim identity, and Microsoft fixed it in the September and October 2026 updates
Required LDAP and SMB signing did not stop NTLM relay: a re-authenticated session kept the attacker's key
Defender actions
- Confirm that every domain controller has the cumulative update of 2026-10-13 and every Windows server the September 2026 one for its Windows release (SpecterOps names KB5126646, the October update for Windows Server 2025, and KB5122882, the September update for Windows Server 2022; other releases have their own packages), then list the computer accounts whose msDS-AllowedToActOnBehalfOfOtherIdentity or msDS-KeyCredentialLink holds a value nobody set, because patching does not remove what a relay already wrote.
Analysis
SpecterOps and Blackfield show that NTLM relay to a server that requires signing works again when the attacker first owns a signed session and then re-authenticates it with the victim's identity, so the session keeps the attacker's signing key. For LDAP, the attacker signs a session to a domain controller with valid credentials or, where accepted, an anonymous NTLM context, coerces a victim over SMB, and sends the victim's relayed authentication with a malicious LDAP modification in one SASL record signed with the attacker's key; the controller checks the signature once, switches to the victim's identity and runs the modification with the victim's rights (SpecterOps, 2026-10-23). The tested controller enforced LDAP signing and channel binding and the attack still worked over 389/TCP; the demonstration writes the resource-based constrained delegation attribute, and relaying a domain controller's machine account to another controller leads to DCSync and domain compromise (SpecterOps, 2026-10-23). Blackfield shows the SMB counterpart: a server keeps the original signing key on re-authentication without checking that the identity matches, so on any host that requires SMB signing, domain controllers included, a relayed privileged authentication yields a privileged session still signed with the low-privilege key, provided the attacker can capture or coerce that authentication (Blackfield, 2026-10-21).
SpecterOps reported the LDAP flaw to Microsoft on 2026-10-06, received no response, and says the fix shipped in the 2026-10-13 cumulative update, KB5126646, while the SMB variant was patched quietly in September 2026 (KB5122882) (SpecterOps, 2026-10-23). KB5126646 is the October update for Windows Server 2025 and KB5122882 the September update for Windows Server 2022 (Microsoft, 2026-10-13; Microsoft, 2026-09-08), so each release needs its own cumulative update of the month. Blackfield found no CVE or KB note for the SMB change, says similar changes seem to have reached the other supported versions in the following weeks without having traced every build, and warns that one or two end-of-life versions may never receive it (Blackfield, 2026-10-21). Both publish tooling; neither reports use in attacks (SpecterOps, 2026-10-23; Blackfield, 2026-10-21).
Cited evidence
The domain controller we tested against had both LDAP signing and channel binding enforced, and the attack still worked over 389/TCP.
We independently identified a similar vulnerability in SMB, and Microsoft patched it quietly in September 2026.
On any host that requires SMB signing, Domain Controllers included, a relayed privileged authentication yields a privileged session that is still signed with the low-privilege key.
I could not find a CVE for this specific change, in Microsoft’s update guide, the KB notes, or public trackers; it reads as silent hardening rather than a tracked fix.
Sources4
AI-generated · no human review · this permalink is the shareable record for the finding · verify operationally critical claims against the linked primary source.