/hunt-dispatch
Skill-set loader for /hunt orchestrator. Fingerprints the target, picks the right platform attack skills, and loads the Red Team or WAPT skill set. Use when /hunt has just received a mode answer (redteam or wapt + blackbox|greybox) and needs to load the appropriate skills and
$ npx -y skills add elementalsouls/Claude-BugHunter --skill hunt-dispatch --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/hunt-dispatch
Context preview
The summary Claude sees to decide when to auto-load this skill.
Skill-set loader for /hunt orchestrator. Fingerprints the target, picks the right platform attack skills, and loads the Red Team or WAPT skill set. Use when /hunt has just received a mode answer (redteam or wapt + blackbox|greybox) and needs to load the appropriate skills and
SKILL.md
hunt-dispatch.SKILL.mdname: hunt-dispatch
description: Skill-set loader for /hunt orchestrator. Fingerprints the target, picks the right platform attack skills, and loads the Red Team or WAPT skill set. Use when /hunt has just received a mode answer (redteam or wapt + blackbox|greybox) and needs to load the appropriate skills and print the taxonomy. Not for direct user invocation.
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
donerecord 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-redirect `curl -sI` silently misses those matches. pull both headers and the landing-page HTML (`__NEXT_DATA__`, `VIEWSTATE`, `laravel_session`, `Ignition`, framework markers live in the body, not headers).
HOSTS="$TARGET"
if [ -f "recon/$TARGET/live-hosts.txt" ]; then
HOSTS=$(cat "recon/$TARGET/live-hosts.txt")
fi
for H in $HOSTS; do
echo "=== $H ==="
# -L follow redirects, -D - dump headers, -o body; cap body to keep context small
curl -sSL -m 12 -D - -o /tmp/fp_body "https://$H" 2>/dev/null | tr -d '\r'
# surface body-only platform markers
grep -aoE '__NEXT_DATA__|/_next/|VIEWSTATE|rO0[AB]|laravel_session|Ignition|Telescope|Whitelabel|/actuator|application/grpc|socket\.io|swagger|\.js\.map' \
/tmp/fp_body | sort -u
done
rm -f /tmp/fp_bodyif `live-hosts.txt` is absent, the loop still runs once against `$TARGET`. record which signal came from which host — a platform skill matched on host B does not imply host A runs that stack.
look for the following signals → platform skill mapping:
okta.com | auth0.com | pingidentity → okta-attack
login.microsoftonline.com | outlook | sts → m365-entra-attack
pulse | fortinet | ivanti | citrix → enterprise-vpn-attack
vsphere | vcenter | :9443 → vmware-vcenter-attack
amazonaws | azure | googleapis | gcp → cloud-iam-deep
github.com/<org>/ → supply-chain-attack-recon
.apk | play.google.com → apk-redteam-pipeline
MongoDB | mongoose | CouchDB | Redis → hunt-nosqli
?page= | ?file= | ?path= | php wrapper → hunt-lfi
rO0A | VIEWSTATE | rememberMe cookie → hunt-deserialization
Access-Control-Allow-Origin header → hunt-cors
/forgot-password | /reset | X-Forwarded → hunt-host-header
?redirect= | ?next= | ?return= | ?url= → hunt-open-redirect
OTP | /verify | /2fa | no-rate-limit → hunt-brute-force
Set-Cookie session | PHPSESSID → hunt-session
Active Directory | LDAP | OpenLDAP | ADFS → hunt-ldap
__NEXT_DATA__ | /_next/ | buildId → hunt-nextjs
X-Powered-By: Express | Node.js | .js stack → hunt-nodejs
postMessage | dangerouslySetInnerHTML → hunt-dom
WebSocket | ws:// | socket.io → hunt-websocket
gRPC | :50051 | application/grpc → hunt-grpc
laravel_session | Ignition | Telescope → hunt-laravel
X-Application-Context | Whitelabel | /actuator → hunt-springboot
:6443 | :10250 | :237
Read more
name: hunt-dispatch description: Skill-set loader for /hunt orchestrator. Fingerprints the target, picks the right platform attack skills, and loads the Red Team or WAPT skill set. Use when /hunt has just received a mode answer (redteam or wapt + blackbox|greybox) and needs to load the appropriate skills and print the taxonomy. Not for direct user invocation.
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
donerecord 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-redirect `curl -sI` silently misses those matches. pull both headers and the landing-page HTML (`__NEXT_DATA__`, `VIEWSTATE`, `laravel_session`, `Ignition`, framework markers live in the body, not headers).
HOSTS="$TARGET"
if [ -f "recon/$TARGET/live-hosts.txt" ]; then
HOSTS=$(cat "recon/$TARGET/live-hosts.txt")
fi
for H in $HOSTS; do
echo "=== $H ==="
# -L follow redirects, -D - dump headers, -o body; cap body to keep context small
curl -sSL -m 12 -D - -o /tmp/fp_body "https://$H" 2>/dev/null | tr -d '\r'
# surface body-only platform markers
grep -aoE '__NEXT_DATA__|/_next/|VIEWSTATE|rO0[AB]|laravel_session|Ignition|Telescope|Whitelabel|/actuator|application/grpc|socket\.io|swagger|\.js\.map' \
/tmp/fp_body | sort -u
done
rm -f /tmp/fp_bodyif `live-hosts.txt` is absent, the loop still runs once against `$TARGET`. record which signal came from which host — a platform skill matched on host B does not imply host A runs that stack.
look for the following signals → platform skill mapping:
okta.com | auth0.com | pingidentity → okta-attack login.microsoftonline.com | outlook | sts → m365-entra-attack pulse | fortinet | ivanti | citrix → enterprise-vpn-attack vsphere | vcenter | :9443 → vmware-vcenter-attack amazonaws | azure | googleapis | gcp → cloud-iam-deep github.com/<org>/ → supply-chain-attack-recon .apk | play.google.com → apk-redteam-pipeline MongoDB | mongoose | CouchDB | Redis → hunt-nosqli ?page= | ?file= | ?path= | php wrapper → hunt-lfi rO0A | VIEWSTATE | rememberMe cookie → hunt-deserialization Access-Control-Allow-Origin header → hunt-cors /forgot-password | /reset | X-Forwarded → hunt-host-header ?redirect= | ?next= | ?return= | ?url= → hunt-open-redirect OTP | /verify | /2fa | no-rate-limit → hunt-brute-force Set-Cookie session | PHPSESSID → hunt-session Active Directory | LDAP | OpenLDAP | ADFS → hunt-ldap __NEXT_DATA__ | /_next/ | buildId → hunt-nextjs X-Powered-By: Express | Node.js | .js stack → hunt-nodejs postMessage | dangerouslySetInnerHTML → hunt-dom WebSocket | ws:// | socket.io → hunt-websocket gRPC | :50051 | application/grpc → hunt-grpc laravel_session | Ignition | Telescope → hunt-laravel X-Application-Context | Whitelabel | /actuator → hunt-springboot :6443 | :10250 | :237
A self-contained Claude skill bundle for bug hunting and external red-team work · 82 skills · 15 slash commands · 681 disclosed-report patterns across 24 core vulnerability classes · enterprise identity + infrastructure attack matrices · engagement-folder
Repo: elementalsouls/Claude-BugHunter
Other skills on claude-bughunter.
- /apk-redteam-pipeline
End-to-end Android APK red-team pipeline — automated APK acquisition (Play Store + apkpure + apkmirror fallback), jadx decompilation, secret/URL/JWT/Firebase grep, pinned-cert extraction, exported-component enumeration, Frida runtime instrumentation templates, intent-injection
Open skill - /bb-local-toolkit
Local-tooling companion to the bug-bounty orchestrator — carries the SAME complete bug-bounty workflow, but reach for THIS variant when you also need to resolve where tools, wordlists, and clones are installed on the local machine (jhaddix, SecLists, trufflehog, ffuf, dalfox,
Open skill - /bb-methodology
Use at the START of any bug bounty hunting session, when switching targets, or when feeling lost about what to do next. Master orchestrator that combines the 5-phase non-linear hunting workflow with the critical thinking framework (developer psychology, anomaly detection,
Open skill - /bug-bounty
Complete bug bounty workflow — recon (subdomain enumeration, asset discovery, fingerprinting, HackerOne scope, source code audit), pre-hunt learning (disclosed reports, tech stack research, mind maps, threat modeling), vulnerability hunting (IDOR, SSRF, XSS, auth bypass, CSRF,
Open skill - /bugcrowd-reporting
Bugcrowd-specific reporting tactics complementing report-writing: VRT category search-and-fallback strategy when no exact match exists, manual severity override when VRT defaults underrate impact, severity-request paragraph as first body section, OOS-clause rebuttal templates
Open skill - /cloud-iam-deep
Cloud IAM red-team attack chain across AWS, Azure, GCP — focused on EXTERNAL exploitation paths and post-credential-discovery privilege analysis. Covers IAM enumeration (aws iam, az role, gcloud iam), STS/AssumeRole chaining, Azure Managed Identity abuse (via SSRF/leak), GCP
Open skill

