Windows Server 2025 got a new feature. Attackers got SYSTEM

An attack that refuses to die

Relay attacks, where the attacker takes up a position in the middle, are one of the most common vectors we see both on our own pentests and in high-profile breaches and ransomware cases. In a typical network there is always some machine, service, or user that can be pushed into passing its authentication traffic through the attacker's box. From there it is a short step to privilege escalation and lateral movement across the network.

Sometimes, though, the attacker has it harder. Little traffic, a handful of services, literally a few users moving around the network, and nobody to send the captured authentication to. That is when NTLM reflection comes into play: bouncing authentication back to the same machine it came from. A relay to itself. When there is no other target at hand, it is one of the simpler ways in.

Windows has known this problem since 2008, when bulletin MS08-068 blocked the classic SMB-to-SMB version. For nearly two decades Microsoft patched one variant after another, and every few years the industry announced that reflection was finally dead. Every time it came back in a new disguise.

In June 2025 researchers from Synacktiv (with input from other teams) showed that a cleverly crafted DNS name is enough to fool the system into forcing local authentication. That was CVE-2025-33073. The mechanism is called CMTI, or CredMarshalTargetInfo: extra data is appended to the target name, LSASS trims it only at the very end, so authentication is generated for a different name than it appears to be. That vulnerability has been in CISA's Known Exploited Vulnerabilities catalog since October 2025, with a remediation deadline for federal agencies set for November 10. Not an academic curiosity, but something used in real breaches.

Why one patch was not enough

Microsoft's June 2025 fix changed the mrxsmb.sys driver so that it rejects connections to names with appended data. It closed one specific path. It did not touch the cause.

Synacktiv noticed that right away. In their view the patch treated the symptom: it removed one trick, not the underlying fact that Windows components can be pushed into bouncing local authentication back. Guillaume André's team returned to the topic and in April 2026 published a two-part study describing a bypass of the patch along with two new vulnerabilities. The first of them is CVE-2026-24294. The title of their Black Hat Asia 2026 talk captures the situation well: “the gift that keeps on giving”.

For a defender there is one takeaway. Installing an update and understanding the risk are two different things. A narrow patch closes the reported exploit but leaves a whole class of behavior untouched, and then the next CVE for the same thing shows up.

The vector: any TCP port and SMB multiplexing

Windows 11 24H2 and Windows Server 2025 added the option to mount an SMB share on any TCP port, not only the classic 445. You do it with the /tcpport parameter. The feature itself is reasonable, because it gives flexibility for unusual deployments. The problem is not in the feature. The problem is what an old attack can do with it.

The mechanism is short. The attacker stands up a local SMB server on a non-standard port and mounts the share, which opens a persistent TCP connection:

net use \\127.0.0.1\share /tcpport:12345

Then they force a privileged process (LSASS runs as SYSTEM) to reach for that same UNC path. Because the TCP connection already exists, Windows prefers to reuse it rather than build a new one. The privileged NTLM session travels over the attacker's transport and gets bounced back to the real SMB service on port 445. The result: a session with SYSTEM rights.

NTLM reflection did not die. It only changed transport.

What this means beyond one server

SYSTEM on a single machine is already a bad day. But it rarely ends there.

If the compromised server has Unconstrained Delegation enabled, the attacker can force authentication from a domain controller. The TGT of the DC computer account then lands in LSASS memory. From there it is a straight road to DCSync and taking over the whole Active Directory domain. One hop from a local user to domain administrator. That is the consequence worth showing the board before the question “but we have everything patched” comes back.

Who is really in the crosshairs

Windows Server 2025 in its default configuration, where SMB signing is not enforced, is the critical scenario. The path described above works and leads straight to SYSTEM.

Windows 11 24H2 enforces outbound SMB signing by default, which blocks this particular relay. And here the trap in the word “default” shows up. New systems ship with sensible settings: required SMB signing, channel binding for LDAP, EPA on ADCS web enrollment, NTLMv1 disabled. On a fully patched Server 2025 the classic relay chain is blocked.

