SMB Signing, SMBv1, and the Guest Fallback: Hardening Windows File Sharing

SMB is the protocol behind Windows file sharing - and its default posture is a well-worn path for relay attacks, ransomware worming, and rogue file servers. Here's what to check and how WinSentinel audits it.

SMB (Server Message Block) is the protocol behind Windows file and printer sharing. It is quietly one of the most attacked surfaces on a Windows machine, because three of its default behaviors are exactly what an attacker wants: sessions that aren't required to be signed, a legacy protocol version that still ships enabled on plenty of machines, and a client that will silently fall back to unauthenticated guest access. None of these require an exotic exploit — they are just configuration.

Here is what actually matters, split the way WinSentinel's SMB / File Sharing audit splits it: the server side (this machine hosting shares) and the client side (this machine connecting to other shares).

1. SMB signing — the anti-relay control

When SMB signing is not required, an attacker positioned on the network path can relay an SMB session: they sit between you and a server, forward your authentication, and end up authenticated as you. This is the mechanism behind a huge share of Windows lateral-movement, and it is defeated entirely by requiring signing on both ends.

Server: RequireSecuritySignature makes the server refuse unsigned sessions.
Client: RequireSecuritySignature makes the client refuse to talk to a server that won't sign — so it can't be downgraded into an unsigned session with a rogue server.

# Require signing on both roles
Set-SmbServerConfiguration -RequireSecuritySignature $true -Force
Set-SmbClientConfiguration -RequireSecuritySignature $true -Force

"Enable" signing (offer it) is weaker than "require" it — offering signing only helps if the other side also insists on it. WinSentinel flags enable-but-not-require as a warning, not a pass.

2. SMBv1 — turn it off, on both roles

SMBv1 is the protocol version exploited by WannaCry and NotPetya via EternalBlue. It has unpatchable design weaknesses and no modern client needs it. Yet it lingers — a legacy NAS, an old printer, a "we'll fix it later" — and every machine that keeps the SMBv1 client installed can be downgraded into talking to a malicious SMBv1 server.

# Server protocol off
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force
# Client protocol / MRxSmb10 driver off
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol-Client -NoRestart

Modern Windows uninstalls the SMBv1 feature by default, but "default" is not "verified" — which is the whole point of an audit.

3. The insecure guest fallback — the quiet one

The most underappreciated of the three: AllowInsecureGuestAuth on the SMB client. When it's on, the client will silently connect to a file share as an unauthenticated guest if normal authentication fails. An attacker who can stand up a rogue file server on the network (or spoof one you already map a drive to) can serve malicious content or harvest connections with no credential prompt at all.

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters' `
  -Name AllowInsecureGuestAuth -Value 0

This is a single-machine setting with an outsized blast radius, and WinSentinel grades it Critical when enabled.

4. Encryption in transit

Signing protects integrity (nobody can tamper with or relay the session), but it does not encrypt the payload. For shares carrying sensitive data, SMB encryption (SMBv3) protects the contents from network sniffing:

Set-SmbServerConfiguration -EncryptData $true -Force

WinSentinel surfaces this as informational rather than a hard failure — it's a per-environment decision — but it belongs on the checklist.

How WinSentinel checks all of this

WinSentinel reads the local LanmanServer and LanmanWorkstation policy state and the SMBv1 client driver configuration, then grades each knob against CIS Windows L1: server/client require-signing and enable-signing, SMBv1 on either role, share encryption, and the insecure guest fallback. Every finding carries the exact PowerShell one-liner to fix it. It runs locally, on a single machine, and it's completely free:

dotnet tool install --global WinSentinel.Cli
winsentinel --audit

These are single-machine hardening checks — the free tier gives you the full-power audit on every box. If you run a fleet and want the same posture enforced and rolled up across dozens or hundreds of machines — "every node must pass CIS L1 by Friday," drift alerts when one regresses — that's what WinSentinel Pro adds on top. But the hardening itself starts here, free, with one command.