recon-playbook

外部 Web 調査プレイブック

このプレイブックを使って、許可されたルートドメインまたはアセット一覧から、Web アプリケーション、API、認証境界、および検証可能なセキュリティ仮説を優先順位付けしたマップを作成します。

scope
  -> assets
  -> DNS and services
  -> routes and client code
  -> APIs and identities
  -> hypotheses
  -> focused validation
  -> evidence and reporting

使用する場面

• 外部 Web、API、またはバグバウンティの評価を開始するとき。
• 調査結果はあるものの、正規化、出所情報、または優先順位付けが不足しているとき。
• 対象が複数のアプリケーション、サブドメイン、または ID 境界にまたがるとき。
• 広範なスキャン結果を、焦点を絞った手動検証に落とし込む必要があるとき。

合意したスコープ外での活動を正当化したり、利用可能なすべてのツールをすべてのアセットに対して実行したりするために、このプレイブックを使ってはいけません。

前提条件

• 明示的な許可、対象範囲、除外事項、レート制限、および停止条件。
• curl、jq、subfinder、dnsx、httpx、katana。
• IP またはポートの探索がスコープに含まれる場合に限り、nmap。
• 認可およびセッションのテスト用に承認されたテスト ID。
• 書き込み可能な証拠ディレクトリ。

実行方法

export TARGET="example.test"
export OUTPUT_DIR="${OUTPUT_DIR:-./output/$TARGET}"

mkdir -p \
  "$OUTPUT_DIR/assets" \
  "$OUTPUT_DIR/http" \
  "$OUTPUT_DIR/urls" \
  "$OUTPUT_DIR/evidence"

各フェーズは、直前の出力を確認してから実行します。すべてのホスト名、URL、仮説の出所を追跡できるよう、元のソースファイルを保持してください。

手順

1. スコープを記録する

出力と同じ場所に、担当者が読める簡潔なスコープ記録を保管します。

allowed: *.example.test
excluded: status.example.test
identities: anonymous, test-user-a, test-user-b
request rate: 2 requests/second/host
state changes: synthetic records only

スコープには、テスト可能な対象、使用可能な ID、許容されるトラフィック量、および状態を変更するテストが許可されているかどうかを記載する必要があります。

2. アセットを探索して正規化する

subfinder -d "$TARGET" -silent \
  > "$OUTPUT_DIR/assets/subfinder.txt"

curl -sS --max-time 30 \
  "https://crt.sh/?q=%25.${TARGET}&output=json" \
  | jq -r '.[].name_value' \
  | sed 's/^\*\.//' \
  > "$OUTPUT_DIR/assets/crtsh.txt"

cat "$OUTPUT_DIR/assets/subfinder.txt" \
    "$OUTPUT_DIR/assets/crtsh.txt" \
  | tr '[:upper:]' '[:lower:]' \
  | grep -E '^[a-z0-9.-]+\.[a-z]{2,}$' \
  | sort -u \
  > "$OUTPUT_DIR/assets/hostnames.txt"

アクティブなプロービングを始める前に、ワイルドカードの結果、証明書の SAN、サードパーティの CNAME、および除外対象のアセットを確認します。

3. HTTP サービスを解決して特定する

dnsx \
  -l "$OUTPUT_DIR/assets/hostnames.txt" \
  -silent -a -aaaa -cname -json \
  -o "$OUTPUT_DIR/assets/dns.jsonl"

httpx \
  -l "$OUTPUT_DIR/assets/hostnames.txt" \
  -threads 10 \
  -rate-limit 2 \
  -status-code -title -tech-detect -server -ip -cname \
  -json \
  -o "$OUTPUT_DIR/http/services.jsonl"

jq -r '.url // empty' "$OUTPUT_DIR/http/services.jsonl" \
  | sort -u \
  > "$OUTPUT_DIR/http/live-urls.txt"

技術スタックのラベルやバナーは、調査先を絞るためのシグナルとして扱います。脆弱性と関連付ける前に、重要なコンポーネントを複数の情報源から確認してください。

4. ルート、パラメーター、クライアントコードをマッピングする

katana \
  -list "$OUTPUT_DIR/http/live-urls.txt" \
  -silent -jc -kf all \
  -c 2 -p 2 -rl 2 \
  -o "$OUTPUT_DIR/urls/katana.txt"

