On May 12, 2017, a piece of malware did something no attacker had pulled off at that scale before: it spread across the public internet on its own, encrypted files on the way, and brought hospitals, factories, and rail networks to a standstill inside a single working day.
WannaCry infected an estimated 200,000 systems across at least 150 countries in under 24 hours. It cost an estimated $4 billion in global damages. It forced the UK’s National Health Service to divert ambulances and cancel roughly 19,000 patient appointments.
And it did all of it without a single phishing email. No user had to click anything. No macro had to run.
For anyone moving from IT into cybersecurity, WannaCry is one of the most important case studies you will ever look at — because it wasn’t a story about a clever attacker outsmarting users. It was a story about legacy protocols, unpatched infrastructure, and flat networks being weaponized against the organizations running them. Every one of those is an IT problem before it is a security problem.
Here is what happened, who was behind it, how EternalBlue actually worked, and — using the Threat & Control Method — what a defensible environment would have looked like on the morning of May 12, 2017.
The Timeline of an Epidemic
The WannaCry timeline is a near-perfect illustration of the gap between “patch available” and “patch deployed” — the window where most real-world breaches happen.
- March 14, 2017. Microsoft releases MS17-010, a critical patch for a remote code execution flaw in Server Message Block version 1 (SMBv1).
- April 14, 2017. A group calling itself The Shadow Brokers publishes a cache of stolen NSA tooling in a dump titled Lost in Translation. Inside it: a military-grade exploit called EternalBlue, targeting the exact vulnerability Microsoft had just patched.
- May 12, 2017 (early morning UTC). WannaCry is released into the wild. It pairs EternalBlue with a ransomware payload and a worm engine, and starts scanning the internet for port 445.
- May 12, 2017 (afternoon UK time). The NHS declares a major incident. Clinicians are locked out of patient records. MRI and CT machines refuse to boot. Ambulances start getting diverted.
- May 12, 2017 (evening UK time). A researcher operating as MalwareTech notices a hardcoded, unregistered domain inside the malware. He registers it for roughly $10. It turns out to be a kill switch, and global propagation slows dramatically within hours.
- May 13, 2017. Microsoft takes the extraordinary step of releasing emergency patches for out-of-support operating systems, including Windows XP and Server 2003.
Fifty-nine days from patch to detonation. Anything unpatched inside that window — and anything running an OS Microsoft no longer supported — was a target.
The Threat Actor: Lazarus Group
In the immediate chaos, WannaCry looked like an opportunistic outbreak. It wasn’t.
Public attribution came from the U.S. and U.K. governments in December 2017, and the U.S. Department of Justice’s 2018 indictment of Park Jin Hyok laid out the technical case in detail: WannaCry was the work of Lazarus Group, an advanced persistent threat operating on behalf of North Korea.
Lazarus is worth understanding as an archetype, because it breaks the mental model most IT professionals bring into security. Russian and Chinese state actors are typically framed around espionage and IP theft. North Korean APTs have a different mandate — they exist, in part, to generate revenue to work around sanctions. That changes the target set. It changes the timelines. And it means the same operators show up hitting banks, cryptocurrency exchanges, and hospitals in the same year.
Lazarus didn’t discover the SMBv1 vulnerability. The NSA did. What Lazarus demonstrated was operational speed: within weeks of Lost in Translation, they had integrated a nation-state exploit into a self-propagating ransomware worm and shipped it globally.
Post-exploitation, they went further. Under intense scrutiny from investigators tracing the ransom Bitcoin wallets, they moved the funds through ShapeShift into Monero — a privacy-preserving cryptocurrency that uses ring signatures to obscure sender, receiver, and amount. The trail effectively ended there.
The point isn’t that every IT team needs to prepare for Lazarus specifically. It’s that the tools nation-states used to build in 2010 leak into the hands of everyone else by 2017. Modern ransomware crews inherited both the exploit and the worm design pattern. WannaCry is the template.
Anatomy of the Attack: How EternalBlue Actually Worked
If you have spent any time as a sysadmin or a network engineer, you already know Server Message Block. SMB is the protocol Windows uses for file and printer sharing over TCP 445 (and, historically, TCP 139 with NetBIOS). Most modern networks run SMBv2 or SMBv3.
SMBv1 is a different animal. It was retained in Windows for backward compatibility with legacy NAS appliances, older printers, and operational technology that had never been recertified. On May 12, 2017, it was still enabled by default on a huge number of production systems.
WannaCry didn’t just encrypt files — it was a cryptoworm. It paired a ransomware payload with the EternalBlue exploit (CVE-2017-0144) and a scanner that hunted for the next victim on its own.
The vector: kernel memory corruption
EternalBlue exploits a flaw in the way the Windows kernel SMB driver (srv.sys) parses File Extended Attributes. A size-calculation error — a value expected to be one width being handled as another — allows an attacker to convince the kernel to allocate a small buffer and then write far more data into it than the buffer can hold. That is a heap overflow in the kernel’s non-paged pool.
By carefully sending fragmented SMB packets to shape the pool (“heap grooming”), the exploit ensures the overflow lands where it needs to land, overwriting adjacent kernel structures cleanly. The end state: arbitrary code executing in kernel mode as NT AUTHORITY\SYSTEM. No user interaction, no elevation step, no phishing.
The payload and persistence
Once EternalBlue landed, the attacker installed DoublePulsar, a stealthy kernel-mode backdoor. DoublePulsar didn’t write files to disk. It lived in memory and hooked into SMB transactions, letting the operator push additional payloads through the same channel.
Through DoublePulsar, WannaCry did three things in sequence:
- Scan. It spawned threads to enumerate the local subnet and generate random public IP addresses, hammering TCP 445 to find the next unpatched host.
- Encrypt. It encrypted local files with a combination of AES-128 and RSA-2048.
- Destroy recovery. Before ransoming, it ran native Windows commands to torch local backups:
cmd.exe /c vssadmin delete shadows /all /quiet & wmic shadowcopy delete & wbadmin delete catalog -qThat last step is the one people underestimate. Volume Shadow Copies are the thing most IT teams quietly rely on when something goes wrong. WannaCry made a point of taking them out first.
The $4 Billion Wake-Up Call
Global losses were estimated at up to $4 billion by Cyence — a figure that is a directional estimate, not an audited number, but the human cost is not disputed.
In the U.K., the NHS faced a genuine patient-safety event. The National Audit Office reported roughly 19,000 patient appointments were cancelled. Ambulances were diverted from affected A&E departments. Diagnostic equipment — MRI, CT — was locked out. Staff dropped to pen, paper, and fax.
Outside healthcare, WannaCry hit FedEx, Telefónica, Deutsche Bahn, Renault, and Nissan, among others. Renault and Nissan physically halted vehicle assembly lines because the manufacturing execution systems couldn’t run.
For IT professionals, this is the point where “keeping servers up” and “cybersecurity” stop being separable disciplines. Availability is a security property. The reason security exists as a function inside an organization is not to write policy documents — it’s to keep the systems the business depends on doing what the business needs them to do, in the face of people actively trying to stop that from happening.
The Defensive Playbook — Through the Threat & Control Method
The temptation with a WannaCry retrospective is to say “patch faster” and stop there. Patching is necessary, but the reason WannaCry hurt so badly is that the systems it hit had no defense in depth. Once inside a flat network, the worm didn’t need to break anything else — the network handed it every workstation it could reach on port 445.
At Blue Team Academy we work every real environment through four steps: Inventory → Threats → Controls → Scale. Here is what that looks like against a WannaCry-class threat.
1. Inventory — know what’s actually on your network
You cannot defend what you cannot see. Before disabling anything, an IT team needs a real answer to three questions:
- Which hosts still have SMBv1 enabled — servers, workstations, and appliances?
- Which hosts legitimately require SMB access to which other hosts?
- Which endpoints are running an OS that Microsoft no longer supports?
None of this is glamorous. All of it is the work. Get-SmbServerConfiguration, Get-WindowsFeature FS-SMB1, an authenticated Nmap sweep with smb-protocols, and a real look at your CMDB or asset register will tell you more about your risk in a day than any threat intel feed will.
2. Threats — model how a cryptoworm would actually move
Once you know what you have, model what an attacker can do with it. For SMB-borne worms, the model is not complicated:
- Entry point — an internet-exposed 445, an infected laptop rejoining the corporate LAN, a vendor’s engineer connecting from a compromised network.
- Lateral movement — workstation-to-workstation SMB, service accounts with unnecessary domain reach, shared local admin credentials.
- Impact — encryption of file shares, destruction of Volume Shadow Copies, loss of backup catalogs, and downstream availability failures on anything that depends on those files.
You do not need to name a specific threat actor to do this. You need to name the behavior — and once you have, the controls follow naturally.
3. Controls — pick the ones that actually reduce the modeled risk
Working from the threat model, not from a generic checklist:
Kill SMBv1. Patching MS17-010 is table stakes. Removing the protocol entirely is the real fix. On a single host: Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force and Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol. At scale: enforce it via Group Policy so it stays off when someone reinstalls an application that helpfully turns it back on.
Segment the network. Workstations almost never need to talk to other workstations over 445. Enforce that at the host firewall via GPO. Use VLANs and edge ACLs so that end-user subnets can reach designated file servers and nothing else. Block 137/138/139/445 outbound at the perimeter, in both directions. Flat networks are how one infection becomes a thousand.
Detect the pattern, not just the file. Deploy IDS coverage — Suricata or Snort — on internal choke points, tuned to detect the malformed SMB traffic EternalBlue relies on. Feed SMB session logs into your SIEM. A single host attempting 445 connections against dozens of others in a minute is not “noise.”
Make backups actually recover you. Volume Shadow Copies are not a backup strategy against modern ransomware, because modern ransomware deletes them first. Backups need to be off the same identity plane as the systems they protect — separate credentials, separate network path — and they need immutability (WORM storage, object-lock, or equivalent) so that a compromised admin account cannot destroy them.
4. Scale — apply the same reasoning everywhere else
The final step is the one that separates a WannaCry postmortem from a real defensive practice: apply the same thinking to every other protocol you inherited.
The pattern is: a legacy protocol, enabled by default for compatibility, running on a flat network, unmonitored, with no immutable recovery path. SMBv1 is one instance. Telnet is another. FTP is another. LM and NTLMv1 authentication are another. Unrestricted WinRM, un-scoped WMI, and unsigned SMBv2 all rhyme with it.
An IT professional who can walk into an environment and run this loop — inventory, model, control, apply the same loop to the next protocol — is thinking like a defender. That is the transition, and it is a shorter distance from a sysadmin’s daily work than most people realize.
Why This Belongs in Your Career, Not Just in a History Book
Every worm-based intrusion in the eight years since WannaCry has borrowed from its playbook. NotPetya used EternalBlue two months later, with far worse consequences and no kill switch. BadRabbit reused parts of the design. Modern ransomware crews routinely include SMB-based lateral movement modules, even when their initial access came from somewhere else entirely.
For an IT professional moving into defensive security, WannaCry is not a museum piece. It is the clearest existing worked example of how the environments you already run get turned into weapons — and of how ordinary IT hygiene, applied with a defender’s intent, would have stopped almost all of it.
Cybersecurity is not rocket science. It is the same infrastructure work you already do, aimed at a different question: what would an attacker do with this, and how would we know?
If you want to build that thinking into how you approach your own environment, our blue team training built for IT professionals at Blue Team Academy walks the Threat & Control Method through real incidents — WannaCry among them — so you finish able to run the loop yourself.
Keep IT Safe.
Want more Breach Files delivered to your inbox? Subscribe to the Keep IT Safe newsletter.
