What is EternalBlue

In March 2017, Microsoft quietly patched a set of flaws in its SMBv1 file-sharing protocol. A month later, the exploit for the most dangerous of those flaws — a memory corruption bug in the SMB server driver known as EternalBlue and tracked as CVE-2017-0144 — was published to the internet by a group calling itself the Shadow Brokers. Within weeks it powered WannaCry, a ransomware worm that crippled the UK's National Health Service, Spain's Telefónica, and FedEx's European operations, and shortly after that it was repurposed inside NotPetya, which caused an estimated $10 billion in damages worldwide. EternalBlue remains one of the clearest case studies in why unpatched, internet-facing legacy protocols are an existential risk: a single remote-code-execution bug, unauthenticated and wormable, turned into the most damaging cyberattacks in history within two months of public disclosure.

What EternalBlue actually is

EternalBlue exploits a buffer overflow in how Windows' SMBv1 server driver (srv.sys / srv2.sys) handles specially crafted packets during the negotiation of SMB transactions. By manipulating the FEA (File Extended Attributes) conversion logic, an attacker can corrupt kernel memory in a way that allows arbitrary code to run with SYSTEM privileges — no authentication, no user interaction, just a single crafted packet sent to TCP port 445. That combination is what makes it "wormable": once one machine on a network is compromised, the exploit can be fired at every other reachable host running vulnerable SMBv1, without any user clicking anything.

EternalBlue is the best-known member of a small family of exploits believed to have been developed by the NSA's Equation Group and leaked by the Shadow Brokers, alongside related tools like EternalRomance, EternalChampion, and EternalSynergy. Microsoft's March 2017 update, bulletin MS17-010, addressed the full cluster of underlying CVEs:

• CVE-2017-0143 – SMB remote code execution
• CVE-2017-0144 – SMB remote code execution (EternalBlue proper)
• CVE-2017-0145 – SMB remote code execution
• CVE-2017-0146 – SMB remote code execution
• CVE-2017-0147 – SMB information disclosure (EternalRomance-adjacent)
• CVE-2017-0148 – SMB remote code execution

Affected versions and components

MS17-010 covers essentially every Windows version that still shipped SMBv1 support at the time, including:

• Windows Vista, 7, 8.1, and 10 (pre-1703)
• Windows Server 2008, 2008 R2, 2012, 2012 R2, and 2016
• Windows XP and Server 2003 (out of support at the time, but Microsoft issued an emergency out-of-band patch given the severity)

The vulnerable component is the SMBv1 server implementation itself, so exposure is not limited to file servers — any Windows host with File and Printer Sharing enabled, or with SMBv1 unintentionally left on by default (as it was on most pre-2017 Windows builds), is in scope. This is a big part of why the blast radius was so large: SMBv1 was on by default, rarely audited, and frequently exposed on flat internal networks where lateral movement went unchecked.

CVSS, EPSS, and KEV context

• CVSS v3.1 base score: 8.1 (High) for CVE-2017-0144, reflecting network attack vector, high attack complexity (the original scoring predates full understanding of how reliable the exploit chain would prove in practice), no privileges required, no user interaction, and complete impact to confidentiality, integrity, and availability.
• EPSS: EternalBlue-related CVEs sit at or near the top of the EPSS distribution — in the highest exploitation-probability percentile of all scored CVEs — because of the volume and diversity of automated scanning and exploitation activity that has targeted port 445 continuously since 2017. Any internet-facing or flat-network host still exposing SMBv1 should be treated as a near-certain target for opportunistic exploitation.
• CISA KEV: The underlying MS17-010 vulnerabilities are canonical entries in the "known exploited" category that the CISA Known Exploited Vulnerabilities catalog was created to capture — confirmed active exploitation via WannaCry, NotPetya, Retefe, and continued cryptomining and botnet campaigns years after disclosure. Federal agencies and any organization following CISA BOD 22-01-style guidance should treat unpatched SMBv1 exposure as a mandatory, time-boxed remediation item, not a backlog ticket.