grep -Ei '/api/|/graphql|swagger|openapi|/rest/' \
  "$OUTPUT_DIR/urls/katana.txt" \
  > "$OUTPUT_DIR/urls/api-candidates.txt"

grep -Ei 'login|logout|register|reset|oauth|saml|callback|session|token' \
  "$OUTPUT_DIR/urls/katana.txt" \
  > "$OUTPUT_DIR/urls/auth-candidates.txt"

grep -Ei '\.js([?#].*)?$' "$OUTPUT_DIR/urls/katana.txt" \
  > "$OUTPUT_DIR/urls/javascript.txt"

アーカイブの情報源を追加する前に、現在のルートをマッピングします。過去の URL は探索には役立ちますが、エンドポイントが現在も到達可能であることの証明にはなりません。

5. API と ID 境界をマッピングする

各アプリケーションについて、以下を記録します。

• API のベース URL、説明、バージョン、操作、およびオブジェクト識別子。
• 匿名ユーザー、ユーザー、テナント、マネージャー、管理者の各境界。
• ログイン、ログアウト、トークン更新、パスワードリセット、MFA、OAuth、SAML の各フロー。
• Cookie、トークン、CORS、CSRF、および WebSocket の動作。
• 状態を変更するメソッドと、テスト用として承認された合成オブジェクト。

ユーザー間またはテナント間のアクセスに関する主張を検証するには、少なくとも2つの承認済み ID が必要です。

6. 焦点を絞ったスキルを選択する

attack-patterns-reference を使って観察結果を分類し、現在の証拠によって裏付けられるスキルだけを開きます。よくある調査先は次のとおりです。

観察結果	次に使うスキル
JavaScript バンドルまたはソースマップ	js-secrets-extraction、source-leak-hunt
REST オブジェクトと識別子	hunt-api-misconfig、hunt-idor
GraphQL エンドポイント	hunt-graphql
OAuth または SAML フロー	hunt-oauth、hunt-saml
WordPress の攻撃対象領域	hunt-wordpress、wordpress-plugin-hunt
公開されたサービスポート	port-service-discovery
複数ステップの候補パス	cross-attack-chains

7. 一度に1つの仮説を検証する

プローブを実行する前に、仮説を記述します。

Expected: user A cannot read user B's synthetic object.
Test: repeat the same object request with both approved sessions.
Positive evidence: user A receives user B's object and its non-public fields.
Negative control: an unknown object returns the documented not-found response.
Stop condition: any access to non-synthetic or out-of-scope data.

報告前に triage-validation を使ってください。ステータスコード、スキャナーのラベル、バージョン文字列、または一見制限が緩そうなヘッダーだけでは、十分な根拠になりません。

8. 証拠を保全する

重要な結果ごとに、以下を保持します。

• 対象、ID、UTC タイムスタンプ、およびスコープのコンテキスト。
• サニタイズ済みのリクエストとレスポンス。
• 期待された動作と観察された動作。
• ネガティブコントロール。
• 副作用、クリーンアップ、およびテストの制限。
• ツール名と関連するバージョン。

テスト中は evidence-hygiene を、検証後は report-writing を使ってください。

落とし穴

• あらゆるパスを受け付けるアプリケーションは、存在しない機密性の高いパスにも 200 を返します。
• CDN の IP アドレスやヘッダーだけでは、オリジンやアプリケーションのバージョンを特定できません。
• アーカイブされたエンドポイントは、応答しない、リダイレクトされる、または別の用途に再割り当てされている場合があります。
• 公開クライアント識別子が自動的に秘密情報になるわけではありません。
• 広範なクロールは、サードパーティや除外対象のドメインにまで及ぶ可能性があります。
• ページネーションにより、範囲を限定した検証が不必要なデータ収集に変わる可能性があります。
• 状態を変更する検証には、コマンド実行の直前に明示的な許可が必要であり、合成レコードを使用する必要があります。

検証

• すべての稼働中の資産は、許可されたスコープのエントリと発見元までたどれる必要があります。
• 稼働中のサービスには、正規化された URL と DNS のコンテキストが必要です。
• アプリケーションマップには、ルート、API、認証、ID のロールを含める必要があります。
• 採用されたすべての検出結果には、意味的な証拠とネガティブコントロールを含める必要があります。
• 攻撃経路の候補では、未検証の手順に「推定」または「未テスト」のラベルを付けてください。
• 証拠はサニタイズされ、再現可能で、OUTPUT_DIR 配下に保存されている必要があります。