HolyGhost logoHolyGhost
← cd ..

EternalBlue: The Leaked Exploit That Powered WannaCry

How a flaw in an ageing file sharing protocol, weaponised by a leaked intelligence exploit, spread ransomware across the world in hours. A breakdown of EternalBlue and MS17-010.

HolyGhost··8 min read

On a Friday in May 2017, staff at hospitals across the United Kingdom sat down at their computers and found their files locked, replaced by a red screen demanding payment in Bitcoin. Ambulances were diverted. Operations were cancelled. And the same red screen was appearing at telecoms companies in Spain, factories in France, and rail systems in Germany, all within the space of a few hours. Nobody had clicked a dodgy link. Nobody had opened a malicious attachment. The infection was simply arriving over the network, machine to machine, faster than anyone could unplug things.

That was WannaCry, and the engine underneath it was an exploit called EternalBlue. This is the story of how an old protocol, a leaked government toolkit, and a fleet of unpatched machines combined into one of the most damaging outbreaks in computing history. It is also, once you strip away the drama, a story with a very ordinary and very fixable moral.

Credit and scope

EternalBlue was reportedly developed by the NSA (the Equation Group) and leaked publicly by a group calling itself The Shadow Brokers in 2017. Microsoft had already patched the underlying flaw in MS17-010. This is a defensive explainer of how it worked, not original research.

The weak spot: an ageing protocol

Server Message Block, usually shortened to SMB, is the protocol Windows uses to share files and printers across a network. When you open a folder on a colleague's machine or print to the office printer down the hall, SMB is doing the quiet work behind the scenes. Version 1 of SMB is genuinely old. It comes from an era with very different security assumptions, back when networks were small, trusted, and rarely connected to anything hostile. It should have been retired years before 2017. Many networks still had it switched on out of habit and backwards compatibility.

To understand the flaw, it helps to know what a remote code execution bug actually is, because that phrase gets thrown around a lot. Remote code execution, or RCE, means an attacker can make a machine run instructions of their choosing over the network, without needing an account on it and without anyone sitting at the keyboard. It is about as bad as a single vulnerability gets, because running your own code on a target is effectively controlling it.

EternalBlue exploited a flaw in how SMBv1 handled certain specially crafted packets. A network packet is just a chunk of data sent across the wire. By sending deliberately malformed requests, an attacker could corrupt the memory of the part of Windows that services SMB, and steer that corruption into running their own code at the highest privilege level on the target. This is the remote code execution flaw tracked as MS17-010 and, among other identifiers, CVE-2017-0144.

The crucial detail, the one that separates this from an ordinary bug, is what it did not require: no credentials and no user interaction. The attacker needed nothing but network access to an exposed SMB port (port 445) on an unpatched Windows machine. No password to guess. No user to trick into clicking. Just reach the port, send the packets, own the machine.

Attacker  --->  malformed SMBv1 packets  --->  port 445 on target
                                               |
                                               v
                              memory corruption -> attacker's code runs
                              at SYSTEM (highest privilege), no login needed

Why no user interaction is the terrifying part

Most attacks need a human to slip up, click a link, open a file, or type a password into the wrong page. A bug that needs none of that removes the one defence you cannot patch, human caution. An exposed, unpatched SMBv1 machine could be taken over while nobody was even sitting in front of it. That is what let this spread at the speed of the network rather than the speed of people making mistakes.

Why it spread like wildfire

A single remote code execution bug is serious enough on its own. What made EternalBlue historic was how WannaCry combined it with self spreading behaviour to become a worm. A worm is malware that copies itself from machine to machine on its own, with no human driving it. Give a powerful RCE exploit to a worm and you get an automatic, tireless spreading machine.

1. Infected machine scans the network for other hosts with SMB open.
2. For each one, it fires EternalBlue to run its code remotely.
3. The new victim encrypts its files, then starts scanning too.
4. Repeat, exponentially, with no human involved.

Look at the shape of that loop. Every machine it infects becomes a new attacker, scanning and infecting further machines, each of which becomes another attacker. This is exponential growth, the same maths that makes a rumour or an epidemic explode. Two become four, four become eight, and in a large network the count runs away in minutes rather than days.

The reason it ran so freely comes down to network design. Many organisations ran flat networks, meaning every machine could talk to every other machine without restriction, including on port 445. In a flat network there are no internal walls. So one infected laptop plugged into a hospital network could reach thousands of other machines directly, and the worm simply walked through all of them. There was nothing internally to slow it down.

The patch existed before the outbreak

Microsoft released the MS17-010 fix in March 2017, roughly two months before WannaCry. The machines that fell were, overwhelmingly, ones that had not applied an available patch. NotPetya used the same exploit again weeks later. This is the recurring, uncomfortable lesson of EternalBlue.

What actually happened on an infected machine

It is worth being concrete about the victim's experience, because it explains why the damage was so total and so fast. Once EternalBlue delivered WannaCry's code onto a machine, the ransomware began encrypting files, scrambling documents, spreadsheets, and databases so they could not be opened, and it displayed a demand for payment in exchange for the key to unscramble them. At the same time, that freshly infected machine started scanning its neighbours to spread further. Encryption and propagation happened together, so a network could be simultaneously locking up and spreading the infection wider, all without a single click from any user.

For a hospital, that meant patient records and imaging systems going dark in the middle of a working day, which is precisely why the outbreak became a public safety story and not just an IT one.

Shutting it down

The defences read almost like a checklist for basic network hygiene, which is part of why the outbreak was so frustrating to security professionals. None of this was exotic.

  1. Patch. MS17-010 closes the vulnerability outright. Timely patching would have stopped both WannaCry and NotPetya cold. The fix was sitting there, free and available, for two months before the attack.
  2. Disable SMBv1 entirely. It is obsolete. Modern Windows does not need it for normal operation, and turning it off removes the attack surface completely. If the vulnerable code is not running, it cannot be exploited.
  3. Block SMB at the perimeter. Port 445 should never be reachable from the internet. Filter it at the firewall so the outside world cannot even knock on that door.
  4. Segment your network. If machines cannot freely reach each other on SMB, then a single infection cannot become a worm, because the worm hits an internal wall and stops. Segmentation is the difference between one sick machine and a sick building.

Segmentation is what turns a catastrophe into an incident

Patching stops the specific bug. Segmentation stops the pattern. Even against a brand new exploit that no patch exists for yet, a network divided into isolated zones limits how far any single compromise can travel. It is the control that keeps paying off long after EternalBlue itself has faded into history, which is exactly why it deserves a line in every network design.

Old protocols are liabilities, not conveniences

SMBv1 survived on many networks purely because switching it off felt like effort and nobody wanted to risk breaking an old printer. That inertia is precisely what attackers count on. Treat any decades old protocol still running in your estate as a question that needs answering: do we truly need this, and if not, why is it still on?

The takeaway

EternalBlue is a lesson in three parts. Old protocols like SMBv1 are liabilities and should be switched off. Patches only ever protect the machines that actually apply them, so an available fix that nobody installs protects nobody. And flat networks let one compromise become total, while segmentation contains it. The exploit itself was extraordinary, the product of a state intelligence programme leaked to the world, but the reason it hurt so many organisations was entirely ordinary: unpatched systems, obsolete protocols, and open, undivided networks. The extraordinary part you could not control. The ordinary part you always could.