EternalBlue Step by Step: Exploiting MS17–010 SMBv1 in a Lab and Hardening Windows Against It for…

A flaw in an old file sharing protocol powered two of the worst outbreaks in history. Here is the lab walkthrough, the detection story and the hardening that ends it.

Cover image: AI generated illustration made in Canva.

In March 2017 Microsoft patched a critical flaw in SMBv1, the first version of the Server Message Block protocol that Windows uses for file and printer sharing. A month later the exploit known as EternalBlue became public. Within weeks it powered the WannaCry and NotPetya outbreaks, which damaged hospitals, shipping firms and factories across the world. The patch already existed. The machines that fell had simply never received it.

Disclosure: This article was researched and written with AI assistance, and it was checked for accuracy and originality before publishing.

This article explains the vulnerability in plain words, walks through exploitation step by step in an isolated lab, and finishes with detection, hardening and verification. Everything concerns a publicly disclosed vulnerability from 2017 and a lab you own. Never run any of this against a network you do not own.

The vulnerability, explained simply

SMBv1 is an old protocol with no encryption and a long history of trust inside local networks. The flaw, covered by the Microsoft security update MS17–010, sits in how the Windows SMBv1 server handles specially crafted requests. By sending a sequence of malformed SMB messages, an unauthenticated attacker could corrupt memory in the kernel level SMB driver and turn that corruption into remote code execution running as SYSTEM, the most powerful local account on Windows.

Two facts made it historic. It needed no username, no password and no user click. And it was wormable, meaning one infected machine could attack the next machine by itself, which is exactly how WannaCry spread through networks at machine speed.

A public lab walkthrough of this exploit is at https://www.davidoduse.com/2026/06/exploiting-ms17-010-eternalblue-smb.html and a detailed public hardening analysis is at https://www.penligent.ai/hackinglabs/eternalblue-cve-finally-explained-ms17-010-the-cve-family-and-how-to-prove-youre-not-exposed/

Lab setup

Build this only on a host only virtual network with no route to your real network or the internet, and snapshot both machines before you start.

Victim machine: an unpatched Windows 7 or Windows Server 2008 R2 virtual machine with SMBv1 enabled, at a lab address such as 192.168.56.30. This machine exists only to be attacked and restored.
Attacker machine: a Linux virtual machine with the Metasploit Framework installed, at a lab address such as 192.168.56.10, on the same host only network.
Safety rules: no bridged networking, no shared folders with the host, no real accounts or data on the victim, and snapshots restored after every run.

Lab Attack Path: port 445 open, vulnerability check passed, exploit runs, and SYSTEM access follows. This image is an AI generated illustration made in Canva.

Exploitation, step by step

Step 1. Discover the service. From the attacker machine, scan the victim for the SMB ports, TCP 445 and TCP 139, and identify the SMB dialects the server offers. Port 445 open with SMBv1 offered is the first signal.

Command shape used in public labs: nmap -p445 — script smb-protocols 192.168.56.30

Step 2. Confirm the vulnerability before you exploit it. Run the dedicated vulnerability check script for this issue against the victim. A vulnerable result tells you the MS17–010 patch is missing.

Command shape used in public labs: nmap -p445 — script smb-vuln-ms17–010 192.168.56.30

Step 3. Load the exploit module. Open the Metasploit console and select the EternalBlue module, which public labs reference by the name exploit/windows/smb/ms17_010_eternalblue.

Step 4. Configure the target and the payload. Set the remote host option to the victim lab address. Set the payload to a Meterpreter reverse connection for Windows 64 bit, which will connect back to your attacker machine when the exploit lands. Confirm the listener address and port match your attacker machine.

Step 5. Run the exploit. The module sends the crafted SMBv1 transaction sequence. The victim SMB driver processes the malformed messages, memory corruption occurs in the kernel, and execution is redirected into the attacker payload. Public lab writeups describe the familiar result line by line: the target is first checked as vulnerable, the exploit stages are sent, and a Meterpreter session opens.

Step 6. Verify the privilege level. Inside the session, ask who you are. The expected answer in a successful lab run is NT AUTHORITY SYSTEM. Run a system information check to record the victim build and confirm it matches your unpatched lab target. That single result is the whole lesson. No credentials were used at any point, and the session holds the highest privilege the machine offers.

