/hunt

name: hunt
description: "Active vulnerability hunting on a target. Loads scope, reads brain, detects tech stack, runs targeted tests with concrete payloads. Usage: /hunt target.com [--vuln-class idor|xss|ssrf|sqli|ssti|oauth|rce|race|graphql|upload|business-logic|llm-ai]"
disable-model-invocation: false

Active hunting on: $ARGUMENTS

ALL agents dispatched by this command MUST use `model: "inherit"` in the Agent tool call.

Read `rules/hunting.md` AND `rules/mistakes.md` FIRST. Both are always active.

• `rules/hunting.md` — 29 hunting rules (Rule 0 → Rule 28)
• `rules/mistakes.md` — "Top 10 Most Common Mistakes" + category rules from real engagements. Agents repeat these without the reminder (hallucinated file paths, curl vs browser, theoretical impact, CVSS mismatch, etc.).
• `rules/waf-bypass-protocol.md` — 7-level bypass ladder. If any probe returns a WAF block (403/429/challenge page), this file is mandatory reading before concluding dead end. "WAF blocks the payload" is NEVER a valid stop reason by itself — that's exactly the scenario this file exists for.
• `rules/payloads.md` — ready-to-use payloads organized by vuln class, with bypass variants for common WAFs (CF, Akamai, AWS WAF, F5, Imperva).

Phase 1: Read Before Touching (mandatory)

1. Read scope.yaml — confirm target is in scope 2. Read brain: `uv run python3 $CLAUDE_PROJECT_DIR/tools/brain.py brief <target>` — what's tested, what's exhausted 3. Read hacktivity.md — what has been reported and paid for this program 4. `uv run python3 $CLAUDE_PROJECT_DIR/tools/scope_check.py <target>` — hard validation

Phase 1.5: Policy Enforcement (MANDATORY)

Read `policy.md` and extract ALL actionable constraints into a policy preamble. This preamble MUST be included in every agent dispatch from this command.

POLICY CONSTRAINTS (VIOLATION = DISQUALIFICATION/BAN):
SCOPE AND POLICY MUST BE OBEYED AT ALL TIMES.
[constraints extracted from policy.md]

Failure to include policy constraints in agent dispatches may result in disqualification from the program or account ban.

Phase 2: Tech Stack Detection

TARGET="<parsed from arguments>"
curl -sI https://$TARGET | grep -iE "server|x-powered-by|x-aspnet|x-runtime|x-generator"

Map stack → primary bug class:

• Ruby on Rails → mass assignment, IDOR
• Django → IDOR (ModelViewSet), SSTI
• Flask → SSTI, SSRF
• Express/Node → prototype pollution, path traversal
• Spring Boot → Actuator endpoints, SSTI
• Next.js → SSRF via Server Actions, open redirect
• GraphQL → introspection, IDOR via node(), auth bypass on mutations

Phase 2.5: Auto-Select Vuln Class (autonomy-first)

If `--vuln-class` was NOT specified, generate ranked class hypotheses:

uv run python3 $CLAUDE_PROJECT_DIR/tools/intel_engine.py classes \
  --tech-stack "<detected stack + recon hints>" \
  --target <target> \
  --limit 8 \
  --output CLASS_HYPOTHESES.md

Use the top-ranked class first, then continue in ranked order. This ranking combines stack signals + hacktivity ROI + brain exhaustion penalties.

Phase 2.9: Writeup Intelligence (MANDATORY — do this BEFORE Phase 3)

Before testing ANY vuln class, search for prior art using the writeup-search MCP:

search_techniques "<vuln class>" — get known bypass techniques
search_writeups "<target tech stack> <vuln class>" — get relevant writeups
search_payloads "<vuln class>" — get ready-to-use payloads

If the writeup-search MCP is not available, read `rules/payloads.md` as fallback.

This is NOT optional — prior art saves hours and reveals techniques you wouldn't think of. Skip this step = guaranteed duplicate or missed opportunity.

Include the writeup intelligence results in every hunter agent prompt you dispatch. If a hunter signals a different vuln class mid-hunt: 1. Call `search_techniques` + `search_payloads` for the new class 2. Dispatch the appropriate specialized hunter with the fresh intelligence

Phase 2.95: Autonomous Budget + Exhaustion Gates (MANDATORY)

Before dispatching classes, allocate budget:

uv run python3 $CLAUDE_PROJECT_DIR/tools/intel_engine.py budget \
  --tech-stack "<detected stack + recon hints>" \
  --target <target> \
  --total-minutes 120 \
  --total-tokens 30000 \
  --output CLASS_BUDGET.md

After any class is "exhausted", enforce quality:

uv run python3 $CLAUDE_PROJECT_DIR/tools/intel_engine.py exhaustion-gate \
  --attempts <N> \
  --combos-tested <N> \
  --combos-remaining <N> \
  --encoding-steps <N> \
  --differential-evidence

If gate fails, re-dispatch class with stricter matrix requirements.

After each class run, update telemetry:

uv run python3 $CLAUDE_PROJECT_DIR/tools/intel_engine.py record-outcome \
  --vuln-class <class> \
  --result <confirmed|killed|downgraded|partial> \
  --attempts <N> \
  --elapsed-minutes <N>

Chain-anchor preamble (MANDATORY for feeder classes)

For these vuln classes — **standalone is on the never-submit list or sells low** — extract the per-class anchors from `rules/chain-table.md` "Per-Class Chain Anchors" and prepend them to the hunter dispatch prompt:

open-redirect, cors-hunter, info-disclosure, csrf-hunter, subdomain-takeover,
xxe-hunter, file-upload, race-condition, business-logic, privilege-escalation

Inject this preamble verbatim into the hunter's task:

CHAIN-ANCHOR DIRECTIVE — this finding class sells low/N-A standalone.

After confirming the bug, you MUST probe the following chain anchors before
declaring the finding complete (see rules/chain-table.md "Per-Class Chain
Anchors" section for full list):

[paste the 3-5 anchors for the specific class from chain-table.md]

For each anchor:
- If the anchor returns signal → label finding as CHAIN-CANDIDATE in brain
  with `--from-capability "<this finding's capability>"` and STOP. Do not
  write a single-bug report. The orchestrator will dispatch chain-builder.
- If all anchors fail → finding is informational. Apply rules/never-submit.md
  before an