SMBv1 WannaCry Alert: Disable Old Protocol on Windows

You're staring at a ransom note that appeared after a file share connection or simply after leaving a Windows 7 or older Server online. The screen says your files are encrypted, pay $300 in Bitcoin. The trigger is almost always an unpatched Windows machine exposed to the internet or a LAN with one infected PC. The malware doesn't need you to click anything—it spreads by itself using an exploit called EternalBlue, targeting port 445 where SMBv1 listens.

What's actually happening here is that WannaCry carries a worm component. It scans random IPs and local subnets for machines with SMBv1 enabled and missing the MS17-010 patch. Once it finds one, it sends a malformed SMBv1 packet that overflows the buffer, giving it remote code execution. From there it installs a doublepulsar backdoor and starts encrypting. The reason disabling SMBv1 works is that even if the machine is unpatched, the vulnerable code path never runs—the protocol handler simply isn't there to answer the malicious request.

Root Cause: SMBv1 Is Ancient and Insecure

SMBv1 dates back to 1983 for LAN Manager. Microsoft added SMBv2 in Vista and SMBv3 in Windows 8/Server 2012, but kept SMBv1 as a fallback for compatibility with old NAS devices and legacy printers. That compatibility layer is a liability. SMBv1 lacks modern encryption and authentication, and it's the only version vulnerable to EternalBlue. Windows 10 and Server 2016 still ship with SMBv1 enabled by default (unless you've removed it), so disabling it is a necessary hardening step—not just for WannaCry, but for later ransomware like NotPetya and Bad Rabbit.

Don't fall for the myth that you need SMBv1 for home networking. Windows 10 Pro and Home can talk to each other and to most consumer NAS devices using SMBv2 or SMBv3. Only ancient devices—think a 2005-era Buffalo LinkStation—might fail. In that case, replace the device or live with the risk.

The Fix: Disable SMBv1

There are three ways to disable SMBv1, and the right one depends on your Windows edition. Pick the one that matches.

Method 1: PowerShell (Windows 8.1, 10, 11, Server 2012+)

This is the cleanest method because it removes the feature entirely, including the driver.

1. Open PowerShell as Administrator. Right-click Start and choose “Windows PowerShell (Admin)”.
2. Run this command to disable SMBv1:

   Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart

3. Reboot when prompted.

Method 2: Windows Features Dialog (Home/Pro GUI)

If PowerShell feels foreign, use the GUI:

1. Open Control Panel → Programs → Turn Windows features on or off.
2. Scroll down and uncheck “SMB 1.0/CIFS File Sharing Support”.
3. Click OK and reboot.

Method 3: DISM (For Server Core or Offline Images)

If you're managing a Server Core or need to apply this to an offline WIM, DISM works:

dism /online /disable-feature /featurename:SMB1Protocol /NoRestart

For offline images, point to the WIM mount path after /image:.

Verify It's Actually Off

Reboot, then run this in an admin PowerShell or cmd to confirm:

Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

You want the State to read Disabled. Note that on Windows 10 there's also a client and server sub-feature: SMB1Protocol-Client and SMB1Protocol-Server. Disabling the parent SMB1Protocol disables both.

What About Group Policy?

For domain-joined machines, you can enforce this via Group Policy, but it's not a feature toggle. The policy only controls the SMBv1 server, not the client or driver. The proper way is to deploy the PowerShell command as a startup script or use the Windows Features removal via GPO software installation. Honestly, the registry hack that some sites post (setting SMB1 to 0 in HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters) does the same as the feature toggle, but it doesn't remove the driver—so a separate SMBv1 client component might still be active. Use the feature removal.

Still Failing After Disabling?

If you've disabled SMBv1 and still see SMB-related errors or suspect infection, check these:

• Patch MS17-010. Disabling SMBv1 doesn't patch other SMB versions. Install all pending updates, especially the April 2017 security rollup or later. Run Windows Update manually.
• Check for leftover SMBv1 components. Some Windows installations keep the client after the server is removed. Run Get-SmbServerConfiguration and look at EnableSMB1Protocol—if it shows True, you've only disabled the feature partially. Re-run the disable command after a clean boot.
• Scan for DoublePulsar. The backdoor that WannaCry plants can survive a reboot. Use a trusted EDR tool like Microsoft Defender's offline scan or the Sysinternals Autoruns to check for suspicious services or drivers, especially in C:\Windows\System32\drivers with random names.
• Check port 445. If something still listens on port 445 after disabling SMBv1, it's not SMBv1—it's another service or malware. Run netstat -ano | find ":445" in an admin cmd. If the PID is still there, identify the process with tasklist /FI "PID eq <pid>".

One more thing: if you're on Windows 7, the feature removal command might throw an error because SMBv1 is more deeply integrated. For Windows 7, uninstall it via Control Panel → Programs → Turn Windows features on or off, unchecking “SMB 1.0/CIFS File Sharing Support”. Reboot. If the option is greyed out, check that the Windows 7 SP1 is installed first.

Disabling SMBv1 isn't just a WannaCry band-aid. It removes a decade-old attack surface that's been abused by multiple worm families. Do it on every Windows machine, including laptops that only connect to home shares. The compatibility cost is near zero for most users, and the security gain is massive.