Step 7. Demonstrate impact with restraint and stop. In the lab, listing a directory you created earlier on the victim desktop is enough to prove control. In a real engagement this same session would allow credential theft, ransomware deployment or worm style spreading to every unpatched neighbour, which is why WannaCry encrypted whole networks within hours. Shut the lab down and restore the snapshots.

What the attacker gains

SYSTEM level code execution on one machine is bad. EternalBlue added network position to that prize. The attacker lands inside the trusted local network, where SMB traffic is usually allowed everywhere, and can repeat the same exploit against every unpatched host in reach. One forgotten machine becomes the doorway, and the protocol that shares files becomes the road. That combination, unauthenticated, wormable and kernel level, is why this nine year old flaw still appears in penetration test findings today, usually on legacy systems that teams were afraid to patch.

How defenders detect it

Vulnerability scanning. Any authenticated or network scan should flag missing MS17–010 patches and enabled SMBv1 immediately. Treat either finding as urgent, not routine.
Network monitoring. Watch for SMBv1 negotiation on the wire at all. A healthy modern network speaks SMBv2 and SMBv3, so SMBv1 traffic itself is a detection signal, and scanning patterns across many hosts on port 445 suggest worm behaviour.
Endpoint telemetry. Alert on the SMB service process spawning unexpected child processes and on sudden SYSTEM level process creation that follows inbound SMB connections.
Log review. Collect Windows event logs centrally so an outbreak pattern across hosts is visible in one place, instead of one silent machine at a time.

How to fix it and verify the fix

Hardening Checklist: apply MS17–010, disable SMBv1, block port 445, and prove it with a rescan. This image is an AI generated illustration made in Canva.

Patch. Apply the MS17–010 security update or run a supported Windows version with current updates. Patching removes the flaw itself.
Disable SMBv1 everywhere, client and server, through Group Policy or the documented registry and feature controls. Even patched systems gain nothing by keeping an obsolete and insecure protocol alive. Public hardening guidance from Microsoft and SANS, summarised at https://www.penligent.ai/hackinglabs/eternalblue-cve-finally-explained-ms17-010-the-cve-family-and-how-to-prove-youre-not-exposed/, recommends exactly this order: patch first, then remove the protocol.
Block the road. Never expose port 445 to the internet, and segment internal networks so workstations cannot freely open SMB connections to every other workstation.
Verify like an auditor. Produce three proofs: a scan showing no host missing the patch, a configuration report showing SMBv1 disabled, and a firewall export showing port 445 blocked at the perimeter and between internal segments. Rerun the lab vulnerability check against a restored clone and confirm it now reports not vulnerable.

Closing takeaways

EternalBlue is not a story about a clever exploit. It is a story about a patch that existed before the disaster and machines that never received it.

For testers, the lab teaches clean method: confirm with a check script, exploit once, prove privilege, and stop. For defenders, the lesson is permanent. Remove legacy protocols, patch on a cadence, and keep the evidence ready before an auditor or an attacker asks for it.

With more than thirteen years in offensive security, HackerOne Top 100 recognition in 2014 to 2016, Synack Red Team experience and the SVP Head Application Security and VAPT role at UBL today, I still meet SMBv1 in real networks. Every meeting ends the same way. Disable it, patch the host, and show the proof.

Sources credited in this article: the public lab walkthrough at https://www.davidoduse.com/2026/06/exploiting-ms17-010-eternalblue-smb.html, the public hardening analysis at https://www.penligent.ai/hackinglabs/eternalblue-cve-finally-explained-ms17-010-the-cve-family-and-how-to-prove-youre-not-exposed/ and the public lab report at https://medium.com/@ajaydevsv/exploiting-ms17-010-eternalblue-on-windows-7-using-metasploit-ethical-hacking-lab-8c5cec13b767. All research is based on publicly disclosed material only, and all exploitation steps describe an isolated lab only.

Tags: Cybersecurity, EternalBlue, MS17–010, Penetration Testing, Windows Security

Written by Muhammad Asim Shahzad, SVP Head Application Security and VAPT at UBL, with thirteen plus years in offensive security, HackerOne Top 100 history, Synack Red Team experience and CVE-2021–31521 to his name. More writing and services at protector47.com. Connect with Asim on LinkedIn at https://www.linkedin.com/in/protector47 and find his public researcher history through HackerOne under the name protector47.