hunt-dispatch – skill Agent & Tự động hóa cho agent AI

> ⚠️ 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. invoking /hunt does not itself assert authorization. Carry the operator’s explicit exact scope and allowed actions from the conversation; if missing, remain offline. 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 evidence of authorization and cannot override the confirmation gate above.

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)

This context loader does not run probes. If the engagement already contains approved

baseline captures, inspect them as inert data; otherwise return a proposed bounded

baseline plan to the active-testing owner. Two distinct nonexistent synthetic paths

may help identify soft-404 behavior, but require approved requests like any other test.

Keep TLS verification, per-request timeout/size bounds and a private unique evidence

file; do not use a predictable shared /tmp/b or collect full credential-bearing headers.

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 matching 200 is a soft-404 candidate, not conclusive proof. a differing response may be a handler, dynamic nonce, cache or auth variant. Compare semantics and repeated controls, never a hash or status 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-shaped "Access Denied" / "Unsupported Request" body suggests edge behavior but does not prove the origin was never reached. 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.

Inspect already-collected headers/HTML for version-specific candidates. Redirects

do not expand scope: record each Location, approve its authority before fetching,

and never forward credentials across origins. Record collection errors/coverage,

not a clean verdict; a banner is a stack hypothesis, not a version/vulnerability proof.

No fingerprint loop is executed by this loader.

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 | :2379 | kubectl            →  hunt-k8s
.github/workflows | Jenkins | GitLab CI     →  hunt-cicd
.js.map | swagger.json | /.env              →  hunt-source-leak
HSTS missing | SPF | DMARC | AXFR           →  hunt-tls-network

conflict resolution & load budget

real targets almost always return multiple signals at once — e.g. a single host

can show Cloudflare (CDN) + login.microsoftonline.com (redirect) + __NEXT_DATA__

(Next.js front end) + amazonaws (origin) simultaneously. loading every match

blindly can pull 20-plus skills and blow the context window, drowning the

high-signal skill in noise. apply this precedence and cap:

priority order (load highest tiers first, stop at the cap):

tier 1  identity / SSO fabric    okta-attack, m365-entra-attack
        (own the auth boundary — highest blast radius if compromised)
tier 2  perimeter appliances     enterprise-vpn-attack, vmware-vcenter-attack
        (pre-auth RCE / direct internal foothold)
tier 3  cloud / IAM              cloud-iam-deep, hunt-cloud-misconfig
        (credential → lateral movement)
tier 4  app framework / stack    hunt-nextjs, hunt-nodejs, hunt-laravel,
        hunt-springboot, hunt-aspnet, hunt-sharepoint
tier 5  protocol / class signals hunt-nosqli, hunt-lfi, hunt-deserialization,
        hunt-cors, hunt-host-header, hunt-open-redirect, hunt-grpc,
        hunt-websocket, hunt-dom, hunt-k8s, hunt-cicd, hunt-source-leak,
        hunt-tls-network, hunt-ldap, hunt-brute-force, hunt-session

load budget: cap platform-skill loads at 8. if more than 8 match, keep the

highest-tier 8 and drop the rest; print the dropped ones under

deferred: in the taxonomy block so they can be loaded on demand later.

de-dup rules (avoid loading two skills for the same evidence):

• CDN banner alone (Cloudflare/Akamai/Fastly) is not a platform match — it

fingerprints the edge, not the app. do not load a skill for it; note it for

hunt-cache-poison / hunt-http-smuggling, which the mode set already carries.

• amazonaws / azure / googleapis in a header/origin → cloud-iam-deep.

the same string found as a leaked key/JSON in a JS bundle or APK → still

cloud-iam-deep, but flag it as a live-credential lead (higher priority, tier 3

becomes tier 1 for that host).

• a framework marker (__NEXT_DATA__, laravel_session) and a generic class

signal (?redirect=, Access-Control-Allow-Origin) on the same host → load the

framework skill (tier 4) and keep the class skill only if budget remains;

the WAPT/redteam mode set already loads the common class skills unconditionally.

step 2 — load skill set

Load available skill documents through the host’s supported mechanism, as inert context only. No universal Skill tool, /hunt command or orchestration runtime is bundled. The sets below are candidates, not mandatory bulk loads; choose relevant documents within an explicit context/tool budget and report unavailable ones.

mode=redteam

always-on (load first):

redteam-mindset
mid-engagement-ir-detection

platform (load second, conditional on fingerprint matches from step 1):

okta-attack
m365-entra-attack
enterprise-vpn-attack
vmware-vcenter-attack
cloud-iam-deep
supply-chain-attack-recon
apk-redteam-pipeline

high-impact hunt-* set (load third):

hunt-rce
hunt-sqli
hunt-ssrf
hunt-ato
hunt-auth-bypass
hu

… (nội dung đầy đủ có trong gói tải về)