Windows - Security - ENFORCE SMB Signing

What the SMB signing enforcer does

This Automox Worklet™ enforces mandatory SMB (Server Message Block) digital signing on Windows endpoints by writing the RequireSecuritySignature registry value to 1 for both the SMB server (LanManServer) and SMB client (LanManWorkstation) services. Enabling SMB signing only tells Windows to sign sessions when the peer supports it. Enforcement refuses the session entirely when signing is unavailable, which is what closes the NTLM relay attack path.

The Worklet writes to two registry locations on every run: HKLM:\System\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature and HKLM:\System\CurrentControlSet\Services\LanManWorkstation\Parameters\RequireSecuritySignature. On modern Windows builds, the server-side value is equivalent to running Set-SmbServerConfiguration -RequireSecuritySignature $true, and the client-side value is equivalent to Set-SmbClientConfiguration -RequireSecuritySignature $true. The Worklet uses the registry path directly so the behavior is identical on Windows 8 through Windows 11 and on Windows Server 2012 through Server 2022.

Setting the value to 1 takes effect immediately for new SMB sessions and does not require a reboot. Existing connections continue under their negotiated terms until they close. If a downstream connectivity issue surfaces against a legacy SMBv1 or unpatched third-party SMB server, edit the $requireSMBSigning variable at the top of the script from 1 to 0 and re-run the Worklet to roll back the change on the affected pilot ring.

Why enforce SMB signing across the fleet

NTLM relay over SMB is one of the most reliable lateral movement paths in a Windows environment. An attacker on the same broadcast domain coerces an endpoint to authenticate (PetitPotam, PrinterBug, LLMNR or NBT-NS poisoning), forwards the NTLM challenge to a target file server or domain controller, and either reads files or executes code under the coerced user's context. The mitigation that breaks the chain is mandatory SMB signing: when the relayed session cannot produce a valid signature, the target rejects it. SMB signing that is merely enabled does not break the chain, because the client and server will negotiate down to an unsigned session whenever the attacker wants them to. CIS Microsoft Windows Benchmarks 2.3.9.x (Microsoft network server) and 2.3.10.x (Microsoft network client) treat both "Digitally sign communications (always)" controls as Level 1 settings for member servers and workstations.

Mandatory SMB signing is the registry change that translates the CIS control text into an actual mitigation on each Windows host. A recurring Automox policy against your workstation, file server, and domain controller groups holds RequireSecuritySignature=1 in both LanManServer\Parameters and LanManWorkstation\Parameters, so NTLM relay over SMB stays broken even after image refreshes, GPO inheritance changes, or admin troubleshooting sessions that flip the value back.

How SMB signing enforcement works

1. Evaluation phase: The Worklet reads RequireSecuritySignature from HKLM:\System\CurrentControlSet\Services\LanManServer\Parameters and HKLM:\System\CurrentControlSet\Services\LanManWorkstation\Parameters using Get-ItemPropertyValue with -ErrorAction SilentlyContinue. Each key is checked independently. The endpoint is flagged non-compliant and the script exits 1 if either value is missing or not equal to 1. When both values already read 1, the script writes a compliance message and exits 0.

2. Remediation phase: The Worklet writes RequireSecuritySignature as a REG_DWORD with value 1 to both LanManServer\Parameters and LanManWorkstation\Parameters. New-ItemProperty creates the value when absent and Set-ItemProperty corrects it when present but off-spec. The change is honored by the SMB stack on the next session negotiation, so no reboot is required. The remediation script exits 0 once both registry values are in their desired state.

Requirements for enforcing SMB signing

• Windows 8 or later, or Windows Server 2012 or later, with the Automox agent installed

• Administrative privileges on the endpoint (the Automox agent runs as SYSTEM, which already meets this)

• All SMB peers in the environment (file servers, domain controllers, NAS appliances, third-party SMB endpoints) must support SMB signing; any peer that cannot sign will be unreachable once enforcement is on

• Run the companion Enable SMB Signing Worklet first if the fleet has not already negotiated signed sessions, so enforcement does not flip an unprepared endpoint into a broken state

• Pilot on a representative ring (workstation, member server, domain controller) before fleet-wide rollout to surface legacy SMB peers

• Change the $requireSMBSigning variable at the top of the evaluation and remediation scripts from 1 to 0 if a temporary rollback is needed for a specific group during compatibility testing

Expected SMB behavior after enforcement

After remediation, both registry values read 1 and the endpoint refuses any new SMB session that cannot be digitally signed. Validate from PowerShell with Get-ItemPropertyValue -Path 'HKLM:\System\CurrentControlSet\Services\LanManServer\Parameters' -Name RequireSecuritySignature and the equivalent LanManWorkstation path; both should return 1. Get-SmbServerConfiguration | Select-Object RequireSecuritySignature and Get-SmbClientConfiguration | Select-Object RequireSecuritySignature give the same answer through the SMB cmdlet surface. A subsequent Automox evaluation run reports the endpoint as compliant and applies no further remediation.

If users report file share access errors after enforcement, isolate the failing peer with Get-SmbConnection on the client and review the System event log for events 30803, 30804, or 31010 from source Microsoft-Windows-SMBClient. Those events identify the server that could not sign. Patch or replace the offending peer, then re-run the Worklet; the next evaluation confirms the endpoint stays compliant. The setting persists across reboots and Windows feature updates, and the Worklet restores it automatically if a Group Policy refresh, a third-party hardening tool, or a manual registry edit removes the value.