WannaCry Is Your Reason to Patch MS17-010 and Turn Off SMBv1

Last Friday a ransomware outbreak called WannaCry, which Microsoft calls WannaCrypt, tore through organizations around the world. US-CERT’s alert says the first reports came in around 4:00 AM EDT on May 12, and it cites open source reports of tens of thousands of infections in more than 150 countries. The part that should get the attention of anyone running Windows machines, even a handful in a small office, is how it moved from machine to machine: through a file sharing bug Microsoft fixed two months ago. This isn’t a zero day story. It’s a patching story, and a story about an old protocol most networks can live without.

What the official sources say about the spread

US-CERT’s alert, TA17-132A, says initial reports point to the attackers getting into enterprise servers by exploiting a critical Windows SMB vulnerability, and that phishing may be one infection vector according to open sources. Microsoft’s guidance similarly mentions that some observed attacks used common phishing tactics, including malicious attachments.

What happens after the first machine is the scary part. US-CERT analyzed the files it received and describes the dropper scanning IP ranges on the local network and trying UDP ports 137 and 138 and TCP ports 139 and 445. When a connection to 445 works, it tries to spread by exploiting the SMBv1 vulnerability documented in MS17-010. So one infected laptop on a flat office network becomes a problem for every unpatched Windows machine it can reach.

MS17-010, the March patch

Microsoft Security Bulletin MS17-010 was published on March 14, 2017, and it’s rated Critical for all supported releases of Windows. It covers six CVEs, CVE-2017-0143 through CVE-2017-0148. Five are remote code execution bugs and one, CVE-2017-0147, is information disclosure. They all live in the SMBv1 server, and the bulletin says that in most situations an unauthenticated attacker could exploit them by sending a specially crafted packet to a targeted SMBv1 server. Microsoft listed no mitigating factors.

The affected list is basically every Windows release that was still supported in March: Vista SP2, Windows 7 SP1, Windows 8.1 and RT 8.1, Windows 10 (the original release, 1511 and 1607), and Server 2008, 2008 R2, 2012, 2012 R2 and 2016, Server Core installs included. On Windows 7 and 8.1 with the newer servicing model, the fix is in both the March security only update and the March monthly rollup, which on Windows 7 and Server 2008 R2 are 4012212 and 4012215. Windows 10 and Server 2016 got it in their March cumulative updates. If automatic updates have been running since March you are probably fine, but probably isn’t a patch level, so go check.

Microsoft patched XP, Windows 8 and Server 2003 too

Windows XP, Windows 8 and Server 2003 weren’t in the bulletin because they were out of support. In Customer Guidance for WannaCrypt attacks, the Microsoft Security Response Center said it was taking a “highly unusual step” and making the update for those platforms, which only get custom support, broadly available for download. US-CERT’s alert says those patches came out on May 13, and they’re listed under KB4012598 in the Microsoft Update Catalog.

The same post says customers running Windows 10 were not targeted by the attack, that supported systems with the update installed or automatic updates enabled are protected, and that Windows Defender detects the threat as Ransom:Win32/WannaCrypt. I’d treat the XP patch as a lifeline and not as a reason to keep those machines around.

What US-CERT recommends

The alert’s prevention advice starts where you’d expect, with applying the March 14 patch. Its network protection section then says that if you can’t patch, consider disabling SMBv1 and blocking all versions of SMB at the network boundary, meaning TCP port 445 plus the related UDP ports 137 and 138 and TCP port 139, on all boundary devices. None of this is new. US-CERT made the same two recommendations back in January in SMB Security Best Practices. Microsoft’s malware protection team said much the same in its WannaCrypt write-up, suggesting that until you can patch, you disable SMBv1 and consider a router or firewall rule blocking incoming SMB on port 445.

US-CERT adds a caveat worth taking seriously: disabling or blocking SMB can break access to shared files, data or devices, so weigh the benefit against the disruption. The rest of the alert is solid general hygiene. It covers spam filtering with SPF, DKIM and DMARC, least privilege for accounts and share permissions, disabling macros in Office files that arrive by email, training people to spot scams, and segregating networks so machines can’t talk to everything by default.

