WannaCry (May 2017): SMBv1, Unpatched Servers and What Cloud Teams Missed

Retrospective: this article looks back at events from May 2017, written in 2026 with the benefit of hindsight.

On May 12, 2017, WannaCry ransomware spread across the world in a matter of hours, encrypting files on hundreds of thousands of Windows computers in more than 150 countries. Hospitals in the UK's National Health Service turned away patients. Factories stopped production lines.

How it spread

WannaCry used EternalBlue, an exploit for a flaw in Microsoft's SMBv1 file-sharing protocol. Microsoft had released a patch (MS17-010) two months earlier, in March 2017. Systems that had not applied it — or that still ran unsupported versions of Windows — could be infected over the network with no user interaction. Once inside, the worm scanned for other vulnerable machines and kept going.

The outbreak slowed when security researcher Marcus Hutchins registered a domain name the malware checked before running, which acted as an accidental kill switch.

What cloud teams missed

Many organizations believed WannaCry was an "on-premises problem." But Windows virtual machines in Azure and AWS ran the same operating system and were patched by the same customers. Under the shared responsibility model, the cloud provider secures the host; patching the guest operating system is your job. Cloud VMs with SMB exposed to the internet or to flat internal networks were just as vulnerable.

Lessons in hindsight

• Patch latency is risk. Two months was long enough for an exploit to be weaponized at global scale.
• Disable legacy protocols. SMBv1 had been deprecated for years and was rarely needed.
• Never expose SMB (port 445) to the internet.
• Segment networks so one infected machine cannot reach everything.
• Know your unsupported systems. Microsoft took the unusual step of issuing patches for Windows XP and Server 2003.

WannaCry made patch management a board-level topic and showed how quickly a single unpatched vulnerability can become a global crisis.