Black Hat Asia 2026 (Singapore, Apr 23–24) — Briefings Deep Dives

The Gift That Keeps on Giving: Bypassing Authentication Reflection Mitigations for SYSTEM Shells

Talk 07 · Windows & Active Directory security · analysis from the speaker's published deck

Sep 23, 2026 · conferences · 11 min read · 2233 words expert

The gift that keeps on giving — one Windows patch, three ways around it.

conferences blackhat active-directory ntlm-kerberos windows

Official recording, Black Hat YouTube channel · open on YouTube ↗

Guillaume André (Synacktiv) tells a patch-bypass story that is really a lesson in how to read a fix. Microsoft patched CVE-2025-33073, an authentication-reflection bug giving authenticated remote-code-execution as NT AUTHORITY\SYSTEM. André applies a simple, repeatable methodology, understand exactly what the patch blocks, then find an attack path the patch's assumption doesn't cover, and turns the single fix into a chain of new SYSTEM-shell vulnerabilities. The standout technique: a Unicode homoglyph that makes a DNS record and a service principal name (SPN) collide under Windows' case-insensitive sort-key comparison, while remaining distinct under the exact comparison the DNS client uses to avoid resolving its own name. That single mismatch rebuilds a Kerberos coercion primitive from scratch. The saga ends with Microsoft enforcing SMB signing on loopback connections, the real structural fix, but the underlying Unicode coercion primitive survives against other services (SCCM, MSSQL).

Post 07 of my Black Hat Asia 2026 series. This is a dense Active-Directory topic; I've kept it analysis-first, explaining the primitives and the reasoning rather than reproducing attack commands. The speaker's slides carry the operational detail.

1. Authentication reflection, in one picture

Authentication reflection is a family of Windows attacks with a simple shape:

  1. Coerce a privileged service on a machine into authenticating (via NTLM or Kerberos) to a server the attacker controls.
  2. Relay that authentication back to a service on the same machine, so the attacker is now authenticated as the privileged client, typically SYSTEM.

If you can reflect a SYSTEM service's authentication back onto SMB, you get a privileged SMB session and, from there, code execution. Historically this was hard: NTLM reflection has had mitigations for years, and Kerberos reflection is awkward because Kerberos ties authentication to domain names, not arbitrary IPs, so you can't just point a victim at your box.

2. CVE-2025-33073 and the trick behind it

CVE-2025-33073 (reported by several researchers, Synacktiv among them) was a "trivial logical vulnerability" giving authenticated RCE, and it used one trick to achieve both NTLM and Kerberos reflection. The trick, building on James Forshaw's research, is the CREDENTIAL_TARGET_INFORMATION (CMTI) marshalling: a marshalled target-info structure can be appended to an SPN, and LSASS discards it when building the authentication blob, but only after the TCP connection is made. So a target like CIFS/srv1<marshalled-blob> yields an authentication blob for CIFS/srv1, while the ugly full string is a valid DNS record the attacker can register and point at their own server.

Net effect: the machine thinks it is authenticating locally (to srv1), but the connection goes to the attacker, who relays it back to srv1's SMB service and runs commands as SYSTEM. It works because when the target is the machine's own hostname/FQDN/localhost/local-IP, Windows uses a local-authentication variant (NTLM copies the client token into the server context; Kerberos matches a subkey stored in both the AP-REQ and LSASS).

2.1 The patch, and why it was insufficient

Microsoft's fix added a check in the SMB client (mrxsmb!SmbCeCreateSrvCall): if the target name contains marshalled target information, abort. That kills the CMTI trick in the SMB client, and nothing more. André's whole talk is about the words "and nothing more."

3. A generic patch-bypass methodology

The reusable method is disarmingly simple, and worth internalizing as a defender because it is exactly how a patch gets defeated:

1. Understand exactly what it blocks 2. Enumerate ideas it doesn't cover 3. Assess feasible? default-config? 4. Build the selected path

Fig. 1 — The bypass loop. The critical realization for CVE-2025-33073: the patch only addresses the CMTI trick in the SMB client. Everything else, other client protocols, other coercion targets, other coercion primitives, is untouched.

André maps the option space: use other client protocols (RPC/DCOM needs integrity, HTTP's WebClient isn't installed by default), or play with the coercion target (coerce to localhost for local privilege escalation; find a way to change the target port; or find a new Kerberos coercion primitive). Two branches paid off.

