Microsoft has published advisory guidance tied to CVE‑2025‑55234 that focuses less on a new exploitable bug and more on enabling administrators to find and measure exposure to SMB relay‑style elevation‑of‑privilege attacks before they flip stronger hardening controls. The short form: the SMB Server can still be used in relay scenarios depending on configuration, and Microsoft’s September 2025 updates expose new audit events so teams can safely assess compatibility and identify devices or software that will break when SMB hardening (SMB signing, Extended Protection for Authentication / EPA, NTLM blocking) is enforced. (learn.microsoft.com)
Administrators should treat the September 2025 audit events as a priority tool in their identity and network hardening playbook. Begin audits now, build remediation roadmaps, and avoid blanket enforcement before you’ve identified and addressed incompatible endpoints. The combination of SMB signing, EPA, NTLM blocking and SMB dialect management is the right technical direction — but it must be executed with inventory, test rings, vendor coordination, and robust logging so the transition does not become a production outage risk.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Why SMB relay attacks still matter
SMB (Server Message Block) is a decades‑old networking protocol used for file and printer sharing, named pipes, and many Windows‑centric features. Because it is so widely deployed — on workstations, file servers, backup appliances, NAS devices and virtual appliances — weaknesses in SMB configuration remain a favorite attack surface for adversaries. NTLM relay attacks, specifically, rely on coercing a user or device to authenticate to an attacker‑controlled endpoint, then relaying those NTLM authentication tokens against a service that will accept them. When successful, a relay attack can lead to lateral movement, privilege escalation, mailbox access, certificate issuance or even domain compromise. Microsoft and industry researchers have repeatedly observed NTLM relay techniques used in real campaigns. (msrc.microsoft.com, semperis.com)What Microsoft changed (high level)
Rather than introducing a single urgent fix for a new code‑level bug, Microsoft is using CVE‑2025‑55234 as the vehicle to publish audit tooling and events that make it practical to discover which devices or third‑party servers do not support the hardening features required to blunt relays — namely SMB signing, Extended Protection for Authentication (EPA) and SMB encryption / dialect controls. Those audit events were shipped as part of the Windows 11 / Windows Server updates around September 2025 and are intended to let administrators operate in audit‑first mode: discover, triage, and remediate incompatible endpoints before flipping enforcement. (learn.microsoft.com)Overview: SMB hardening primitives explained
SMB signing
- What it does: cryptographically signs SMB messages so recipients can verify messages are from the expected party and have not been tampered with.
- Why it helps: signing prevents an attacker from transparently relaying NTLM authentications — signed sessions cannot be replayed on a server that requires a signature mismatch.
- Default changes: Starting with Windows 11 24H2 and Windows Server 2025, SMB signing is required by default for many connection types; administrators can audit and enforce policy through Group Policy and PowerShell. (learn.microsoft.com)
Extended Protection for Authentication (EPA)
- What it does: EPA binds authentication to the channel (via channel binding tokens) and to the service (via SPNs). It prevents a client from being tricked into authenticating to an attacker‑controlled intermediary.
- Where it’s used: historically in IIS and Exchange, now increasingly enabled for AD CS, LDAP and other services in Server 2025. EPA is the primary mitigation for NTLM relay coercion techniques that leverage web or RPC endpoints. (learn.microsoft.com, msrc.microsoft.com)
NTLM blocking / LmCompatibilityLevel
- What it does: prevents SMB clients from negotiating weaker NTLM protocols or prevents NTLM usage entirely in outbound SMB sessions.
- Why it helps: NTLM is the authentication primitive that can be relayed. Blocking NTLM or requiring Kerberos reduces the available primitives for relays.
- Administrative notes: Windows Server 2025 and Windows 11 include policies and controls to block outbound NTLM on SMB and to create exception lists for legacy servers that cannot be upgraded. (learn.microsoft.com, techcommunity.microsoft.com)
What CVE‑2025‑55234 actually provides administrators
Microsoft’s advisory (the CVE record and accompanying security update guidance) does three things of operational value:- Adds SMB audit events and Group Policy / PowerShell controls so that servers can log when a connecting client does not support signing or encryption, or when a client uses insecure guest logons. These events allow a phased rollout from audit to enforcement. (learn.microsoft.com)
- Surfaces compatibility aids such as audit modes and explicit toggles (similar to Netlogon RPC hardening work) so vendors and IT teams can find devices that will break if hardening is enabled and address them first. The Netlogon hardening experience from mid‑2025 — which added Audit and Disabled modes to permit staged adoption — is the operational template Microsoft advocates. (support.microsoft.com)
- Recommends that administrators adopt SMB signing and EPA as key hardening measures, but first assess their estate using the audit events shipped with the September 2025 security updates. This advisory is intentionally framed as an assessment tool to reduce disruption when enforcement is later made more aggressive. (learn.microsoft.com)
How the new audit events work — practical details
Microsoft added event types and corresponding Group Policy / PowerShell toggles for auditing SMB client and server behaviors:- New Group Policy settings (paths):
- Computer Configuration\Administrative Templates\Network\Lanman Server\Audit client does not support encryption
- Computer Configuration\Administrative Templates\Network\Lanman Server\Audit client does not support signing
- Computer Configuration\Administrative Templates\Network\Lanman Server\Audit insecure guest logon
- PowerShell equivalents (examples):
- Set-SmbServerConfiguration -AuditClientDoesNotSupportEncryption $true
- Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true
- Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true
- (Use Get-SmbServerConfiguration and Get-SmbClientConfiguration to read state.) (learn.microsoft.com)
- SMB Server audit events: Event IDs 3021 and 3022 (examples: server rejected connection due to missing signing/encryption).
- SMB Client audit events: Event IDs 31998 and 31999 (examples: client observed server does not support encryption/signing). (learn.microsoft.com)
A recommended phased deployment plan
The purpose of the audit capability is to permit a staged migration from permissive to strict. The following sequence is the operationally safest path:- Inventory and baseline
- Run network discovery to find SMB servers: Windows file servers, NAS appliances, backup targets, print servers and any appliance that advertises SMB (TCP/445) externally or internally.
- Record vendor/firmware versions for each device and note any that historically require SMBv1 or lack signing support.
- Enable audit on a small subset
- Pick a small set of test servers (file servers and a sample of client endpoints).
- Enable the SMB audit settings (PowerShell commands above) and collect logs for 7–14 days.
- Export event logs and correlate with asset inventory.
- Triage incompatible clients/servers
- Classify findings:
- Devices that refuse signed connections (incompatible third‑party SMB stacks).
- Clients that prefer guest logons or insecure fallbacks.
- Systems that insist on NTLMv1 or cannot use Kerberos.
- For each incompatible item, either apply vendor firmware/software updates, reconfigure to support signing/EPA, or plan an exception/segmentation strategy.
- Address vendor/device incompatibilities
- Contact vendors for firmware patches or configuration guidance.
- Replace or isolate devices that cannot be updated (use micro‑segmentation or VLANs to keep them away from domain controllers and critical assets).
- Move from Audit to Enforcement
- After a satisfactory audit window and remediation work, flip policies to require signing/EPA on servers and block NTLM on SMB clients where feasible.
- Closely monitor authentication failures and use the audit logs to identify any missed devices.
- Continuous monitoring
- Keep SMB auditing enabled in production as a permanent detection control to spot regressions or newly introduced legacy devices.
- Integrate with asset lifecycle management so that newly added devices are checked for SMB hardening compatibility. (learn.microsoft.com)
Concrete commands & policy names (copy‑ready)
- PowerShell — enable server‑side audits:
- Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true
- Set-SmbServerConfiguration -AuditClientDoesNotSupportEncryption $true
- PowerShell — enable client‑side audits:
- Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true
- Set-SmbClientConfiguration -AuditServerDoesNotSupportEncryption $true
- Group Policy paths to look for (Administrative Templates):
- Computer Configuration → Administrative Templates → Network → Lanman Server → Audit client does not support signing/encryption
- Computer Configuration → Administrative Templates → Network → Lanman Workstation → Audit server does not support signing/encryption
- Event log paths & IDs:
- Applications and Services Logs\Microsoft\Windows\SMBServer\Audit — Event IDs 3021, 3022
- Applications and Services Logs\Microsoft\Windows\SMBClient\Audit — Event IDs 31998, 31999
Compatibility and risk considerations — what can break
- Third‑party SMB servers and older NAS appliances frequently implement only a subset of SMB 3.x capabilities. They may advertise SMB 3.1.1 but not implement signing/encryption correctly. Audit events will flag these devices. Expect vendors to release firmware patches or require configuration changes. (learn.microsoft.com)
- Legacy devices that require guest or anonymous access will fail if you enforce signing or block guest logons. Consider segmentation or proxies that mediate access for legacy devices.
- Hybrid and cloud‑connected services (Exchange hybrid configurations, AD FS, appliances using LDAP/AD) may rely on NTLM coercion patterns; enabling EPA in one piece of the stack without auditing the rest can create outages. Use the audit window to identify and remediate such chained dependencies. (msrc.microsoft.com, techcommunity.microsoft.com)
- Vendor compatibility modes: Microsoft’s past rollouts (for Netlogon hardening) included Audit and Disabled registry modes to permit staged adoption when ecosystem readiness lagged. Expect similar migration windows for SMB hardening; resist flipping enforcement globally until third parties and device fleets have been assessed. If you must maintain temporary compatibility, use targeted firewall rules and exceptions instead of globally disabling hardening. (support.microsoft.com)
Detection and hunting guidance
- Build SIEM rules to alert on:
- SMB Server Audit event 3021/3022 with a unique source IP that indicates a server refused a client because it didn't support signing/encryption.
- SMB Client Audit events 31998/31999 showing clients encountering servers that do not support signing/encryption.
- Sudden surge in SMB authentication failures from a single subnet (possible staging of relay attack).
- Hunt for anomalous outbound SMB connections to unexpected external IPs — such flows may be a precursor to coercion/relay techniques used by attackers.
- Correlate SMB audit events with lateral movement indicators (new service creations, unexpected scheduled tasks, domain controller ticket requests) to detect chained exploitation sequences. (semperis.com, learn.microsoft.com)
Vendor and community reaction — what practitioners are saying
Industry coverage and community threads emphasize the operational tradeoffs: enforcing signing and EPA is the right security direction, but the ecosystem has many legacy devices requiring careful planning. News and commentary echo Microsoft’s posture: audit first, then enforce. Community guides and forums provide practical playbooks that mirror Microsoft’s recommended phased approach. Windows administrator communities have also documented the same runbook used successfully for Netlogon RPC hardening: enable audit, identify incompatibilities, notify vendors, then pivot to enforcement. (bleepingcomputer.com)Critical analysis: strengths and limitations of Microsoft’s approach
Strengths
- Operationally prudent: shipping audit events reduces the odds of unexpected outages when enforcement is enabled, enabling a realistic migration path.
- Defence‑in‑depth alignment: requiring signing, enabling EPA and offering NTLM blocking together reduce the primary primitives that allow relays and credential replay.
- Ecosystem focus: Microsoft is not just changing defaults on Windows but also giving guidance and tools to help identify non‑Windows or third‑party devices — a necessary step in heterogeneous environments. (msrc.microsoft.com, learn.microsoft.com)
Limitations and risks
- Reliance on vendor responsiveness: many appliances and legacy systems will not be updated quickly; organizations with large device diversity face long migration timelines.
- False sense of security if only partially deployed: enabling only server‑side signing without client hardening or without EPA leaves attack paths open. Attackers can weaponize the weakest link.
- Audit fatigue and alert noise: default audit events can generate large volumes of logs in complex networks. Without careful triage and automation, teams may miss real threats.
- Incomplete public technical details: CVE entries that serve as policy/audit announcements sometimes lack low‑level exploitability data, which is fine for this use case but complicates risk scoring. Administrators should therefore rely on the audit data and in‑house testing rather than waiting for exploit proof‑of‑concepts. (learn.microsoft.com, securityweek.com)
Quick operational checklist — immediate actions (what to do in the next 7–14 days)
- 1.) Confirm all servers are at the required patch level and that the September 2025 SMB audit events are present.
- 2.) Enable SMB audit settings in a small pilot ring (use the PowerShell commands above).
- 3.) Export and correlate audit events with your asset inventory; create a prioritized remediation list.
- 4.) Contact vendors for firmware updates for any NAS, backup appliance, or printer server that does not support signing/EPA.
- 5.) Where vendor updates are not available, implement network segmentation and firewall rules to limit those assets’ exposure to sensitive resources.
- 6.) Prepare a communication plan for application owners if enforcement causes authentication failures in production.
- 7.) After a satisfactory audit window and remediation work, enable enforcement in stages, starting with domain controllers and high‑value servers. (learn.microsoft.com, support.microsoft.com)
Monitoring and post‑deployment validation
- Validate enforcement by attempting controlled connections from test clients that do and do not support signing/EPA and confirm expected rejections and events.
- Monitor for reappearance of audit events and for new devices joining the network that lack signing support.
- Maintain a rolling inventory of all devices that had exceptions; include a timeline for replacement or remediation.
Final assessment
CVE‑2025‑55234 is not a classic single‑exploit, code‑execution advisory — it is a practical operational mechanism designed to accelerate a safer SMB ecosystem by giving administrators the telemetry and audit controls needed to move from permissive to strict configurations without breaking services. The approach is sound: enable detection, find incompatibilities, remediate or isolate, and then enforce signing and EPA permanently. That said, the success of this initiative depends on careful planning, vendor cooperation, and the discipline to treat NTLM as a legacy risk that must be cataloged and shrunk across the estate.Administrators should treat the September 2025 audit events as a priority tool in their identity and network hardening playbook. Begin audits now, build remediation roadmaps, and avoid blanket enforcement before you’ve identified and addressed incompatible endpoints. The combination of SMB signing, EPA, NTLM blocking and SMB dialect management is the right technical direction — but it must be executed with inventory, test rings, vendor coordination, and robust logging so the transition does not become a production outage risk.
Key configuration references (recap)
- Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true. (learn.microsoft.com)
- Group Policy: Computer Configuration → Administrative Templates → Network → Lanman Server → Audit client does not support signing. (learn.microsoft.com)
- Watch Event IDs: SMB Server 3021/3022, SMB Client 31998/31999. (learn.microsoft.com)
Source: MSRC Security Update Guide - Microsoft Security Response Center