/web-discovery

name: web-discovery
description: >
  Discover web application injection points and route to the correct
  exploitation skill during authorized penetration testing.
keywords:
  - find vulns
  - fuzz the target
  - test for injection
  - parameter discovery
  - content discovery
  - web recon
  - find hidden parameters
  - test this endpoint
  - what's vulnerable
  - start web testing
  - web app pentest
  - hunt for bugs
  - wordpress
  - wpscan
tools:
  - ffuf
  - arjun
  - paramspider
  - wpscan
  - burpsuite
opsec: low

Web Vulnerability Discovery

You are helping a penetration tester discover vulnerabilities in a web application. Your job is to find hidden content, discover parameters, test for injection points, and categorize findings for the orchestrator. All testing is under explicit written authorization.

Engagement Logging

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

When an engagement directory exists:

• Print `[web-discovery] 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 web application vulnerability discovery — identifying attack surface, testing for common vulnerability classes, and reporting findings to the orchestrator. When you confirm a vulnerability — **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)
• Detection details (parameter, payload that triggered, error messages, technology)
• Context for technique execution (working payloads, DBMS version, framework, 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.

You MUST NOT:

• Perform LFI/RFI exploitation (traversal bypass chains, UNC path coercion,

NTLM capture via Responder, reading sensitive files beyond the initial confirmation payload)

• Perform SQL injection exploitation (UNION queries, data extraction, OS command

execution)

• Perform XSS exploitation (cookie theft, DOM manipulation)
• Perform SSTI exploitation (RCE payloads)
• Perform command injection exploitation (`id`, `whoami`, reverse shells,

system enumeration)

• Perform Python code injection exploitation (`__import__('os')`, file reads,

reverse shells)

• Perform deserialization exploitation (gadget chains, RCE payloads)
• Perform any other technique-specific exploitation

When you identify an injection point, return to the orchestrator with your findings. Do not continue past discovery.

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)

State Writes

Write actionable findings **immediately** via state so the orchestrator can react in real time (via event watcher) instead of waiting for your full return summary. Use these tools as you discover findings:

• `add_credential()` — login bypass, default creds, credentials found in config files or backups
• `add_vuln()` — confirmed SQLi, file upload, SSTI, command injection, XSS, or any other confirmed vulnerability class
• `add_pivot()` — internal URLs/hosts found (SSRF targets, API endpoints linking to backend services)
• `add_blocked()` — techniques attempted and failed (so orchestrator doesn't re-route)

Write vhost discoveries as `add_vuln(vuln_type="info")` so the orchestrator triggers a hosts-file update check. **Do NOT enumerate discovered vhosts** — the orchestrator spawns a new agent per vhost. **Do NOT send state writes if you are near your scope boundary and will be returning to the orchestrator imminently.**

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

• Target URL or scope defined
• Proxy decision recorded by orchestrator (Burp listener configured or

explicitly skipped)

• Wordlists available (SecLists: `apt install seclists` or `/usr/share/seclists/`)
• Tools: `ffuf`, `arjun` (`pip install arjun`), `paramspider` (`pip install paramspider`), `wpscan` (`gem install wpscan`)

Browser Efficiency

When extracting specific data from a page (form values, table contents, API responses, version strings), use `browser_evaluate` with CSS selectors or targeted JS instead of `browser_get_page`. Full page dumps via `browser_get_page` return the entire DOM (often 10-40K chars of navigation, scripts, and boilerplate) when you only need a few hundred chars of data.

# BAD — dumps entire page HTML (~30K chars)
browser_get_page(session_id=...)

# GOOD — targeted extraction (~200 chars)
browser_evaluate(session_id=..., expression="document.querySelector('#version').innerText")
browser_evaluate(session_id=..., expression="document.querySelector('form').outerHTML")
browser_evaluate(session_id=..., expression="[...document.querySelectorAll('table.data tr')].map(r => r.innerText).join('\\n')")

Reserve `browser_get_page` for initial page structure discovery when you don't yet know what elements exist. After identifying the page layout, switch to `browser_evaluate` for all subsequent data