pentest-outbound-interaction-oob-detection

アウトバウンド通信とOOB検出

目的

仮説の検証に、即時のインバンド応答ではなくコールバックの証拠が必要な場合は、このスキルをアウトバウンド通信とアウトオブバンド検証に使用します。

主なユースケース：

• SSRF のコールバック確認
• ブラインド XSS のビーコン
• ブラインド XXE
• Webhook 配信の検証
• DNS、HTTP、HTTPS のコールバック照合
• 非同期のサーバーサイド通信の証明
• リバースシェルに関連するエグレステスト。ただし目的はコールバックの検証であり、シェルの処理ではありません

検出内容をインバンドだけで完全に確認できる場合は、代わりにインバンド検証スキルを使用します。

運用ルール

• OOB 検証は、ペイロードの送信だけでなく証拠の収集として扱います。
• テストケースごとに一意の相関トークンを生成します。
• コントロールペイロードとテストペイロードは分けます。
• 検出を確認する前に、トークン、サブドメインまたはパス、タイムスタンプでイベントを照合します。
• セッション状態とコールバックログをディスクに保存します。
• 遅延した通信に備えて、リスナーを十分な時間稼働させます。
• 仮説を検証できる範囲で、必要最小限のプロトコルを使用します。
• バックグラウンドトラフィックや相関のないコールバックを根拠に、確認済みと判断してはいけません。
• コールバックペイロードに実際のシークレットを含めてはいけません。

有効化トリガー（該当）

リクエストまたは観測された動作に以下が含まれる場合、このスキルを使用します。

• ssrf callback
• blind xss
• webhook abuse
• oob
• dns interaction
• asynchronous callback
• xxe out of band
• blind xxe
• http callback
• https callback
• egress validation

引き継ぎ基準

• OOB コールバックを照合する前の XSS コンテキスト、ブラウザーシンク分析、ペイロード構築については、pentest-xss に引き継ぎます。
• パーサー、XXE、SSRF、リクエストの変更作業については、pentest-input-protocol-manipulation に引き継ぎます。
• 決定的なアウトバウンド動作が確認できた後に限り、pentest-exploit-execution-payload-control に引き継ぎます。

検証基準

以下をすべて満たした場合に限り、検出内容を確認済みとします。

1. ペイロード送信前に、テストごとに一意のトークンが生成されている。
2. テスト対象のペイロードに、想定されたコールバック識別子が埋め込まれている。
3. 許可されたテスト時間内に通信が観測されている。
4. 観測された通信が、トークン、パスまたはサブドメイン、タイムスタンプに一致している。
5. コントロールケースでは、同じシグナルを説明できない。

判定：

• confirmed：決定的な相関がある
• inconclusive：部分的なシグナルはあるが、相関が不十分
• not confirmed：一致する通信がない、またはコントロールにより主張が否定される

手順

1. ペイロードを送信する前に、テストごとに一意の相関識別子を生成します。
2. 遅延イベントに対応できるよう、コールバックリスナーのスコープと保持期間が十分であることを確認します。
3. 確認する前に、トークン、パス、時間枠でコールバックを照合します。
4. ノイズとなるバックグラウンドトラフィックと、テストに関連する通信を区別します。
5. 誤検出を減らすため、コントロールペイロードを使用します。
6. 確認済みのプリミティブは、相関を示す証拠一式とともにエクスプロイトまたはロジックスキルに渡します。

検証ゲート

• OOB 検証は、ペイロードの送信だけでなく、証拠を厳密に扱う手順として扱います。
• 監査可能性を確保するため、変更不可のコールバックログを保存します。
• 肯定コントロールと否定コントロールの両方の結果を含めます。
• 決定的な相関がある場合に限り、確認済みと判断します。
• 無関係なテストには新しいトークンを使用します。
• コールバックペイロードに実際のシークレットを含めないでください。

標準ワークフロー

1. 仮説と、想定されるアウトバウンド動作を定義します。
2. 検証に使える最小限のコールバック手段を選びます。
3. 評価の実行中に使用するリスナーセッションを1つ開始します。
4. プローブごとに一意のトークンを1つ生成します。
5. トークンを含むコールバックエンドポイントをペイロードに埋め込みます。
6. ペイロードを送信し、タイムスタンプと送信元のコンテキストを記録します。
7. 想定される時間枠内で、一致する通信を監視します。
8. 判定する前に、コントロールと比較します。
9. 確認済みのプリミティブは、証拠一式とともにエクスプロイトまたはロジック悪用のワークフローに渡します。

