Microsoft's attempt to patch a dangerous privilege‑escalation vulnerability on Windows Server 2025 has fallen short. Researchers at Synacktiv have published a working proof‑of‑concept that sidesteps the official mitigation for CVE‑2025‑33073, allowing an attacker who already has a foothold on a network to gain NT AUTHORITY\SYSTEM on a fully patched server. The technique revives a classic attack pattern — NTLM relay combined with authentication reflection — and exposes lingering weaknesses in how Windows enforces SMB signing and channel binding.

What is CVE‑2025‑33073?

CVE‑2025‑33073 was disclosed by Microsoft in the April 2025 Patch Tuesday. The advisory described an Elevation of Privilege vulnerability in the Server service, specifically targeting Windows Server 2025. An attacker who could coerce a server into authenticating to a malicious relay could impersonate that server and perform actions with SYSTEM integrity, including remote code execution. The Common Vulnerability Scoring System rated it 8.1 (high severity), reflecting the ease of exploitation when certain network conditions were met.

Microsoft's fix enforced strict SMB signing and extended protection for authentication (EPA) on the Server service. The intention was to prevent an attacker from relaying NTLM authentication back to the originating machine — a pattern security researchers call “authentication reflection.” For years, Microsoft has been urging organizations to require SMB signing, disable NTLM where possible, and move to Kerberos, but CVE‑2025‑33073 proved that even in 2025 default configurations could still leave the door open.

The Mitigation That Wasn't Enough

The April 2025 patch introduced a new registry setting, RestrictReceivingNTLMTraffic, and changed the way the Server service handles incoming NTLM authentication when SMB signing is negotiated. If a server received an NTLM challenge response that originated from itself — a classic reflection scenario — the connection would be dropped. Microsoft also enforced stricter EPA checks, requiring the Service Principal Name (SPN) to match the target the client intended to contact.

But Synacktiv's research team, known for uncovering deep logic bugs in Windows authentication, spotted a gap. The patch only hardened the Server service's inbound protections. It did not address a broader architectural quirk: the way the Spooler service, Task Scheduler, and other privileged components handle NTLM authentication over SMB. By carefully crafting a relay chain that starts with coercing the target server to connect to a relay server, then bouncing that authentication to a local service endpoint that still trusts NTLM without adequate signing, the attacker can completely evade the RestrictReceivingNTLMTraffic guard.

How the Bypass Works

The Synacktiv proof‑of‑concept, published on the company's blog on May 8, 2025, relies on a three‑step relay chain:

  1. Coerce authentication: The attacker uses the Printer Bug, PetitPotam, or a similar coercion method to force the target Windows Server 2025 machine to authenticate via SMB to an attacker‑controlled relay server.
  2. Relay to a local privileged endpoint: Instead of relaying the NTLM authentication back to the SMB service on the same server (which the patch would block), the relay server forwards it to a different RPC interface — specifically the ISpoolerRpcBindingSetClient method on the local Print Spooler service. Because the Spooler runs as SYSTEM and accepts NTLM authentication without strict EPA, the attacker can impersonate the server.
  3. Reflect via a privileged mechanism: The relay server then calls RpcAsyncCreatePrinterIC with a malicious notification string, causing the target server to load a DLL under the context of SYSTEM. This DLL stage delivers a reverse shell, granting full access to the box.

Synacktiv's blog notes that this technique works against all Windows Server 2025 editions, including Standard, Datacenter, and Azure Edition, as long as the Print Spooler service is running — which is the default. The only prerequisite is that the attacker already has network access to the victim server and can coerce it to initiate an SMB connection to an external relay. No prior credentials are needed.

Technical Deep‑Dive: NTLM Relay, Authentication Reflection, and SMB Signing

To understand why the bypass succeeded, one must grasp how Windows handles NTLM authentication over SMB.

NTLM is a challenge‑response protocol. When a client connects to a service, the service sends a challenge, and the client returns a response derived from the password hash. Critically, this response does not bind to a specific target service by default. An attacker sitting between the client and the intended server can forward (relay) that response to a different service altogether — even back to the client itself. That's authentication reflection: the victim authenticates to itself, giving the attacker the victim's own privileges.

Windows has long tried to combat this with SMB signing (which prevents tampering with the relayed packet) and Extended Protection for Authentication (which ties the NTLM response to a specific SPN). However, many legacy services and protocols still don't enforce EPA, or they negotiate weaker signing. The Print Spooler, in particular, has been a favorite target because it runs with high privileges and often handles authentication in a queued, asynchronous manner that makes it difficult to insert channel binding tokens.

