kage

Kage — ペンテスト用サンドボックス

このスキルを使用する場面

• kage <target> — ブラックボックスのエンゲージメント
• pentest <target> / security audit on <target> — 上記と同じ
• kage audit <local path> — ホワイトボックスのソース監査のみ
• kage greybox <target> <source-path> — ブラックボックス＋ソースのコンテキスト

<target>には、ドメイン、URL、ワイルドカード（*.example.com）、またはローカルの ソースパスを指定できます。greyboxモードでは、Turn 0でまずバンドルされた audit-context-building 手法をソースに適用し、その後、信頼境界と認証フローの コンテキストをTurn 2〜3に渡します。

コンテナモデル

すべてのツールは、$Kシム経由でエンゲージメントごとのKaliコンテナ内で実行されます。各作業ディレクトリには 専用のコンテナ（名前は$PWDから生成）が割り当てられるため、複数のエンゲージメントを 相互に干渉させずに同時実行できます。

SKILL_DIR="$HOME/.claude/skills/kage"
K="$SKILL_DIR/scripts/k"
"$K" <cmd>            # runs <cmd> inside this engagement's container
"$K" ls | reset | prune | nuke   # management subcommands

プローブはコンテナ内の/skill/scripts/*.pyにあります（読み取り専用の バインドマウント）。結果は/workspace/results/<target>/に出力されます（現在の作業ディレクトリから バインドマウントされています）。

ペンテストツールをホスト上で直接実行しないでください。

---

Turn 0 — セットアップ

SKILL_DIR="$HOME/.claude/skills/kage"
K="$SKILL_DIR/scripts/k"
"$K" whoami            # warms the sandbox; surfaces docker errors

TARGET="example.com"   # derive from user prompt; slugify for paths

# Host-side mkdir so dirs are owned by your UID (host Write tool needs this).
mkdir -p "results/$TARGET"/{recon,vulns,testing,exploits,chains,verification,judging,reports}

ユーザーのCWDに./creds.mdがあれば読み込みます。存在しない場合は、 ブラックボックスで続行するか、テンプレート assets/creds.sample.mdを参照するかを尋ねます。

Greyboxの事前確認（モードがgreyboxの場合のみ）

audit-context-building 手法を<source-path>に適用します。モジュールが大規模な場合は、 function-analyzer サブエージェントを起動します。必要に応じて、複数を並列で起動してください。

results/$TARGET/context.mdに以下を記述します：信頼境界、認証 フロー、データフロー、価値の高いエントリーポイント、既知の機微なパラメーター。 すべてのTurn-2テスターとTurn-3aのエクスプロイターは、通常の入力と 合わせてcontext.mdを読み込みます。

{target, scope_type, started_at, rules_of_engagement}を含むresults/$TARGET/engagement.jsonを作成します。

---

Turn 1 — 偵察（2つのフェーズ）

検出はストリーミングパイプとして高速に実行されます（1〜3分）。脆弱性スキャンは 時間がかかるため（5〜15分）、nucleiの冗長な出力がメインのコンテキストを 汚染しないよう、サブエージェント内で分離して実行します。

フェーズ1 — 検出

R="results/$TARGET"
"$K" bash -c '
  set -e
  cd /workspace
  R="results/'"$TARGET"'"
  (subfinder -d "'"$TARGET"'" -silent \
     | tee "$R/recon/subs.txt" \
     | httpx -silent -title -tech-detect -status-code \
     | tee "$R/recon/live.txt") &
  (gau --subs "'"$TARGET"'" > "$R/recon/wayback.txt") &
  (until [ -s "$R/recon/live.txt" ]; do sleep 1; done
   katana -u "$R/recon/live.txt" -d 3 -jc -silent -o "$R/recon/crawl.txt") &
  (python3 /skill/scripts/dorks.py -d "'"$TARGET"'" --output "$R/recon/dorks.json") &
  wait'

並行して、port-scannerを起動します： HOSTS_FILE=$R/recon/live.txt、OUTDIR=$R/recon/ports/。

GITHUB_TOKENが設定されている場合は、scripts/gitmail.pyも実行します：

"$K" bash -c "GITHUB_TOKEN=\"$GH_TOKEN\" python3 /skill/scripts/gitmail.py \
   -O <guessed-org> -r -s --verified-only \
   -o /workspace/$R/recon/github.json"

フェーズ2に進む前に、パイプ、port-scanner（実行した場合はgitmailも）の完了を待ちます。

フェーズ2 — 脆弱性スキャン

vuln-scannerを起動し、 LIVE_HOSTS_FILE=$R/recon/live.txt、OUTPUT=$R/vulns/nuclei.txtを指定します。

Turn 2に進む前に、vuln-scannerの完了を待ちます。

まとめ

recon/summary.mdに以下を記述します：サブドメイン数、稼働ホスト数、価値の高い ポート、nucleiの重大度別件数と主な検出結果、認証エンドポイント、IDを含む APIパス、URLを受け付けるパラメーター。

ユーザーがrecon-onlyと指定した場合は、ここで終了します。

---

ターン 2 — 詳細テスト（並列ファンアウト）

recon/summary.md を読みます。該当するトリガーが発生した場合は、対応するテスターのサブエージェントを同時に起動します。すべてのディスパッチを 1 つのメッセージで送信します。各テスターは共有コンテナに対して独自に $K を呼び出し（docker exec は並列実行されます）、それぞれの testing/<class>/ パスに書き込みます。

recon のトリガー	ディスパッチ
login / SSO / OAuth / JWT エンドポイント	auth-tester
オブジェクト ID と 2 つのアカウントを持つ API エンドポイント	idor-tester
403、管理パネル、ロール制限付きルート ＋ 2 つ以上のロール	access-control-tester
url= / redirect= / proxy= / fetch= / webhook= パラメーター	ssrf-tester
パラメーター化された URL、検索フィールド、フォーム、GraphQL 変数	injection-tester
ユーザー向け HTML（コメント、プロフィール、検索）	client-side-tester
OpenAPI/Swagger URL、/graphql、REST ルート	api-tester
payment / coupon / redeem / invite / signup エンドポイント	logic-tester
クローラーの対象範囲が狭く、隠しパスがありそうな場合	content-discovery
ターン 1 で JS バンドルが見つかった場合	js-secret-scanner
稼働中のウェブホストがある場合	headers-tester
2 つ以上のアカウントが必要な場合（セルフサービス登録）	agentmail を使って使い捨ての受信箱を作成します（AGENTMAIL_API_KEY が必要です）

greybox モードでは、すべてのテスターが results/$TARGET/context.md も読み込み、汎用スキャンではなく、ソースコードから判明している弱点を重点的に調べます。

すべてのテスターから結果が返るまで待ちます。 結果の JSON をまとめて、候補となる指摘事項の一覧を作成します。すべてのプローブは共通の findings[] / summary{} 形式で出力します。すべての HTTP 通信には scripts/tls.py を使用します（Cloudflare のターゲットでは scripts/browser.py を使用します）。

5 分ルール。 5 分以内に立証できない調査の手掛かりは切り上げて、次に進みます。理論上のバグは対象外です。

---

ターン 3 — 悪用、検証、連鎖、判定

順次実行します。各ステップの結果を次のステップに渡します。

3a. 悪用 — PoC を作成する前に絞り込む

references/judging.md を読みます。候補となる指摘事項ごとに、次の対応を行います。

• 自動除外パターンに該当する場合は即座に除外します（PoC のないヘッダー欠落、バージョンバナー、セルフ XSS、ログアウト CSRF、TRACE/TRACK、TLS 暗号スイートの問題、SPF/DKIM/DMARC、情報漏えいにつながる 500 エラー、悪用シナリオのないレート制限の欠如）。これらの PoC は作成しないでください。
• 影響の説明に「could potentially」が含まれる場合、またはブラックボックスでは検証できない条件が必要な場合は除外します。greybox モードでは、まず context.md を確認します。ソースコードによって確認または否定できる場合があります。
• 攻撃者の操作によって、実際の影響（データアクセス、コード実行、認証バイパス、コスト増幅、状態変更、金銭的影響）を伴う、観測可能で再現可能なサーバー側の結果が生じる場合にのみ、PoC を作成します。

残った各項目について、results/$TARGET/exploits/<slug>.py に curl_cffi の PoC を作成します。初回の実行で再現できないものは除外します。

3b. 検証 — 並列

各 PoC に対して verifier をディスパッチします。すべての verifier タスクを 1 つのメッセージで送信します。それぞれに専用の OUTDIR=results/$TARGET/verification/F<NNN>/、新しい認証情報、クリーンなセッションを割り当て、3 回の再現テストを行います。

結果を verification/verified_findings.json にまとめます。

3c. 連鎖

検証済みの指摘事項に対して chain-builder をディスパッチします。references/chains.md に記載された 7 つの標準パターンを対応付け、創造的な組み合わせも探します。

3d. 判定

judge をディスパッチします。references/judging.md の 4 段階フィルターを適用し、確信度と CVSS を評価して重複を排除し、除外リストを適用します。

出力：judging/approved_findings.json（レポートに含まれる唯一の指摘事項）、judgment.md（監査記録）、dropped_findings.md。

---

Turn 4 — 監査レポート

report-writer を次の内容でディスパッチします： TARGET、ENGAGEMENT_JSON、APPROVED_FINDINGS_JSON、 TEMPLATE=$SKILL_DIR/references/audit-report-template.md、 OUTPUT=results/$TARGET/audit-report.md。

エージェントは、エンゲージメントと承認済みの調査結果から {{placeholders}} を埋めます。 再フィルタリングは行いません。すでに判定担当者が済ませています。完了したら ユーザーにサマリーテーブルを表示します。

---

表面化させるべき失敗モード（握りつぶさない）

• Docker がインストールされていない／実行されていない → shim のエラーを表示して停止します。
• ターゲットに到達できない／DNS が失敗する。
• レート制限または WAF によるブロック → 速度を落とす、フィンガープリントを変更する （tls.py --impersonate <name>）、または scripts/browser.py に切り替えます。
• ユーザーが認証済みテストを求めているのに、creds.md が見つからない。

参考ドキュメント（必要に応じて読み込む）

• references/methodology.md — 攻撃クラスごとのトリガーと呼び出しの詳細
• references/judging.md — 4 段階フィルター + 重大度の基準 + 除外リスト
• references/chains.md — 名前付きのエスカレーションパターン 7 件
• references/report-formatting.md — プラットフォームごとの規約（HackerOne、Bugcrowd、Intigriti）
• references/audit-report-template.md — Turn 4 のテンプレート
• references/tools.md — サンドボックスにインストールされているツールの完全な一覧
• references/audit-context-building/SKILL.md — グレーボックスの方法論
• references/agentmail/SKILL.md — 使い捨て受信トレイのプロビジョニング
• assets/creds.sample.md — スコープと認証情報のテンプレート
• assets/wordlist-strategy.md — ターゲット固有のサブドメイン用ワードリスト