Timeline

• 2001–2017: EternalBlue is developed and used as part of the NSA's offensive toolkit, reportedly for over five years, without public disclosure.
• Early 2017: Microsoft is notified — reportedly after signs the exploit toolkit had been stolen — and begins preparing a fix.
• March 14, 2017: Microsoft ships MS17-010, patching CVE-2017-0143 through CVE-2017-0148 across all supported Windows versions.
• April 14, 2017: The Shadow Brokers publicly release the "Lost in Translation" dump, including the EternalBlue exploit and the DoublePulsar backdoor implant, roughly one month after the patch shipped.
• May 12, 2017: WannaCry erupts, using EternalBlue for initial compromise and worm-like propagation, infecting an estimated 200,000+ systems across 150 countries in days, notably paralyzing NHS trusts.
• May 14, 2017: Microsoft takes the unusual step of issuing patches for out-of-support Windows XP and Server 2003 given the scale of the crisis.
• June 27, 2017: NotPetya, disguised as ransomware but functioning as a destructive wiper, combines EternalBlue with credential-harvesting (Mimikatz-style) techniques to spread inside Maersk, Merck, FedEx/TNT Express, and other multinationals, causing billions in losses.
• 2017–present: EternalBlue continues to be found and exploited in cryptomining botnets, and in periodic vulnerability scans, security researchers and Safeguard's own telemetry still routinely encounter internet-facing and internal hosts with SMBv1 enabled nearly a decade later.

Remediation

The fix for EternalBlue has been available since March 2017, and defense-in-depth options exist even where patching is delayed:

1. Patch immediately. Apply MS17-010 (or the relevant cumulative update for your Windows version) on every host that has not already received it. For legacy/out-of-support systems, apply Microsoft's emergency patches for Windows XP/Server 2003, or isolate them entirely if patches cannot be applied.
2. Disable SMBv1 outright. Most organizations do not need SMBv1 for legitimate business purposes. Use Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol (or Group Policy) to remove it fleet-wide, and validate no legacy printers, NAS devices, or applications silently depend on it before rollout.
3. Block SMB at the network boundary. Filter inbound and outbound TCP 445 (and 137–139) at perimeter firewalls; SMB should never be reachable from the public internet.
4. Segment internal networks. Restrict SMB traffic between internal subnets/VLANs to only the hosts and services that require it, so a single compromised endpoint cannot fan out laterally the way WannaCry and NotPetya did.
5. Monitor for exploitation indicators. Watch for DoublePulsar implant signatures, anomalous SMB negotiation patterns, and unexpected SYSTEM-level process creation on SMB-facing hosts via EDR.
6. Inventory before you assume you're clean. Nearly a decade on, SMBv1 still turns up on forgotten print servers, OT/ICS gateways, and shadow IT — an accurate asset and software inventory is the only reliable way to confirm exposure is actually zero.

How Safeguard Helps

EternalBlue is a textbook example of why context matters as much as detection: the CVE was public and patchable for years, yet exposure persisted because teams couldn't easily see which hosts were actually reachable, unpatched, and running SMBv1 in practice. Safeguard's reachability analysis identifies whether vulnerable SMB services and legacy components are actually exposed and exploitable within your specific network and application paths, so teams can prioritize the handful of genuinely at-risk assets instead of chasing every legacy Windows box in inventory. Griffin AI correlates that reachability signal with exploitation data — including KEV and EPSS trends like the ones described above — to separate "patch this decade-old finding today" from "track and revisit." Continuous SBOM generation and ingest give security and IT teams a living inventory of OS components and legacy protocols across the fleet, closing the exact visibility gap that let SMBv1 linger silently for years. And where remediation is code- or configuration-driven, Safeguard's auto-fix PRs turn that prioritized finding directly into a reviewable change, shortening the path from "known exploited vulnerability" to "verified fixed."