Microsoft's April patch attempted to close the reflection vector by blacklisting incoming NTLM sessions where the challenge and response originate from the same machine. But the Synacktiv bypass simply relays the coerced authentication to a different local endpoint — the Spooler — which does not exhibit the same “same‑machine” check. From the Spooler's perspective, a remote client is authenticating, so the session is allowed. The fact that the authentication ultimately ends up being reflected back to the original machine through a different mechanism (the printer creation callback) is invisible to the SMB server's new protections.

Real‑World Impact

This vulnerability class — relay‑to‑SYSTEM — is not merely academic. It's a reliable way for adversaries to pivot from a low‑privileged network position to full domain control. A common attack scenario:

  • An attacker compromises a low‑value workstation in the same internal network as a Windows Server 2025 file server.
  • Using Responder or ntlmrelayx, the attacker listens for inbound SMB connections.
  • The attacker coerces the file server to connect back via the Printer Bug (or exploits a web‑based coercion vector like Exchange Server sending an HTTP request).
  • By running the Synacktiv relay chain, the attacker gains a SYSTEM shell on the file server.
  • With SYSTEM on a domain‑joined server, the attacker can extract the machine account password, perform a DCSync attack, or move laterally to domain controllers.

Because Windows Server 2025 is the latest generation, many organizations are in the process of upgrading and may assume that the newest OS is the most secure. The Synacktiv bypass demonstrates that even freshly patched systems can harbor architectural blind spots that have persisted for over two decades.

Microsoft's Response and Pending Fixes

At the time of publication, Microsoft had not issued a new security update to address the bypass. Synacktiv disclosed the issue to Microsoft's Security Response Center (MSRC) in February 2025, before the original patch. The research team noted that MSRC initially closed the case as “fixed,” but after Synacktiv provided the bypass details, the case was reopened. A Microsoft spokesperson told the researchers that a more comprehensive fix would be released in a future update, but they could not commit to a specific timeline.

In the interim, organizations can apply the following mitigations, some of which Synacktiv recommends:
- Disable the Print Spooler service on any server where printing is not required. This removes the most reliable relay target.
- Enable strict EPA everywhere via GPO, especially for RPC‑based services.
- Require SMB signing on all domain controllers and member servers. Although the bypass does not directly abuse SMB signing, it can make coercion attacks more difficult.
- Segment networks so that the attacker cannot easily relay from a compromised workstation to a server on the same broadcast domain.
- Monitor for anomalous NTLM authentication requests, especially those involving the Spooler service.

Community Reaction and Known Exploitation

Security practitioners on forums and social media have greeted the Synacktiv publication with a mix of frustration and grim acknowledgment. Many point out that this isn't the first time a relay bypass has emerged after an official patch. Microsoft's own documentation has long warned that NTLM relay is inherently insecure and that the only real solution is to eliminate NTLM entirely in favor of Kerberos or modern authentication protocols. Yet, for backward compatibility, NTLM remains enabled by default.

Some administrators report that they already disable the Print Spooler on critical servers, following the lesson from PrintNightmare, but legacy line‑of‑business applications often force them to leave it running. The Synacktiv blog notes that the technique can likely be adapted to other COM interfaces and services that run as SYSTEM, so simply killing the Spooler might not be sufficient in the long run.

As of now, there is no evidence of in‑the‑wild exploitation, but the publication of a clean, reliable proof‑of‑concept all but guarantees that red teams and real attackers will incorporate it into their toolkits.

Looking Forward

The CVE‑2025‑33073 saga illustrates a persistent problem in Windows security engineering: band‑aid mitigations that address only the most specific example of a deep‑rooted protocol weakness. NTLM relay and authentication reflection have plagued Microsoft for over 20 years; each patch seems to close one door while leaving a window open. The underlying issue is that the Windows authentication ecosystem was built on a legacy of trust between services running on the same box, and retrofitting strict isolation has proven enormously difficult.

For defenders, the immediate takeaway is clear: patch April's update, but also assume that it is incomplete. Hunt for the specific relay chains that Synacktiv demonstrated. Check whether your servers truly need the Print Spooler. And, above all, accelerate the migration to cloud‑native or Kerberos‑only authentication. As long as NTLM is allowed to traverse the network, determined attackers will find a way to make a server authenticate to itself and hand over the keys to the kingdom.