hunt-dispatch

> **⚠️ AUTHORIZED USE ONLY**

> This skill is for educational purposes or authorized security assessments only.

> You must have explicit, written permission from the system owner before using this tool.

> Misuse of this tool is illegal and strictly prohibited.

> **Mandatory confirmation gate**

> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:

> 1. Ask the user to state the exact target URL, IP, account, or resource.

> 2. Ask the user to confirm written authorization and the permitted scope.

> 3. Show the exact command(s) and explain their expected effect.

> 4. Wait for explicit confirmation in the current conversation.

>

> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.

# hunt-dispatch

skill-set loader for `/hunt`. one concept (which skills to load), one place.

engagement context

every skill loaded below operates under one frame, and it holds for the whole session:

- **authorized and scope-bounded.** the operator asserted written authorization for the named scope

when they invoked `/hunt`. testing stays inside it. an out-of-scope host ends the run — it does not

widen it.

- **the output is a finding, not an exploit.** the deliverable is a reproducible proof that a defect

exists, written so the owner can remediate it. enough to demonstrate impact; no further.

- **remediation is the point.** these skills exist so defects get fixed by the people who own them.

this frame is stated here because it is the choke point every `/hunt` run passes through before any

`hunt-*` skill loads. it is not a prompt and needs no answer.

invocation contract:

hunt-dispatch mode=redteam
hunt-dispatch mode=wapt box=blackbox
hunt-dispatch mode=wapt box=greybox

step 0 — 404 baseline (ALL modes, mandatory, before any enumeration)

run this for **every** host before probing a single path. it takes one request per

host and it is the cheapest false-positive kill in the whole toolkit.

many modern estates (SPA / Next.js / React front ends behind a CDN) return

**HTTP 200 with the application shell for paths that do not exist**. a status code

therefore proves nothing. without a recorded control, `/.well-known/security.txt`,

`/api/revalidate`, `/__nextjs_original-stack-frame` and `/__nextjs_launch-editor`

all "exist" on a host where none of them do.

for H in $HOSTS; do
  # two independent bogus paths — if they agree, that IS the soft-404 signature
  for P in /zzz-nope-12345 /qqq-other-98765; do
    printf "%-34s %-20s " "$H" "$P"
    curl -sk -m 12 -o /tmp/b -w "%{http_code} %{size_download} " "https://$H$P"
    shasum /tmp/b | cut -c1-12
  done
done

record per host: **status, byte length, body hash**. that triple is the control.

**the rule: no path is "found" until its response differs from the control.**

a 200 that matches the control hash is a soft 404. a 404 whose body differs from

the control may be a real handler. compare bodies, never status codes alone.

re-derive the baseline per host — it differs across an estate. one engagement saw

two hosts serving the *same* application return soft-404 bodies of wildly different

size, so a control taken from one host would have been meaningless on the other.

also re-derive it **per path depth** where a framework renders different fallbacks

for `/x` and `/a/b/x`.

edge pages are not origin findings: a CDN "Access Denied" / "Unsupported Request"

body means the request never reached the application. classify it as edge

behaviour and move on.

step 1 — fingerprint (red team only)

fingerprint **every** live host, not just the apex. for multi-host / wildcard

targets the platform-skill routing must be driven by all banners, not one host's.

use `-L` (follow redirects) — identity-provider and CDN signals

(`login.microsoftonline.com`, `okta`, `auth0`, CDN banners) routinely sit

behind a 30x, so a no-redir