4. Bypass #1 — local reflection via SMB custom port + multiplexing (CVE-2026-24294)

For a local privilege escalation, the idea is to force a privileged service to authenticate over SMB to localhost on a custom port the attacker controls, because a localhost target triggers NTLM local authentication. Two Windows features combine to make it work:

  • SMB client custom ports. Since Windows 11 24H2 / Server 2025, the SMB client can connect to a user-defined port (net use \\localhost\share /tcpport:...), available to a low-privileged user by default.
  • SMB session multiplexing. Per MS-SMB2, multiple authenticated sessions can be multiplexed over one TCP connection, and the Windows client reuses connections. This sidesteps the constraint that a coercion doesn't let you choose the target port and that net use only affects your own logon session: the privileged service's coerced authentication rides the attacker's already-established connection to the custom-port listener.

The result is a low-privileged user reflecting a SYSTEM service's SMB authentication back to the local SMB service, fixed as CVE-2026-24294, and working by default on Server 2025 (which doesn't enforce SMB signing).

5. Bypass #2 — the Unicode SPN collision (CVE-2025-58726)

This is the clever core of the talk. The goal is a new Kerberos coercion primitive: a target name that is (a) different from the machine's own name, so the DNS client actually resolves it (and the attacker can point it at their server), yet (b) maps to one of the machine's SPNs, so the domain controller issues a service ticket for the real machine. That's an alternative to the now-blocked CMTI trick.

5.1 Why a homoglyph collides

Active Directory stores everything in the ntds.dit database (ESE / B-trees). Because Windows is largely case-insensitive, searches use sort keys generated by LCMapStringEx with the LCMAP_SORTKEY flag. When AD builds a search key for an SPN, it passes flags 0x31403, which include NORM_IGNORECASE, NORM_IGNOREWIDTH, NORM_IGNORENONSPACE, NORM_IGNOREKANATYPE. Under those normalization flags, an ordinary letter and a chosen Unicode look-alike (a homoglyph, e.g. a circled or styled variant of "R") produce the identical sort key. So SRV1 and its homoglyph twin map to the same account, and a Kerberos TGS request for the twinned SPN returns a service ticket for the real SRV1 machine.

Same sort key, different string — the whole bug in one line homoglyph SⓇV1 real SRV1 LCMapStringEx(…, 0x31403) → identical sort key

Fig. 2 — AD's normalization flags make the homoglyph and the real name search-equal, so the DC issues a ticket for the real machine. But other comparisons in the stack normalize differently — and that inconsistency is the exploit.

5.2 The exploit is a normalization inconsistency

Here is the elegant part, and the reason this belongs in the same family as the other "two components disagree" talks in this series. Several Windows components compare strings, but with different normalization:

