A proof-of-concept has been published that bypasses Microsoft’s mitigation for the NTLM reflection vulnerability tracked as CVE-2025-33073 and allows escalation to NT AUTHORITY\SYSTEM on Windows Server.
The exploit leverages two conceptual weaknesses left unaddressed by the original patch: the mitigation was limited to the SMB client path, and recent SMB features let attackers coerce privileged services into authenticating over attacker-controlled TCP connections.
The result is a practical local privilege escalation and, in chained scenarios, remote command execution on vulnerable servers.
CVE-2025-33073 originally allowed an attacker who could control DNS records or otherwise influence target names to append base64-encoded “additional target information” after a machine name.
LSASS strips that extra data before constructing NTLM access or Kerberos blobs, so a client ends up authenticating as though to the machine itself.
An attacker-controlled server receiving that authentication can relay the resulting NTLM or Kerberos material back to the target, creating an authenticated SMB session as the SYSTEM account.
The other obvious attack strategy would be to find an alternative to the CMTI technique, allowing us to receive a message AP-REQfor an arbitrary service.
Microsoft’s fix blocked targets containing additional target information at the SMB client (mrxsmb.sys) but left other client protocols and SMB-specific features untouched.
PoC Released for NTLM reflection
According to Synacktiv, the published PoC exploits a Windows 11/Windows Server feature that lets clients specify an arbitrary TCP port when connecting to SMB shares. The technique proceeds in two stages.
First, the attacker sets up a local SMB server listening on a nonstandard port and mounts a share from that server from the target machine.
This establishes a persistent TCP connection that the Windows SMB client will reuse (SMB multiplexing). Second, the attacker forces a privileged service LSASS or another SYSTEM process to access the same UNC path so the client reuses the previously opened TCP connection.
When the privileged service authenticates, its NTLM credentials are captured and relayed back to the machine’s real SMB service, yielding an authenticated session as SYSTEM and enabling command execution.
The PoC chain uses common tools with small modifications: an Impacket-based SMB server (smbserver.py) able to run on a custom port and parse authentication blobs, ntlmrelayx to relay NTLM to the local SMB target, net.exe to mount the custom-port share, and a local forcing primitive (modified PetitPotam).
The technique notably does not require user interaction and works against default configurations of Windows Server 2025; Windows 11 24H2 is less affected where SMB signing is enforced by default.
This bypass highlights two critical lessons. First, patching a single protocol implementation (mrxsmb.sys) without addressing how other protocols force authentication or how SMB multiplexing and custom-port features are used leaves a structural attack surface.
Second, features intended for convenience arbitrary SMB ports and default connection reuse can become enablers for reflection and relay attacks when combined with service-forcing primitives.
Defensive measures beyond the original patch include enforcing SMB signing and channel binding, disabling WebClient/WebDAV where unnecessary, restricting who can create DNS records in Active Directory, and applying strict outbound connection controls for privileged services.
Administrators should also review Microsoft advisories and install Microsoft’s patches for related issues; see the official MSRC entry for CVE-2025-33073 for Microsoft’s guidance and updates: https://msrc.microsoft.com/update-guide/fr-FR/vulnerability/CVE-2025-33073.
Operators should assume Windows Server 2025 machines are at higher risk unless SMB signing and Microsoft’s relevant updates are applied; immediate review and hardening of authentication-exposed services is advised.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
