SMB signing re-auth bypass

SMB session re-authentication lets an attacker place a relayed, privileged authentication onto a session whose signing key the attacker already controls. The session’s identity becomes the victim’s while traffic keeps being signed with the attacker’s key — so a host that requires SMB signing (Domain Controllers included) accepts the session. Enforced signing, the standard mitigation against the whole relay class, does not stop it. The same idea works against LDAP signing, which makes it a class of bug rather than a single protocol mistake. ^{1 2}

Two write-ups appeared within days of each other: Lyderic Lefebvre’s “Defeating enforced SMB signing: a note” (October 21, 2026, covering SMB) and SpecterOps’ Raj Patel, “Signed, Sealed, and Relayed, NTLM-style” (October 23, 2026, the LDAP variant). Both report that Microsoft had already fixed the issues — silently for SMB around September 2026, and for LDAP in the October 13, 2026 update (KB5126646). Every Windows Server release from 2016 through 2025 was vulnerable to the LDAP variant until that update; the SMB variant had no CVE and reads as silent hardening rather than a tracked fix. ^{3 4}

Mechanism (SMB)

SMB lets a client re-authenticate an existing session (after expiry, for example). The specification keeps the session’s signing key across the re-authentication: “the existing Session.SessionKey will be retained” (MS-SMB2 3.3.5.5.2), and the server derives a new Session.SigningKey only when the request “is not for session reauthentication” (MS-SMB2 3.3.5.5.3, step 7). ^{5 6}

What the specification does not require is that the re-authenticating identity match the session’s original one. Step 3 sets Session.SecurityContext only “If Session.SecurityContext is NULL” — for an existing session “no changes are necessary.” The documented scenario is a principal re-authenticating its own session; a different identity swapped onto the same key passes whatever the server checks, which is the missing piece the bypass uses. ^{7 8}

The attack follows directly: open an SMB session as a low-privilege account you control (so you can sign traffic), then re-authenticate that same session with a relayed authentication of a privileged account (NTLM or Kerberos). The identity becomes privileged, signing continues with the low-privilege key the attacker holds, and a signing-required target accepts the session. ⁹

LDAP variant (the “LDAP Switcheroo”)

Against LDAP signing the same shape works through SASL records. The attacker first establishes a signed LDAP connection with a session key they know — valid low-privilege credentials, or an anonymous NTLM context where the DC accepts one — then relays a coerced victim’s NTLM authentication over that existing connection, packing a malicious LDAP operation into the same signed SASL record as the victim’s AUTHENTICATE message. One signature covers everything inside a SASL record: the DC verifies it with the attacker’s key, switches authorization to the victim’s identity, and executes the operation with the victim’s privileges. ¹⁰

The victim has to be a coerced Windows SMB client. The SMB client sets the NTLM signing flag in its authentication — the very thing that used to make SMB-to-LDAP relaying hard — and that flag is what makes the stacked operation pass; an HTTP/WebDAV victim leaves it unset and the DC rejects the attempt with operationsError. The technique targets LDAP on 389/TCP; LDAPS (636/TCP) is out of scope. ¹¹

Impact is the full relay-to-LDAP payoff: coerce a machine-account authentication on one DC and relay it to LDAP on another DC, write msDS-AllowedToActOnBehalfOfOtherIdentity for resource-based constrained delegation (or a shadow-credentials equivalent), then DCSync — domain and forest compromise from an unauthenticated or unprivileged start. ¹²

What it is not

Defeating signing is not a compromise by itself: it only lets a relayed authentication be accepted on a signing-required target. The attacker still needs to capture or coerce an authentication of an identity that is privileged on that target, through LLMNR/mDNS poisoning, coercion, or similar. SMB signing and LDAP signing also stay necessary — the clean fix is a same-identity check on re-authentication, the check the specification already defines for session binding. ¹³

Patch status

• SMB: a same-user check on re-authentication appeared on Windows 11 24H2 / Server 2025 around September 2026, with similar changes reaching other supported versions in the following weeks (one or two end-of-life versions may never receive it). Lefebvre found no CVE in Microsoft’s update guide, the KB notes, or public trackers. Treat it as a patch window: hosts current on updates are likely not affected, hosts behind that wave still are. ¹⁴
• LDAP: fixed in the October 13, 2026 update (KB5126646). The fix tracks each LDAP connection’s identity with a counter and discards the rest of a signed SASL record when the identity changes mid-record. SpecterOps reported the issue to MSRC on October 6, 2026 and received no response; the fix shipped a week later, and they cannot say whether their report caused it. All Server 2016–2025 DCs they tested were vulnerable until that update. ¹⁵
• SpecterOps independently found the SMB variant and confirmed the September silent patch. Lefebvre’s framing is the useful one: “a sign this is a class rather than a single bug.” ^{16 17}

