hunt-dispatch

hunt-dispatch

/hunt 用のスキルセットローダーです。どのスキルを読み込むかという概念を一元化します。

呼び出しの仕様：

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

ステップ 1 — フィンガープリントを取得する（レッドチームのみ）

最上位ドメインだけでなく、稼働中のすべてのホストのフィンガープリントを取得してください。複数ホストやワイルドカードのターゲットでは、プラットフォームスキルの振り分けに、単一ホストではなくすべてのバナーを使用してください。

-L（リダイレクトに従う）を使用してください。ID プロバイダーや CDN のシグナル（login.microsoftonline.com、okta、auth0、CDN バナー）は 30x リダイレクトの背後にあることが多いため、リダイレクトしない curl -s --max-time 30 --connect-timeout 10I では、これらの一致を見逃してしまいます。ヘッダーとランディングページの HTML の両方を取得してください（__NEXT_DATA__、VIEWSTATE、laravel_session、Ignition、フレームワークのマーカーはヘッダーではなく本文に含まれています）。

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 --max-time 30 --connect-timeout 10 -sSL -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_body

live-hosts.txt がない場合も、ループは $TARGET を対象に 1 回実行されます。各シグナルがどのホスト由来かを記録してください。ホスト B で一致したプラットフォームスキルは、ホスト A でも同じスタックが動作していることを意味しません。

次のシグナルを探し、プラットフォームスキルに対応付けてください。

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

優先順位の決定と読み込み上限

実際のターゲットでは、ほぼ必ず複数のシグナルが同時に返されます。たとえば、単一のホストに Cloudflare（CDN）＋login.microsoftonline.com（リダイレクト）＋__NEXT_DATA__（Next.js フロントエンド）＋amazonaws（オリジン）が同時に現れる場合があります。一致したスキルを無条件にすべて読み込むと、20 個以上のスキルが読み込まれてコンテキストウィンドウを圧迫し、シグナルの強いスキルがノイズに埋もれてしまうことがあります。次の優先順位と上限を適用してください。

優先順位（最上位から読み込み、上限に達したら停止）：

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

読み込み上限：プラットフォームスキルの読み込みは最大 8 個です。 8 個を超える場合は、優先度の高い 8 個を残し、残りは除外してください。除外したスキルは分類ブロックの deferred: の下に記載し、後で必要に応じて読み込めるようにします。

重複排除ルール（同じ証拠に対して 2 つのスキルを読み込まないようにする）：

• CDN バナー単独（Cloudflare/Akamai/Fastly）はプラットフォームの一致とは見なしません。これはアプリではなくエッジのフィンガープリントです。これに対するスキルは読み込まず、hunt-cache-poison / hunt-http-smuggling 用として記録してください。これらはモードセットにすでに含まれています。
• ヘッダー／オリジン内の amazonaws / azure / googleapis → cloud-iam-deep。 同じ文字列が JS バンドルや APK 内の漏えいしたキー／JSON として見つかった場合も cloud-iam-deep を使用しますが、実際に利用可能な認証情報につながる手掛かりとしてフラグを付けます（優先度を上げ、このホストではティア 3 をティア 1 に引き上げます）。
• 同一ホストでフレームワークのマーカー（__NEXT_DATA__、laravel_session）と一般的なクラスのシグナル（?redirect=、Access-Control-Allow-Origin）が見つかった場合は、フレームワークスキル（ティア 4）を読み込み、クラススキルは上限に余裕がある場合のみ残してください。WAPT／redteam モードセットには、一般的なクラススキルがすでに無条件で含まれています。

ステップ 2 — スキルセットを読み込む

Skill CLI を使って、各スキルを順番に呼び出してください。

mode=redteam

常時読み込むスキル（最初に読み込む）：

redteam-mindset
mid-engagement-ir-detection

プラットフォーム（ステップ 1 のフィンガープリント一致に応じて、2 番目に読み込む）：

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

影響度の高い hunt-* セット（3 番目に読み込む）：

hunt-rce
hunt-sqli
hunt-ssrf
hunt-ato
hunt-auth-bypass
hunt-saml
hunt-oauth
hunt-mfa-bypass
hunt-file-upload
hunt-http-smuggling
hunt-cloud-misconfig
hunt-sharepoint
hunt-aspnet

レポート形式：redteam-report-template（subject / observations / description / impact / recommendation / poc）。

mode=wapt

常時有効：

bb-methodology
security-arsenal
triage-validation

