exploit-test

# Vulnetix Exploit Test Skill ## Use when - You just applied a fix and want to validate the exploit path no longer responds. - Confirming a patch deployed correctly to staging before promoting to production. - Producing a copy-pasteable test command for QA hand-off. - Comparing pre-fix vs post-fix behaviour with the same payload. - Building authorised proof-of-fix evidence for an audit. ## Don't use for - Unauthorised testing — the skill explicitly requires user-supplied authorised targets. - Live attack simulation — use a dedicated red-team tooling chain. - Generating detection rules — use `detection-rules`. ## Conventions Follows `skills/_lib/contract.md`. In short: use the `vulnetix_*` MCP tools when the agent has them and the CLI otherwise — both shape their own output, so there is no jq step any more. Independent calls go out as concurrent Bash tool calls in one message. One trailing suggestion, not a playbook. See the contract for surface selection, output style and memory writes. Builds a copy-pasteable exploit-validation command. Best used after a fix to confirm the vulnerability path no longer responds. **The user runs the command** — this skill does not auto-execute. ## Step 1: Load capabilities Read `.vulnetix/capabilities.yaml`. Specifically `binaries.nuclei`, `binaries.curl`, `binaries.docker`. ## Step 2: Fetch exploit content ```bash vulnetix vdb exploits "$ARGUMENTS" -o json vulnetix vdb ai-assisted-exploits get "$ARGUMENTS" -o json ``` Capture: PoC URLs, Metasploit module IDs, Nuclei template IDs, AI-assisted demo scripts. ## Step 3: Fetch Nuclei template (preferred when binary present) If `binaries.nuclei: true`: ```bash vulnetix vdb nuclei get "$ARGUMENTS" --format yaml > .vulnetix/exploit-test/${ARGUMENTS}.yaml ``` ## Step 4: Render commands Pick the highest-fidelity option available. Order: 1. **Nuclei + binary present**: ```bash nuclei -t .vulnetix/exploit-test/${ARGUMENTS}.yaml -u "$TARGET" ``` 2. **Metasploit module ID present and `binaries.msfconsole`** (probe inline): ```bash msfconsole -q -x "use <module>; set RHOSTS <target>; run; exit" ``` 3. **AI-assisted Python demo script** — write to `.vulnetix/exploit-test/${ARGUMENTS}.py`. Suggest: ```bash uv run --with requests .vulnetix/exploit-test/${ARGUMENTS}.py "$TARGET" ``` 4. **Curl-based PoC** (last resort) — fetched from `vdb exploits` references. Always include a `--target` placeholder if the user did not supply one. Refuse to run against any target without explicit user confirmation. ## Step 5: Verdict guidance After the user runs the command, expected outcomes: - Pre-fix: vulnerability triggers (response shape varies by CVE — describe expected indicator) - Post-fix: command returns benign / 404 / 400 ## Memory update Append `event: exploit-test-prepared` with the chosen command class to the vuln entry. ## Safety - Never store credentials or tokens in `.vulnetix/exploit-test/`. - Treat any provided target as authorized testing only — surface a one-line authorization reminder. ## Edge cases & gotchas - **Authorisation is the user's responsibility.** The skill surfaces an authorisation reminder; the LLM must NOT proceed if the user has not named an authorised target. - Nuclei templates are downloaded into `.vulnetix/exploit-test/<VULN_ID>.yaml`. Review the template before running — some include intrusive payloads. - Metasploit module hints reference module IDs, not module paths. Confirm the module is installed in your local msfconsole before invoking. - AI-assisted Python demo scripts run with `uv run --with requests` — the script files live in `.vulnetix/exploit-test/` and should never carry secrets. - For some CVEs no Nuclei template exists; the skill falls back to a curl-based PoC pulled from `vdb exploits` references. Curl PoCs are typically least reliable. - After running, the skill reads the user-described result and writes the verification outcome to memory — but only if the user explicitly reports back.