リスナーコンポーネント

DNS、HTTP、HTTPS のコールバック検証には、利用可能な場合、interactsh-client または同等の管理下にあるコールバックサービスを使用してください。

起動パターンの例：

RUN_DIR="/tmp/interactsh-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$RUN_DIR"

interactsh-client \
  -json \
  -o "$RUN_DIR/interactions.jsonl" \
  -sf "$RUN_DIR/session.txt" \
  -ps \
  -psf "$RUN_DIR/payloads.txt" \
  -pi 5 \
  >"$RUN_DIR/stdout.log" 2>&1 &

echo $! > "$RUN_DIR/interactsh.pid"
sleep 2
cat "$RUN_DIR/payloads.txt"

リスナーの取り扱いルール：

• 分離が必要な場合を除き、評価実行ごとにバックグラウンドリスナーを 1 つ起動してください。
• interactions.jsonl、セッション状態、生成したペイロードドメイン、標準出力ログを保存してください。
• 検証期間中はリスナーを稼働させ続けてください。

テストごとのトークン生成

各テストケースに対して、固有のトークンを 1 つ生成してください：

TEST_TOKEN="$(tr -dc 'a-z0-9' </dev/urandom | head -c 10)"
BASE_DOMAIN="$(head -n1 "$RUN_DIR/payloads.txt" | tr -d '\r\n')"
CALLBACK_FQDN="${TEST_TOKEN}.${BASE_DOMAIN}"

echo "$TEST_TOKEN $CALLBACK_FQDN $(date -Iseconds)" >> "$RUN_DIR/test_tokens.log"

printf '%s\n' "$CALLBACK_FQDN"

ルール：

• 無関係なテスト間でトークンを再利用しないでください。
• トークン、ペイロードの送信先、ソースベクター、タイムスタンプを記録してください。
• 有用な場合は、サブドメインベースの相関に加えて、パスベースの相関も使用してください。

プロトコルの選択

仮説に合ったプロトコルを選択してください：

• DNS：外向き通信の証明、リゾルバーの動作、手間の少ない SSRF または XXE の検証
• HTTP：Webhook の配信、SSRF、アプリケーションレイヤーでのコールバック検証
• HTTPS：対象が TLS のみの外向き通信を強制する可能性が高い場合

有用な範囲で最小限のプロトコルセットを使用してください。テストに必要な場合を除き、すべてのプロトコルを一斉に試さないでください。

リバースシェルに関連する外向き通信の確認

このスキルは、対象が 80 や 443 などの一般的な外向き通信経路で外部エンドポイントに到達できるかどうかを確認する目的に限り、リバースシェルに関連する検証に使用してください。

ルール：

• このスキルは、外向きの到達可能性とプロトコル動作の検証に使用し、シェルの取り扱いには使用しないでください。
• 後にシェルを実行できることが確認された場合は、エクスプロイト実行ワークフローに引き継いでください。

収集する証拠

各テストケースについて、以下を記録してください：

• 仮説
• ペイロードベクター
• 生成したトークン
• コールバックエンドポイント
• リクエストのタイムスタンプ
• 制御用ペイロード
• 観測したコールバックのタイムスタンプ
• 観測したプロトコル
• ソースコンテキスト
• 判定

出力スキーマ

以下を返してください：

• token、payload path or subdomain、timestamp、source context を含む相関テーブル
• 検証判定：confirmed、not confirmed、または inconclusive
• 確認済みの外向き通信動作のみに基づく、次の調査機会
• 別の担当者がテストを再実行できるだけの詳細を含む再現手順

ツールに関する注意事項

• interactsh-client または同等のリスナーがない場合は、その旨を明確に伝え、次回の実行に必要なツールを推奨し、OOB の主張を確定せずに中止してください。
• 決定的な相関を推測で置き換えないでください。
• コールバックに基づく主張を監査可能な状態に保つため、ログを保存してください。