hunt-* の全セット（OWASP 関連すべて）：

hunt-xss             hunt-sqli            hunt-ssrf            hunt-idor
hunt-csrf            hunt-xxe             hunt-rce             hunt-graphql
hunt-oauth           hunt-saml            hunt-mfa-bypass      hunt-auth-bypass
hunt-ato             hunt-file-upload     hunt-business-logic  hunt-race-condition
hunt-llm-ai          hunt-api-misconfig   hunt-ssti            hunt-cache-poison
hunt-http-smuggling  hunt-subdomain       hunt-cloud-misconfig hunt-misc
hunt-aspnet          hunt-sharepoint      hunt-ntlm-info
hunt-lfi             hunt-nosqli          hunt-deserialization
hunt-cors            hunt-host-header     hunt-open-redirect
hunt-brute-force     hunt-session         hunt-ldap
hunt-nextjs          hunt-nodejs          hunt-dom
hunt-websocket       hunt-grpc            hunt-laravel
hunt-springboot      hunt-k8s             hunt-cicd
hunt-source-leak     hunt-tls-network

レポート形式：report-writing（対象が bugcrowd 上にある場合は bugcrowd-reporting）。

box=greybox：認証情報は /hunt ですでに取得され、セッションメモリで利用できます。

認証情報が検証されるまで、認証済みの hunt-* セット全体に一斉に処理を展開しないでください。 /hunt は認証情報の入力を求めて保存するだけで（commands/hunt.md）、有効性の確認は行いません。期限切れ、MFA による制限、またはロール違いの認証情報で、認証が必要なテストをすべて実行すると、実行時間を無駄にし、「認証対象の領域なし」という誤った結論を導くことになります。まず、コストの低い認証プリフライトを1つ実行してください。

# session-cookie creds: one authenticated GET against an identity echo endpoint
curl -sS -m 12 -b "$SESSION_COOKIE" "https://$TARGET/api/me" -w '\n%{http_code}\n'
#   200 + your username/email  → live session, role visible in body
#   401/403                    → dead or insufficient — STOP, re-auth

# bearer/JWT creds: same probe with Authorization
curl --max-time 30 --connect-timeout 10 -sS -H "Authorization: Bearer ***" \
  "https://$TARGET/api/me" -w '\n%{http_code}\n'

# raw user/pass: drive the real login flow once, capture Set-Cookie, then echo
#   watch for an MFA / step-up challenge in the response — if present, the creds
#   alone do not yield an authenticated session (see memory: operator-capability)

プリフライトで次の3点を確認し、hunt-* スキル用に記録してください。

1. 有効性 — 認証プローブが 401/403 ではなく 200 を返すこと。
2. ロール／権限 — /api/me（または同等のエンドポイント）の本文に、想定されるロール／テナント／スコープが表示されること。IDOR および認可テストには、既知の基準となる ID が必要です。気づかないまま管理者または読み取り専用の認証情報を使うと、すべての認可に関する検出結果が歪みます。
3. MFA による制限がないこと — ログインが 2fa／追加認証チャレンジで停止していないこと。停止していた場合、認証情報はありますが、セッションはありません。能力を最低限に見積もり、認証済みのアクセス範囲を主張する前にオペレーターに確認してください。

プリフライトに失敗した場合は、ブラックボックスとして黙って続行しないでください。「greybox creds did not validate (HTTP {code} / MFA challenge)」と明示し、オペレーターが認証情報を再提供できるようにしてください。プリフライトに問題がないことを確認してから、検証済みのセッションを認証が必要なすべてのテストに適用してください。

ステップ3 — 分類の出力（セッション開始時に1回）

決定的なブロックを出力します。装飾なしのプレーンテキストで、小文字、コロン区切りにします。

mode=redteam

loaded for red team: {N} skills
  mindset:    redteam-mindset
  platform:   {fingerprint-matched skills (<=8, tier order), or "none detected"}
  deferred:   {platform skills past the 8-cap, or omit line if none}
  auth:       hunt-ato, hunt-auth-bypass, hunt-saml, hunt-oauth, hunt-mfa-bypass
  inj:        hunt-rce, hunt-sqli, hunt-ssrf, hunt-file-upload
  infra:      hunt-http-smuggling, hunt-cloud-misconfig
  stack:      hunt-sharepoint, hunt-aspnet
  ir:         mid-engagement-ir-detection

mode=wapt