Tooling and verification

• reauthx (github.com/aas-n/reauthx) — fork of krbrelayx adding one opt-in --reauth-bypass flag; with the flag off it behaves exactly like krbrelayx. Ships patchcheck.py (recon: places a host in the patch window across CVE-2025-33073 client reflection, CVE-2025-58726 GhostSPN loopback, and the September 2026 same-user re-auth feature flag) and coerce_name.py (Unicode-confusable coercion names). ¹⁸
• NetExec reauth_swap module — probe that reports whether a host still allows the cross-user re-authentication swap (nxc smb <target> -u ... -p ... -M reauth_swap -o PROBE_USER=... PROBE_PASS=... prints VULNERABLE - enforced SMB signing bypassable when it does). ¹⁹
• The archived note carries a full authorized-testing walk-through: recon and patch-window placement, a confusable-name DNS record on the DC, krbrelayx.py --reauth-bypass with the low-privilege base session, coercion, and cleanup. ²⁰

Connections

• ntlm-relay-attacks — the parent attack class and the page whose “enforced signing breaks the relay” rule this bypass qualifies; its remediation guidance now needs the patch-window caveat.
• impacket — krbrelayx (which reauthx forks) and ntlmrelayx belong to the same tool family used for the relay itself.
• kerberos — the class is authentication-protocol-agnostic: Kerberos-authenticated sessions take the same re-authentication path as NTLM ones, which is why Lefebvre’s tooling rides on krbrelayx.

Sources

• Lyderic Lefebvre 2026 — Defeating enforced SMB signing: a note
• Raj Patel 2026 — Signed, Sealed, and Relayed, NTLM-style: Bypassing LDAP Signing Through Reauthentication
• Microsoft — [MS-SMB2]: Reauthenticating an Existing Session
• Microsoft — [MS-SMB2]: Handling GSS-API Authentication

Footnotes

1. Lyderic Lefebvre 2026 — Defeating enforced SMB signing: a note ↩

2. Raj Patel 2026 — Signed, Sealed, and Relayed, NTLM-style: Bypassing LDAP Signing Through Reauthentication ↩

3. Lyderic Lefebvre 2026 — Defeating enforced SMB signing: a note ↩

4. Raj Patel 2026 — Signed, Sealed, and Relayed, NTLM-style: Bypassing LDAP Signing Through Reauthentication ↩

5. Microsoft — [MS-SMB2]: Reauthenticating an Existing Session ↩

6. Microsoft — [MS-SMB2]: Handling GSS-API Authentication ↩

7. Microsoft — [MS-SMB2]: Handling GSS-API Authentication ↩

8. Lyderic Lefebvre 2026 — Defeating enforced SMB signing: a note ↩

9. Lyderic Lefebvre 2026 — Defeating enforced SMB signing: a note ↩

10. Raj Patel 2026 — Signed, Sealed, and Relayed, NTLM-style: Bypassing LDAP Signing Through Reauthentication ↩

11. Raj Patel 2026 — Signed, Sealed, and Relayed, NTLM-style: Bypassing LDAP Signing Through Reauthentication ↩

12. Raj Patel 2026 — Signed, Sealed, and Relayed, NTLM-style: Bypassing LDAP Signing Through Reauthentication ↩

13. Lyderic Lefebvre 2026 — Defeating enforced SMB signing: a note ↩

14. Lyderic Lefebvre 2026 — Defeating enforced SMB signing: a note ↩

15. Raj Patel 2026 — Signed, Sealed, and Relayed, NTLM-style: Bypassing LDAP Signing Through Reauthentication ↩

16. Lyderic Lefebvre 2026 — Defeating enforced SMB signing: a note ↩

17. Raj Patel 2026 — Signed, Sealed, and Relayed, NTLM-style: Bypassing LDAP Signing Through Reauthentication ↩

18. Lyderic Lefebvre 2026 — Defeating enforced SMB signing: a note ↩

19. Lyderic Lefebvre 2026 — Defeating enforced SMB signing: a note ↩

20. Lyderic Lefebvre 2026 — Defeating enforced SMB signing: a note ↩