Source: NSB Cyber
TL;DR
Summary
TL;DR: Microsoft has patched an LDAP signing bypass that allowed NTLM relay attacks against Windows Active Directory domain controllers, even when LDAP signing was enforced. The fix is included in the 13 October 2026 cumulative security update, KB5126646. Organisations should prioritise patching all affected domain controllers, investigate potential exploitation, and review LDAP signing, channel binding, and NTLM exposure. Until patching is complete, additional network restrictions and monitoring are essential, but they are not substitutes for the security update.
A New LDAP Signing Bypass:
A newly detailed NTLM relay technique has demonstrated that LDAP signing, long regarded as a key defence against authentication relay attacks, was not sufficient to protect vulnerable Windows Active Directory environments. In research published on 23 October 2026, SpecterOps described how attackers could relay NTLM authentication to domain controllers even when LDAP signing was enforced. The vulnerability affected tested Windows Server 2016 and later environments before Microsoft released its October 2026 security update. The findings highlight a critical distinction between enforcing security controls and ensuring that their implementation correctly handles authentication state changes.
The good news is that this isn't another case of researchers discovering that the private key is “4” or “56” or “115“. The bad news is, in our history of Penetration Testing, we rarely have encountered fully up to date DCs.
Technical Breakdown: How the Bypass Works
The vulnerability exploits how domain controllers process LDAP authentication changes within signed SASL records. The attack can be broken down into the following steps:
1. Establish a trusted session: The attacker creates a signed LDAP connection to a domain controller using a security context with a session key they know.
2. Trigger authentication: The attacker coerces a victim server or domain controller into authenticating to an attacker-controlled system over SMB.
3. Relay NTLM authentication: The victim's NTLM authentication exchange is forwarded to the target domain controller over the attacker's existing LDAP connection.
4. Combine LDAP operations: The attacker places the victim's final authentication message and a malicious LDAP modification inside the same signed SASL record, signing it with their original session key.
5. Exploit the identity transition: The domain controller validates the record using the original session key, switches the connection to the victim's identity, and processes the subsequent LDAP modification with the victim's privileges.
The root cause is that the domain controller verified the signature for the entire SASL record before processing its contents, without adequately handling the change in identity partway through that record.
The Potential Impact:
By leveraging this authentication bypass, an attacker could perform actions such as:
Modify resource-based constrained delegation (RBCD): Change msDS-AllowedToActOnBehalfOfOtherIdentity to establish a path to impersonate other users or services.
Abuse shadow credentials: Modify msDS-KeyCredentialLink to establish alternative authentication material for a targeted account, where permissions and configuration allow.
Take over computer accounts: Abuse delegated privileges and authentication relationships to gain control over targeted systems.
Escalate privileges within Active Directory: Chain directory modifications with Kerberos-based impersonation and other identity attacks.
Perform DCSync: Abuse sufficient directory replication privileges to obtain password hashes and other sensitive domain credential material.
Compromise the domain or forest: Combine these techniques to escalate from a relayed machine account to broader Active Directory compromise.
The precise impact depends on the relayed account's privileges, the target environment's configuration, and the attacker's ability to chain additional techniques. The attack does not require recovering the victim's password or session key.
MSFT Patch:
Everyone’s favourite section: the patch! As if we haven’t had enough emergency patches to deal with over the past few weeks..
Microsoft addressed the LDAP vulnerability in its October 2026 cumulative update, KB5126646, released on 13 October, following a separate fix for a related SMB signing issue in September. The LDAP fix introduces connection identity tracking so that the server can detect when authentication changes during the processing of a signed request. If the identity changes partway through a SASL record, the remaining operations in that record are discarded, preventing a malicious LDAP modification from executing under the newly authenticated identity. This remediation addresses the underlying processing flaw rather than relying solely on existing signing requirements. Organisations should prioritise patching domain controllers and ensure that the related SMB fix is deployed across affected systems.
Defender Guidance: Detection and Mitigation
For organisations that have not yet patched, the immediate priority is to reduce exposure, investigate suspicious activity and accelerate remediation. Recommended actions include:
1. Patch affected domain controllers. Deploy the October 2026 cumulative update, KB5126646, and verify that the installed update is applicable to the specific Windows Server version. Treat any unpatched domain controller as a priority remediation risk.
2. Monitor suspicious NTLM authentication. Review domain controller security logs and network telemetry for unusual machine-account authentication, unexpected authentication sources, and suspicious SMB-to-LDAP authentication flows. Correlate events across systems rather than relying on a single log entry.
3. Audit sensitive Active Directory changes. Investigate unexpected modifications to msDS-AllowedToActOnBehalfOfOtherIdentity and msDS-KeyCredentialLink. Where directory auditing is enabled, correlate relevant directory-service change events, including Event ID 5136, with the initiating account, source host and time of activity.
4. Look for signs of privilege escalation. Investigate suspicious delegation changes, newly added key credentials, unusual computer-account activity and subsequent directory replication operations that could indicate DCSync abuse.
5. Restrict LDAP network access. Where operationally feasible, limit inbound LDAP on TCP port 389 to authorised systems and required traffic. The demonstrated bypass targets LDAP on this port, so restricting access can reduce the available attack surface. Validate application dependencies before enforcing firewall changes.
6. Strengthen authentication protections. Enforce LDAP signing and LDAP channel binding together where supported, reduce NTLM usage, and restrict opportunities for attackers to coerce systems into authenticating to untrusted hosts. These controls provide important defence in depth but do not replace the patch.
7. Hunt for related SMB relay exposure. Verify deployment of Microsoft's September 2026 SMB fix and review SMB signing configuration. The LDAP bypass was part of a broader set of findings involving authentication relay and signing enforcement.
References:
Want to stay on top of the latest breaches and incidents, sign up to our LinkedIn Newsletter or check our Signals page every Friday!