Turning off SMBv1 on each version of Windows

Microsoft documents the methods in KB 2696547, which covers Vista and later. Run everything from an elevated prompt.

Windows 8.1 and Server 2012 R2 and later can remove SMB1 as a feature. The MS17-010 bulletin describes the point and click route: clear SMB1.0/CIFS File Sharing Support in Turn Windows features on or off on a client, or in Remove Roles and Features in Server Manager, then restart. The Storage team’s Stop using SMB1 post gives the PowerShell versions, the first for clients and the second for servers:

Disable-WindowsOptionalFeature -Online -FeatureName smb1protocol
Remove-WindowsFeature FS-SMB1

On Windows 8 and Server 2012 you can check the server side and turn SMBv1 off with the SMB cmdlets, and the KB says no restart is needed:

Get-SmbServerConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol
Set-SmbServerConfiguration -EnableSMB1Protocol $false

On Windows 7, Vista, Server 2008 and 2008 R2, the server side is a registry value. The KB’s PowerShell command needs version 2.0 or later, and you need to restart afterward:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB1 -Type DWORD -Value 0 -Force

The client side on Vista through Windows 8 and Server 2012 takes two sc.exe commands, which remove the SMBv1 driver from the Workstation service’s dependencies and disable it, followed by a restart:

sc.exe config lanmanworkstation depend= bowser/mrxsmb20/nsi
sc.exe config mrxsmb10 start= disabled

While you’re in there, leave SMBv2 and SMBv3 alone. The KB warns against disabling them except as a temporary troubleshooting step. XP and Server 2003 are the hard case, because the KB notes SMBv2 arrived with Vista and Server 2008, so those older systems have nothing newer to fall back to. For them it’s KB4012598, isolation and a replacement plan.

Find what still needs SMBv1 first

US-CERT’s caveat is why I’d take inventory before flipping switches everywhere. Ned Pyle’s Stop using SMB1 post from last September argues that very few cases remain in a modern enterprise where SMB1 is the only option, and the examples he gives are XP or Server 2003 under a custom support agreement, crusty management software that wants to browse the network neighborhood list, and old multifunction printers that scan to a share. For Windows 10 and Server 2016 he points to auditing with Set-SmbServerConfiguration -AuditSmb1Access $true, and then you check the SMBServer\Audit event log to see who’s still connecting over SMB1. On older servers he suggests asking your network and security folks where they see SMB1 on the wire, or, in a smaller shop, running packet captures on a sample of servers and clients. He also recommends starting small and working your way up.

For a small network my advice is to make an actual list. Every Windows machine, its version and whether it has the March update, plus the printers, scanners and NAS boxes that save files to a share. Anything that truly can’t speak SMB2 goes on its own segment where office machines can’t reach it on 445, and you ask the vendor about firmware.

Backups ransomware can’t touch

Patching and port blocking lower the odds. Backups are what you fall back on when those measures fail. US-CERT’s alert recommends keeping copies of sensitive data in a separate and secure location that isn’t readily accessible from local networks, and testing that your backups actually work. It says that ideally your response to an infection is simply restoring from a known clean backup, and it points out that paying the ransom doesn’t guarantee you’ll get your files back. The UK’s National Cyber Security Centre boiled its advice down the same way in a statement on May 14: keep patches up to date, run proper antivirus, and back up the data that matters so it lives somewhere an attacker can’t hold hostage.

The detail that trips people up is that part about the local network. A backup drive that’s always plugged in, or a backup share mapped on every machine, is just one more thing for ransomware to encrypt. Keep at least one copy disconnected, and try a restore before you need one.

The takeaway

WannaCry worked because two old problems met: machines missing a two month old patch, and a protocol that should have been retired years ago still listening on networks where anything could reach it. Apply MS17-010 everywhere you can, use KB4012598 for the stragglers, block 445 at the edge, find what still depends on SMBv1 and then turn it off, and keep a backup that nothing on your network can reach.