ComponentComparison usedConsequence
AD SPN search (ntds.dit)sort key with full normalization (0x31403)homoglyph SPN = real SPN → DC issues a ticket for the machine
DNS record uniquenesssame sort-key searcha plain homoglyph collides with the existing record → can't register it as-is
DNS client loopback check (dnsapi!Query_MatchAndGetLocalMachine)CompareStringW with only NORM_IGNORECASEhomoglyph ≠ machine name → the client does resolve it (doesn't treat it as "self")

So the attacker needs a name that is simultaneously: search-equal to a machine SPN (so the DC cooperates), not search-equal to the existing DNS record (so it can be registered), and not loopback-equal to the machine name under the weaker DNS-client comparison (so it gets resolved to the attacker's server). Because the different components normalize differently, such a name exists. André finds candidates using homoglyphs plus Unicode variants of the dots in the FQDN, threading all three constraints. Registering that record and coercing against it rebuilds Kerberos reflection, RCE as SYSTEM once again. It was fixed as CVE-2025-58726.

The pattern, again. This is the Active-Directory instance of the theme running through Ghost Bits, IntentGuard, and the DFIR-agent talk: a security decision assumes one canonical form of an identifier, and different parts of the system canonicalize it inconsistently. Unicode is a rich source of these because "equal" has many definitions (case, width, combining marks, homoglyphs) and different code paths pick different ones. Orange Tsai's prior work on Windows charset conversion is cited as kindred research.

6. Bypass #3 — Kerberos loopback via relay forwarding (CVE-2026-26128)

After the October patch, the SMB service (srv2.sys) started rejecting local authentication that arrives from a remote IP. André's next move (with a bigger prerequisite: a "ghost" SPN or the ability to add an SPN to the machine account) is to make the authentication genuinely originate from a local IP by having the attacker forward the relayed AP-REQ so it re-enters the machine locally, defeating the "must come from a local IP" check while the Kerberos loopback subkey still matches. Fixed as CVE-2026-26128; works by default on non-Windows-11 versions (Windows 11 enforces SMB signing, which blocks it).

7. The real fix: sign loopback SMB

Both of the later vulnerabilities were ultimately closed with the same structural change: a check in srv2!Smb2ExecuteNegotiateReal that requires signing on loopback SMB connections. Relaying breaks when the session must be signed, because the attacker can't forge the signature. Two caveats the talk stresses:

  • The behavior is gated by a registry value (RequireSecuritySignatureForLoopback, default 1). Set it to 0 and the vulnerabilities come back.
  • This fixes the SMB service in its default configuration. The Kerberos coercion primitive itself, the Unicode homoglyph, still works against other services that don't enforce channel binding or signing.
The bonus that matters most operationally. André shows the surviving Kerberos coercion primitive applied to SCCM's AdminService: since SCCM 2509 rejects NTLM, defenders may assume relay is dead there, but a standard user can compromise an SCCM install by default via Kerberos reflection/relay through the AdminService. The same likely applies to MSSQL. The lesson: killing NTLM does not kill relay if Kerberos coercion is still possible and the target doesn't enforce channel binding.

8. Defensive takeaways

  • Enforce SMB signing everywhere, and never set RequireSecuritySignatureForLoopback to 0. Windows 11's default-on signing is why it resisted several of these; bring the rest of your estate to that bar.
  • Enforce channel binding (EPA) on HTTP/LDAP/MSSQL services that can be relay targets. For SCCM's AdminService, where channel binding can't yet be enforced, filter inbound traffic to the AdminService and outbound traffic from the primary site server.
  • Don't treat "NTLM disabled" as "relay-proof." Kerberos coercion primitives exist; a service that only rejects NTLM is still exposed if it doesn't bind the channel.
  • Restrict DNS record creation. Authenticated users can add DNS records by default, which is a precondition for these coercion tricks. Constrain who can create records where feasible.
  • Patch promptly and completely. This whole chain exists because the first fix was scoped narrowly. Assume adversaries read patches the way André does.
Is this exploitable by a normal domain user?

Several links in the chain work by default for a standard authenticated user (registering a DNS record is allowed by default; SMB custom ports are low-priv). Some later variants need a bigger prerequisite (a ghost SPN or the ability to add an SPN). The SCCM bonus is explicitly "any SCCM installation compromised by default with a standard user account."

Why does a Unicode look-alike defeat the check?

Because AD's SPN search and the DNS client's loopback check normalize strings with different flags. Under AD's full normalization the homoglyph equals the real name (so the DC issues a ticket for the machine); under the DNS client's weaker case-only comparison it does not equal the machine name (so it gets resolved to the attacker). The gap between the two normalizations is the bug.

Does enforcing SMB signing fully solve it?

It solves reflection to the SMB service in the default configuration, which is the highest-impact target. It does not remove the Kerberos coercion primitive, which still threatens other services (SCCM, likely MSSQL) that don't enforce channel binding. Defense has to cover those separately.

What's the single most important control?

SMB signing enforced (including on loopback), plus channel binding on your web/DB relay targets. Together they remove the "relay the authentication somewhere useful" step that every variant depends on.

Takeaways

  • Authentication reflection = coerce a privileged service to authenticate, relay it back locally as SYSTEM. The 2025 fix blocked only one narrow trick.
  • A generic bypass methodology, understand the patch, enumerate what it doesn't cover, build the uncovered path, turned one CVE into three.
  • The Unicode SPN collision is the clever core: a homoglyph is search-equal to a machine SPN under AD's normalization but not loopback-equal under the DNS client's, rebuilding Kerberos coercion.
  • It's another normalization/parser differential: different Windows components canonicalize the same identifier differently.
  • The real fix is SMB signing enforced on loopback, gated by a registry key you must not disable.
  • Killing NTLM isn't enough, the Kerberos coercion primitive still compromises SCCM's AdminService (and likely MSSQL) by default without channel binding.

References & further reading

← prev: Key Zeroization next: WhatsApp E2EE Attacks →
© cvam — written in plaintext, served warm