In my review of WannaCry's propagation path, the network boundary matters as much as the payload. The May 2017 outbreak combined ransomware with self-propagation across vulnerable Windows SMB services.
There was a patch before the outbreak
Microsoft released MS17-010 in March 2017, the EternalBlue exploit became public in April, and WannaCry spread widely beginning May 12. That timeline comes from Microsoft's response team. It makes this more than a story about one payload: organizations had a finite opportunity to identify exposed systems and close a known remote-code-execution path.
How a workstation problem became a network problem
The relevant chain was vulnerable SMB exposure, exploitation, propagation to reachable hosts and then ransomware impact. An endpoint restored from backup could still be reinfected if the same reachable vulnerable service remained.
The operational questions are straightforward but uncomfortable:
- Which systems accept inbound SMB, and from which segments?
- Which endpoints missed MS17-010 and why?
- Are administrative shares and lateral traffic visible to defenders?
- Could critical operations continue if an entire Windows subnet disappeared at once?
I separate segmentation, patch evidence and recovery into different controls. A patch closes a vulnerability; segmentation reduces reachable targets; backups help recover files but do not stop exploitation.
The virus/worm distinction
Calling everything a virus is inaccurate. NIST distinguishes a virus that attaches to a host program from a worm that can propagate independently between systems. WannaCry's outbreak mechanism is worm-like even though the payload is ransomware. One label describes spread, the other describes the impact.
Sources
- Microsoft Security Response Center: the EternalBlue patch timeline
- CERT-EU advisory 2017-012
- NIST glossary: worm
Scope: Historical incident analysis. No exploit or ransomware sample was run.