CVE-2025-33073: Privilege Escalation via NTLM Reflection in Windows SMB Client

Overview

CVE-2025-33073 is a high-severity elevation of privilege vulnerability in the Windows SMB client. The issue stems from improper access control in the SMB authentication flow and can allow an attacker with low privileges to obtain SYSTEM-level access by abusing NTLM reflection/relay patterns. It is not a remote code execution bug by itself, but in enterprise environments it becomes a powerful step toward host takeover and domain compromise when combined with coercion techniques and weak SMB/NTLM hardening.

How it works

When a Windows client connects to a remote share or pipe over SMB, it authenticates using NTLM or Kerberos. CVE-2025-33073 exploits a gap in the SMB client’s authentication handling so that an attacker can reflect the victim’s own NTLM authentication back to a service on the victim or a nearby host, ultimately executing actions in a privileged context.

The common pattern starts with coercion- forcing the victim to initiate an SMB authentication to an attacker-controlled listener. Known coercion vectors include protocols and endpoints like Print Spooler (MS-RPRN), EFSRPC (MS-EFSRPC), RPC endpoints, or other intra-Windows mechanisms that can trigger outbound SMB. Once the client authenticates to the malicious server, the attacker relays or reflects the NTLM exchange to a target where improper validation lets the session be accepted at a higher privilege than intended.

Enterprise defenses such as SMB signing, Extended Protection for Authentication (EPA), and strict NTLM policies cryptographically bind sessions or add channel bindings, breaking the reflection path. However, many environments have these controls disabled or partially enabled for compatibility, which re-opens the attack surface.

Example hardening knobs (Group Policy):
Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options
  • Microsoft network client: Digitally sign communications (always) → Enabled
  • Microsoft network server: Digitally sign communications (always) → Enabled
  • Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers → Deny all / Audit
  • Network security: LAN Manager authentication level → Send NTLMv2 response only. Refuse LM & NTLM
  • SMB v1 → Disabled via Windows Features / GPO

Risks

Successful exploitation yields SYSTEM privileges on the victim. From there, attackers commonly dump credentials, implant persistence, and pivot. Because SMB and NTLM are foundational in Windows domains, the blast radius is rarely limited to a single endpoint. Weak signing policies and permissive outbound SMB make lateral movement straightforward, and the vulnerability frequently appears in chained attack paths that culminate in data exfiltration or ransomware deployment.

Key enablers include: lack of SMB signing, permissive NTLM settings, legacy hosts, broad workstation-to-workstation SMB access, and service accounts with excessive privileges.

Real life example usage

Consider an attacker with low-privilege access on a workstation. They run a coercion primitive (e.g., a PrinterBug or EFSRPC trigger) to force the host to authenticate via SMB to a malicious listener on another compromised node. The attacker captures the NTLM authentication and reflects it back to the victim’s SMB service. Due to the client-side validation flaw and weak signing policy, the reflected authentication is accepted and the attacker obtains a session token that maps to a privileged context. They execute a service creation or a named-pipe command to spawn a SYSTEM shell, then dump LSASS to extract additional credentials and move laterally.

Recommendations

Remediation is a combination of patching and protocol hardening. Apply the vendor update that corrects the SMB client authentication handling, then enforce the following controls to collapse the reflection/relay paths.

Patch management

Deploy the June 2025 security update (and subsequent cumulative updates) to all supported Windows client and server releases. Prioritize workstation fleets and jump hosts that initiate SMB connections broadly.

Enforce SMB integrity

Enable SMB signing on both client and server. On sensitive servers, consider SMB encryption (SMB 3.0+) to protect in-flight data and further constrain relay viability.

Harden NTLM

Disable SMBv1 and NTLMv1, enforce NTLMv2 only, and enable EPA/channel binding where Kerberos or NTLM is used. Restrict or deny outbound NTLM to untrusted destinations. Use audit modes first to understand potential operational impacts before moving to enforcement.

Constrain SMB pathways

Segment the network to avoid workstation-to-workstation SMB, restrict outbound SMB from user subnets, and tightly control which hosts can initiate SMB to administrative and Tier-0 assets. Block outbound 445/139 from client VLANs except to sanctioned file services.

Reduce coercion surface

Disable or restrict coercion-prone services and endpoints (e.g., legacy Print Spooler exposure, unnecessary RPC interfaces). Where services are required, scope access and monitor for abuse patterns.

Detect and respond

Instrument SIEM/EDR for NTLM anomalies and SMB signing failures. Hunt for SMB authentications where source and destination suggest reflection, sudden spikes of STATUS_INVALID_SIGNATURE or unsigned SMB sessions, and service creations from non-admin users. Enable Windows event channels relevant to NTLM, SMB client/server, service control manager, and security auditing.

Final thoughts

CVE-2025-33073 underscores that NTLM reflection and SMB relay remain potent in real environments where compatibility trade-offs have weakened protocol guarantees. The patch removes the immediate flaw, but durable risk reduction comes from enforcing signing, tightening NTLM, reducing coercion vectors, and narrowing SMB pathways. Treat this as a chance to modernize your Windows authentication posture across the board.