Cause 1: Unpatched SMBv1 on Windows 7, Server 2008 R2, and 2012
The culprit here is almost always a Windows box that hasn't seen a security rollup since early 2017. MS17-010 dropped in March 2017, and WannaCry went wild two months later. If you've got Windows 7 SP1, Server 2008 R2, or even 2012 R2 sitting on a flat network with SMBv1 enabled and no MS17-010 patch, you're a sitting duck. The EternalBlue exploit fires a malformed SMBv1 packet at port 445, corrupts kernel memory, and drops the DoublePulsar backdoor. From there, WannaCry encrypts files and spreads laterally to every reachable host.
I've walked into environments where a single XP machine on a factory floor was the initial seed. One packet and 200 endpoints were encrypted by lunch. Don't assume your perimeter saves you — SMB is internal traffic and most shops don't segment it.
The fix that actually works
Patch first. That's non-negotiable. For legacy boxes still getting updates, install KB4012212 (Windows 7), KB4012215 (Server 2008 R2), or the equivalent rollup for your build. Microsoft even released an out-of-band patch for XP and Server 2003 (KB4012598) — grab it if you're stuck supporting those.
If you can't patch right now (and there's almost no good reason in 2024), disable SMBv1 immediately. On a modern Windows 10/11 or Server 2016+ box:
Disable-WindowsOptionalFeature -Online -FeatureName smb1protocol
On older systems, use the registry:
reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" /v SMB1 /t REG_DWORD /d 0 /f
Then reboot. Don't skip the reboot — the driver stays mapped until you do. Verify with:
Get-SmbServerConfiguration | Select EnableSMB1Protocol
It should return False. If it doesn't, you missed a step.
Cause 2: Port 445 Exposed to the Internet or a Flat Internal Network
The second most common reason WannaCry still shows up in incident reports is that someone punched 445 through the firewall. Yeah, it happens. A contractor needs file sharing, a dev spins up an EC2 instance with a wide-open security group, or a branch office firewall rule from 2010 never got cleaned up. Shodan has thousands of 445-exposed hosts at any given moment.
Even internally, if you're running a flat /16 with no VLANs, one infected laptop turns into a worm highway. EternalBlue doesn't need credentials — it just needs reachability.
Shut the door
Block inbound 445 at your perimeter. There is no legitimate reason for SMB to be reachable from the public internet. Full stop.
Internally, segment. Put file servers on their own VLAN, workstations on another, and only allow 445 between them where it's genuinely needed. Your firewall or ACLs should look like this in spirit:
# Example iptables rule to block SMB from untrusted zones
iptables -A INPUT -p tcp --dport 445 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 445 -j DROP
On Windows, you can also lock down the firewall with a GPO. Allow 445 only from your file server subnet, deny everywhere else. It's a 10-minute change that kills lateral movement cold.
Cause 3: SMBv1 Still Enabled for "Compatibility"
This one makes me grind my teeth. Every environment I've audited has that one guy who swears an old NAS or a 2008-era print server needs SMBv1. Sometimes it's true — most of the time it isn't. SMBv1 is 40 years old, has zero encryption, and is the single biggest ransomware magnet on your network.
Windows 10 1709 and Server 2019 have SMBv1 off by default, but upgrades from older builds often carry it forward. If you upgraded in place from Windows 7, check. It's probably still on.
Rip it out and find out what breaks
Turn it off, then wait. You'll know within a day what actually needed it. Most of the time, nothing does. For the rare holdout, isolate that device on its own VLAN with strict 445 rules and start a migration clock.
Also run this to see if SMBv1 clients are enabled:
Get-SmbClientConfiguration | Select EnableSMB1Protocol
Disable it there too. Both server and client sides need to be clean.
If you're on a domain, push the disable via Group Policy: Computer Configuration → Policies → Administrative Templates → MS Security Guide → Configure SMBv1 client driver. Set it to Disabled. Reboot the fleet over a maintenance window.
Quick reference: causes and fixes
| Cause | Fix | Verify |
|---|---|---|
| Unpatched MS17-010 | Install KB4012212/KB4012215 or equivalent; XP gets KB4012598 | Check wmic qfe | findstr 4012212 |
| Port 445 exposed | Block inbound at firewall; segment SMB traffic internally | Scan from outside with nmap -p 445 |
| SMBv1 still enabled | Disable via PowerShell, registry, or GPO; reboot | Get-SmbServerConfiguration shows False |
One more thing: WannaCry isn't the only EternalBlue-based threat. Even after patching, assume someone's already inside. Hunt for DoublePulsar artifacts — the backdoor listens on port 445 with a specific SMB response pattern. Microsoft's MS17-010 mitigation guidance and the free EternalBlue scanner from the community can help you sweep your subnet.
If you've done all three fixes and you're still seeing infections, you've got a reinfection vector you haven't found yet. Check for open RDP with weak creds, phishing, or a rogue device on the network. Patch, block, disable — in that order.