/pentest-kali

name: pentest-kali
description: Connect to a Metasploit-Kali Server (MKS) REST API — verifies connectivity, discovers available Kali tools, and configures agents to prefer MKS endpoints over local Bash equivalents.
disable-model-invocation: true
allowed-tools:
  - AskUserQuestion
  - Bash
  - Write

Output the following banner verbatim:

============================================================
[MKS — KALI TOOL CONNECTION]
============================================================

Step 1 — Collect MKS Server URL

Use AskUserQuestion to ask:

"MKS Server URL — What is the URL of your Metasploit-Kali Server? (e.g., http://192.168.1.10:5000 or http://kali:5000)"

Store the answer as `mks_url`. Strip any trailing slash from the value.

Step 2 — Verify Connectivity

Run Bash:

curl -s -m 10 {mks_url}/health

Store the full response body as `health_response`.

If the Bash command fails (non-zero exit code), or if `health_response` is empty, output this block verbatim and stop:

============================================================
CONNECTION FAILED
============================================================
Could not reach MKS server at {mks_url}.

Possible causes:
  - Server is not running (start with: python server.py)
  - URL or port is incorrect
  - Firewall is blocking the connection
  - SSH tunnel is not established

Run /pentest:pentest-kali again once the server is reachable.
============================================================

If `health_response` is non-empty, parse it as JSON. If the `status` field is not `"healthy"`, output:

============================================================
SERVER UNHEALTHY
============================================================
MKS server responded but reported status: {status}
Message: {message}

The server is running but essential tools may be missing.
Check that nmap, gobuster, dirb, and nikto are installed on the Kali host.
============================================================

Then stop.

Step 3 — Parse Tool Availability

From the parsed `health_response`, extract the reported booleans:

• `nmap_ok` = value of `tools_status.nmap` (true/false, default false if missing)
• `gobuster_ok` = value of `tools_status.gobuster`
• `dirb_ok` = value of `tools_status.dirb`
• `nikto_ok` = value of `tools_status.nikto`

**Do not trust a `false` from `/health` — re-verify it.** Some server builds have a defect where the `/health` check runs its internal `which <tool>` probe as an argv **list**, which crashes, so every tool is reported missing even when it is installed. Confirm before believing a `MISSING` verdict.

For any essential tool whose `/health` value is `false` (or if `all_essential_tools_available` is false), re-verify it through the generic `/api/command` endpoint, which uses the unaffected string-command path:

for t in nmap gobuster dirb nikto; do
  v=$(curl -s -m 10 -X POST "{mks_url}/api/command" \
        -H "Content-Type: application/json" \
        -d "{\"command\":\"which $t\"}" | jq -r '.stdout // empty')
  echo "$t -> ${v:-MISSING}"
done

For each tool, set `{tool}_ok = true` if `/health` reported true **OR** the `which` re-verification returned a path. Only treat a tool as genuinely MISSING when **both** the `/health` value is false **and** the `which` probe returns empty. If `/api/command` itself is unreachable, keep the `/health` values and note that availability could not be re-verified.

If re-verification flipped any tool from MISSING to AVAILABLE, note it so the operator understands the server's `/health` is under-reporting (a known server bug, not a missing tool):

NOTE: /health reported {tools} missing, but they are installed (verified via /api/command).
This server's /health check is buggy; agents will route tool calls through /api/command.

For tools not in `tools_status` (sqlmap, hydra, john, metasploit), assume available when server is healthy.

Output this block with real values substituted:

============================================================
TOOL AVAILABILITY
============================================================
Essential tools (verified via /health):
  nmap        {AVAILABLE|MISSING}
  gobuster    {AVAILABLE|MISSING}
  dirb        {AVAILABLE|MISSING}
  nikto       {AVAILABLE|MISSING}

Extended tools (assumed available on healthy Kali server):
  sqlmap      ASSUMED AVAILABLE
  hydra       ASSUMED AVAILABLE
  john        ASSUMED AVAILABLE
  metasploit  ASSUMED AVAILABLE

All essential tools available: {YES|NO}
============================================================

Use `AVAILABLE` when the tool status is true, `MISSING` when false.

If `all_essential_tools_available` from the health response is false, output an additional warning:

WARNING: One or more essential tools are missing on the Kali server.
Agents may fall back to local Bash commands for missing tools.

Step 4 — Save .pentest-mks.json

Write `.pentest-mks.json` with the following content, substituting real values:

{
  "url": "{mks_url}",
  "status": "active",
  "essential_tools": {
    "nmap": {nmap_ok},
    "gobuster": {gobuster_ok},
    "dirb": {dirb_ok},
    "nikto": {nikto_ok}
  },
  "extended_tools": ["sqlmap", "hydra", "john", "metasploit"]
}

Step 5 — Output MKS ACTIVE Session Block

Output the following block verbatim, substituting `{mks_url}` with the real value:

============================================================
MKS ACTIVE
============================================================
Kali tool server connected: {mks_url}

HOW AGENTS USE MKS TOOLS:
  MKS tools are invoked via HTTP POST requests using Bash curl:

  nmap scan:
    curl -s -m 120 -X POST {mks_url}/api/tools/nmap \
      -H "Content-Type: application/json" \
      -d '{"target":"<target>","scan_type":"-sS","additional_args":"-p- --min-rate 10000 -T4 -Pn"}'

  gobuster scan:
    curl -s -m 300 -X POST {mks_url}/api/tools/gobust