The trouble is that almost nobody runs a fully uniform environment. One domain controller on Server 2019 that nobody updated is enough. One ADCS server without EPA enabled is enough. The attack does not go after the strongest link, only the weakest, and in mixed infrastructure there is always one. On top of that comes the whole family of coercion techniques the attacker has at hand: PetitPotam (through MS-EFSRPC), PrinterBug through the print service, DFSCoerce, ShadowCoerce. Some of them work without authentication on a default Server 2019 or 2022. And if you do enforce SMB signing, there is still coercion over WebDAV, which goes around all of that protection because it targets services over HTTP.

How to defend

Classic antivirus and EDR have a problem with this, because the whole attack is valid net use commands and protocol-compliant SMB traffic. There is no malicious file to detect. Detection has to look at behavior, not signatures: unusual SMB traffic going out to high ports, SMB authentication from processes that should not be generating it, coercion sequences in network telemetry.

On the configuration side it is worth treating this in layers, because no single option closes every path.

Do this right away:

• Deploy the patches for CVE-2026-24294 (March 2026) and the earlier CVE-2025-33073 (June 2025), with particular priority for Windows Server 2025.
• Turn on NTLM auditing. The tooling has been available in 24H2 and Server 2025 since late 2025 and shows where NTLM is really still working. You cannot fix what you cannot see.
• Enforce SMB signing on servers and clients, not just on domain controllers. It is a barrier at the protocol level. You can check the state with Get-SmbServerConfiguration | Select RequireSecuritySignature and enforce it with Set-SmbServerConfiguration -RequireSecuritySignature $true.

A deeper layer, because the attacker will look for a way around anyway:

• Enforce signing and channel binding for LDAP on domain controllers (LdapEnforceChannelBinding set to 2) to close the relay to LDAP.
• Enable EPA on ADCS web enrollment. That is direct protection against a relay to the certificate service (the ESC8 path), which SMB signing alone does not catch.
• Cut off the coercion vectors: disable the print service where it is not needed, apply RPC filters (netsh rpc filter) that restrict remote calls to dangerous interfaces, disable LLMNR and NBT-NS.
• Limit the ability to initiate SMB connections on ports other than 445 and monitor the use of net use and New-SmbMapping on unusual ports.

Timing matters. Once a public PoC exists (and for CVE-2026-24294 it does), the window between disclosure and exploitation attempts gets short. This is not a fix for “the next maintenance window a quarter from now”.

The real fix is strategic

Here we get to the heart of it. NTLM is a protocol from 1993, designed for a world of standalone workstations and simple workgroups. Microsoft officially deprecated it in 2024 and says outright that some of its weaknesses cannot be patched, because they sit in the design itself. Reflection, pass-the-hash and relay are not separate bugs. They are symptoms of the same aging mechanism.

That is why Microsoft laid out the NTLM phase-out in three stages. Stage one is audit and visibility, available now in 24H2 and Server 2025. Stage two, planned for the second half of 2026, adds IAKerb and a local KDC, features that remove the most common reasons systems reach for NTLM at all (no connectivity to a domain controller, local accounts). Stage three, with the next major Windows Server release, will disable network NTLM by default. The protocol stays in the system as something you can deliberately turn on, but the safety net disappears.

For the board it comes down to one sentence: patching one NTLM CVE after another is firefighting, and the destination is a move to Kerberos. The time between now and that default shutdown is the window to map dependencies and migrate, before another system or another attacker does it for you.

In closing

The least pleasant thing about this vulnerability is that it asks nothing sophisticated of the attacker. Honestly: on internal tests we like primitives of this kind, because it is a clean, single-step road to SYSTEM, and from there usually a short hop to the whole domain. That is exactly why it is worth having someone check it at your place before someone less friendly does.

The question is this: on your 2025 servers, is SMB signing actually enforced, or only “planned for later”? And do you know how much of your network still speaks NTLM?