loaded for wapt ({blackbox|greybox}): {N} skills
  inj:        hunt-xss, hunt-sqli, hunt-ssrf, hunt-rce, hunt-xxe, hunt-ssti, hunt-file-upload
  authz:      hunt-idor, hunt-auth-bypass, hunt-ato
  auth:       hunt-oauth, hunt-saml, hunt-mfa-bypass
  api:        hunt-graphql, hunt-api-misconfig
  logic:      hunt-business-logic, hunt-race-condition
  infra:      hunt-http-smuggling, hunt-cache-poison
  recon:      hunt-subdomain
  cloud:      hunt-cloud-misconfig
  ai:         hunt-llm-ai
  stack:      hunt-aspnet, hunt-sharepoint, hunt-ntlm-info
  misc:       hunt-misc, hunt-csrf
  reporting:  bb-methodology, security-arsenal, triage-validation

ステップ4 — /hunt に制御を戻す

分類の出力後、ステップ3（兄弟スキルへの委任）およびステップ4（アクティブテスト）のため、制御を /hunt に戻します。ここではプローブを実行しないでください。このスキルはコンテキストを読み込むだけです。

プライバシー

次の情報を決して再掲、ログ記録、または永続化しないでください。

• SOW／作業範囲／業務委託契約書の内容
• グレーボックスの認証情報（/hunt がセッションメモリに保持し、ディスクには決して書き込みません）
• ユーザーレベルのメモリに保存されるクライアント識別子

---

検証

1. ハント分類の確認 — ディスパッチ分類が完全であることを確認します。

   grep -c "hunt-" SKILL.md && echo "PASS: hunt-* references present" || echo "FAIL"
   

2. 技術フィンガープリントのパターン — フィンガープリントのシグナルが存在することを確認します。

   grep -q "X-Powered-By\|Set-Cookie\|wp-json\|GraphQL" SKILL.md && echo "PASS: fingerprint signals present" || echo "FAIL"
   

すべてのテストでディスパッチの準備状況を検証します。

---

注意点

• プラットフォーム分類の誤り — React アプリを Next.js と誤認したり、Django アプリを Flask と誤認したりすると、誤った hunt-* スキルを読み込むことになります。必ず複数のフィンガープリントシグナルで確認してください。
• スコープ確認前のディスパッチ — 対象がスコープ内であることを確認する前に hunt-* スキルを読み込むと、スコープ外のアセットに時間を費やすことになります。
• 過剰な分類 — 1つのカテゴリにきれいに収まらないアプリもあります。複数のスタックを使うアプリ（React フロントエンド＋Django API）では、両方のスキルセットを読み込む必要があります。
• ヘッダーからのフレームワークバージョンの推測 — X-Powered-By は偽装または削除される可能性があります。JS バンドルの分析、Cookie 名、エラーページの特徴と照合してください。

---

関連スキルとチェーン

• bb-methodology — PART 0 のモード確認が完了したときに使用します。ワークフローの基本要素：bb-methodology はエンゲージメントの種類（レッドチーム、WAPT、バグバウンティ）を確認します。その回答は、このスキルの mode=redteam / mode=wapt の呼び出しに直接反映されます。
• redteam-mindset + mid-engagement-ir-detection — mode=redteam が読み込まれたときに使用します。ワークフローの基本要素：これらは常時有効なスキルで、レッドチームフローのステップ 2 で、プラットフォームスキルまたは hunt-* スキルより先に読み込まれます。
• okta-attack / m365-entra-attack / enterprise-vpn-attack / vmware-vcenter-attack / cloud-iam-deep / supply-chain-attack-recon / apk-redteam-pipeline — フィンガープリントのシグナルが一致したときに使用します。ワークフローの基本要素：ステップ 1 の recon/<target>/live-hosts.txt に対する curl フィンガープリントスキャンによって、バナー／ドメインのシグナルが、これらのプラットフォームスキルの 1 つ以上に対応付けられます。
• hunt-rce / hunt-sqli / hunt-ssrf / hunt-ato / *その他すべての hunt- スキル** — モード固有のスキルセットが表示されるときに使用します。ワークフローの基本要素：このスキルはローダーです。hunt-* スキルを列挙しますが、プローブは実行しません。実際のハンティングは、ステップ 4 で /hunt` に制御が戻った後に行われます。
• report-writing と redteam-report-template — タクソノミーの表示でレポート形式が指定されるときに使用します。ワークフローの基本要素：mode=wapt は成果物の形式として report-writing で終了し、mode=redteam は代わりに redteam-report-template で終了します。