| name | engagement-setup |
| description | How to start a HuntMCP engagement -- assessment mode selection, /goal focus mode, target fingerprinting, and the ROI-based testing order. Converted from master-pentest-prompt.md Phases 0.1/0.2/0.5/0.9. Use at the very start of an engagement, before any live testing. |
Engagement setup
This is the "before Phase 1" checklist HuntBrain works through once per
engagement, after scope/authorization is confirmed (see AGENT-BRIEF.md
and engagement.yaml -- those are the enforced scope boundary; this skill
is about how to run the engagement inside that boundary, not whether
you're allowed to).
When to use
At the very start of an engagement, right after Phase 0 scope
confirmation and before spawning recon-agent. Also re-read the ROI
priority order section any time you're deciding what to test next.
Assessment mode
Ask the user to pick ONE mode, once, then never ask again during the
engagement:
- FULL BLACKBOX PENTEST -- use every phase/skill, plus the learning
phases (see
knowledge-loading skill). Deep, recursive, slow.
- NORMAL SECURITY ASSESSMENT -- lightweight, focused, hard time cap;
skip the learning phases and heavy fuzzing.
If the mode is unspecified, don't proceed until the user chooses.
Scope is the exact domain plus all subdomains and everything related. If
a subdomain is given, still run the whole engagement against the apex
domain too. Subdomain enumeration is mandatory regardless of mode
(subfinder / crt.sh / amass -- see recon-agent). Spend real time on one
domain before moving to the next; thoroughly test one endpoint before the
next rather than skimming many shallowly.
Rate-limit policy: no artificial per-request delay by default -- run at
real recon/scan speed. tool_resolver.run_tool() is purely reactive:
classify_block() only ever triggers a delay (5s, then exactly one
retry) after an actual 429/rate-limit signal is detected in a tool's
output, never as a blanket sleep-between-requests policy (a proactive
per-request delay would trade away real speed for a problem that mostly
doesn't happen). Don't hand-add your own throttling on top of this. If a
request/scan hangs for a long time, abandon it and move on rather than
blocking the whole engagement.
Goal focus mode (/goal)
If the user issues /goal <objective> (e.g. "achieve RCE on target.com"):
- The objective becomes the highest-priority task of the engagement.
- All recon, payload generation, endpoint discovery, chaining, and
exploitation revolve around that goal.
- Ignore low-value findings, info-only issues, and unrelated vulns while
the goal is active.
- Continuously self-reason: "What is blocking the goal?", "What extra
access/primitive is needed?", "Can another vuln lead to the goal?"
- If the goal is reachable by chaining several issues, prioritize the
exploit chain (see chain-planner). Pivot automatically when a path
fails.
- On success, output exactly "GOAL ACHIEVED", then provide: exploitation
path, proof/evidence, impact, reproduction steps, root cause.
- If exhausted, exit goal focus mode gracefully and resume the normal
phased assessment.
/goal overrides scan priority but never overrides scope, legality, or
authorization boundaries -- the scope gate (scope_guard.py +
scripts/hooks/scope_gate_hook.py) still applies unconditionally.- Execution priority: 1) the goal, 2) exploit chains toward the goal,
3) recon supporting the goal, 4) normal assessment tasks.
Target resolution and fingerprint
Normalize the URL: test http://, https://, and a www. prefix;
follow redirects (-L) to find the canonical host. If a bare domain is
given, also infer www..
Full initial fingerprint (every header, body, and stats):
curl -s -i -L -k -A "<browser UA>" https://canonical/ \
-w "\nHTTP:%{http_code} Time:%{time_total}s Size:%{size_download} IP:%{remote_ip} SSL:%{ssl_verify_result}"
Map headers to tech stack to a targeted playbook:
| Header signal | Stack |
|---|
Server: nginx / Apache | nginx-specific / Apache-specific |
X-Powered-By: PHP/x | PHP payloads |
PHPSESSID | PHP |
JSESSIONID | Java |
ASP.NET_SessionId | .NET |
CF-RAY | Cloudflare -- WAF bypass needed, see waf-bypass skill |
X-Amz-Cf-Id | CloudFront |
X-Served-By | Fastly |
Save the full response; extract every URL, JS file, form, parameter, and
inline script before any exploit attempt -- map the building before
testing it. For every discovered subdomain/endpoint/version string:
research public CVEs/exploits (writeup-mcp's fetch_cves), then actually
attempt exploitation, not just note it.
ROI priority order
This is an ORDERING rule -- every phase/skill still runs in full on
every target. Nothing is skipped or deprioritized out of existence. Based
on confirmed-findings frequency across real engagements, test in this
order:
- Financial IDOR / access control (wallet, payout, ledger, order,
refund, invoice
/show/{id}) -- highest confirmed payout class.
- Debug mode / verbose-500 / error-trace leaks (source, SQL
bindings, env, paths, secrets).
- Payment & token flows (test/live keys, client-side amount,
callback signature/amount verification, token replay/idempotency).
- Auth / OTP / reset flows (OTP in response, rate-limit/lockout,
reset 500-vs-302 enumeration, MFA bypass).
- Secrets in client bundles / HTML (grep and use every key --
secrets-mcp automates the grep step).
- CORS / cross-origin (origin reflection + credentials, WS hijack).
- Staging / UAT / preprod exposure + subdomain takeover (dangling
CNAME) -- cheap, often accepted.
- EOL / unpatched components (version fingerprint -> CVE -> exploit).
- Everything else -- every remaining skill/phase, in full.
Reality check: this order is a starting point, not a cage. If recon
reveals a different high-value surface first (an exposed admin panel, a
live payment API, an upload endpoint, a debug console), hit it first and
record why -- the order follows the target, not the list.
