mcpField
C
cross-wave-delta-analysis

cross-wave-delta-analysis

github.com/uphiagoセキュリティ1.3k44 回インストール8 週間前に更新
リポジトリ

cross-wave-delta-analysis について

cross-wave-delta-analysisは、同じ対象セットに対する複数回の偵察結果を比較するセキュリティ分析スキルです。発見事項を新規、回帰、継続、変更、再発に分類し、一貫した手法での再テストを重視します。

主な機能

  1. 01偵察ウェーブの比較
  2. 02新規・回帰した発見の特定
  3. 03継続中の問題と設定変更の追跡
  4. 04対策の再発を検出
  5. 05差分の再テストと誤分類の回避

活用シーン

  1. 01脆弱性が修正されたか確認する
  2. 02新たなポート、サブドメイン、エンドポイントを発見する
  3. 03報告前に発見事項の状態を再確認する

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/uphiago/recon-skills --skill cross-wave-delta-analysis

インストール後、Claude Code で/cross-wave-delta-analysisを入力して読み込まれたか確認します。

詳細

Cross-Wave Delta Analysis Skill

同一ターゲット群に対する複数回の調査ウェーブの結果を比較する手法です。新規の発見、リグレッション（以前はアクセス可能だったものがブロックされた状態）、継続中の脆弱性、時間経過による変化を検出します。7つの詳細調査対象に対する9回のウェーブから得られた知見をまとめたもので、見落とされていたCORSの発見、新たなポートの公開、インフラのドリフトが明らかになりました。

使用するタイミング

  • 同じターゲット群に対して調査を繰り返すとき（ウェーブNの後にウェーブN+1を実施）。
  • 前回のウェーブ以降に脆弱性が修正されたかどうかを確認したいとき。
  • 新しい攻撃対象面が現れたかどうか（新しいポート、新しいサブドメイン、新しいエンドポイント）を確認したいとき。
  • 詳細な調査ウェーブを完了した後、次のウェーブの前に差分レポートを作成するとき。
  • 報告前に、発見事項が現在も有効か（リグレッションしていないか）を確認するとき。

前提条件

  • ${OUTPUT_DIR:-./output}/baseline/ 以下に、以前の評価結果があること。
  • ${OUTPUT_DIR:-./output}/current/ 以下に、現在の評価結果があること。
  • ターゲットごとに構造化された発見事項があること（最低限、ポート、CORSの状態、WPユーザー、XMLRPCの状態、機密性の高いパス）。

実行方法

# Produce a delta report comparing WaveN to WaveN+1
# Read wave outputs, compare per-target, classify findings

クイックリファレンス

差分のカテゴリ
カテゴリラベル意味例
新規++以前のどのウェーブにも存在しなかった発見Port 3306 (MySQL) now OPEN
リグレッション--アクセス可能だったサービスが、現在はブロックされているXMLRPC 200 -> 405 (hardened)
継続中==すべてのウェーブを通じて変化していない脆弱性CORS still reflecting since wave6
変化~リグレッションではないが、設定が変化したWP users: 10 in wave7, 9 in wave9
再発->後に元に戻ったリグレッション（緩和策が削除された）XMLRPC 405 (W9) -> 200 active (W10)
再発 — 特別なカテゴリ

再発した発見事項とは、後に元の脆弱な状態へ戻ったリグレッションです。これは次のような場合に発生します。

  • WAFルールが一時的に適用された後、削除された（GoDaddy／Cloudflareの共有ホスティングでよくあります）。
  • プラグインのセキュリティアップデートがロールバックされた。
  • 強化策が適用されない状態でインフラが再デプロイされた。

再発は対応が必要なものとして扱ってください。セキュリティチームが状況を把握していないか、問題視していないことを意味します。保護が信頼できないため、これらのターゲットは優先度が高くなります。

ターゲットごとに比較する項目
項目確認方法差分の意味
XMLRPCの状態POST /xmlrpc.php のHTTPステータス200 -> 405 = リグレッション（強化済み）
CORSヘッダー/wp/v2/users のACAO + ACAC反射あり -> ヘッダーなし = リグレッション
WPユーザー/wp/v2/users の件数件数の変化 = 変化
開放ポートnmapまたはnaabuの出力新しいポート = 新規（攻撃対象面の拡大）
サブドメインsubfinderの出力新しいサブドメイン = 新規
機密性の高いパス.env、info.phpなどのHTTPステータス以前は200 -> 403 = リグレッション

手順

ステップ1 — 両方のウェーブのデータを収集する
WAVE_OLD="${OUTPUT_DIR:-./output}/baseline"
WAVE_NEW="${OUTPUT_DIR:-./output}/current"
echo "=== Comparing $WAVE_OLD vs $WAVE_NEW ==="
ステップ2 — ターゲットごとの差分テーブルを作成する

両方のウェーブに存在する各ターゲットについて、XMLRPCの状態、CORSヘッダー、開放ポート、WPユーザー、サブドメインを比較します。発見事項には、新規（前回のウェーブには存在しない）、リグレッション（以前は機能していたが現在はブロックされている）、継続中（変化なし）、または変化（異なるがブロックされてはいない）のラベルを付けます。

ステップ3 — 重大な差分を分類してフラグを付ける

重大な差分を示します。新しいポート3306（MySQL）、新しいCORS認証情報の反射、新しいWPインストールページ、admin／stagingのパターンを含む新しいサブドメインが対象です。

注意点

  • 誤ったリグレッション判定。 403は修正ではなく、レート制限の可能性があります。IPや待機時間を変えて3回再試行してください。
  • 誤った継続中の判定。 エンドポイントが200を返していても、根本的な脆弱性（例：multicall）は無効化されている可能性があります。
  • タイミングが重要です。 各ウェーブで同じ手法を使用しないと、差分に意味がなくなります。
  • 「記録されていない」と「存在しない」を混同しないでください。 発見事項は存在していたものの、単に見落とされていた可能性があります。

検証

  • すべての差分は、両方のウェーブの出力に対してまったく同じコマンドで再現できる必要があります。
  • NEW の検出結果はすぐに再テストしてください。一時的なものである可能性があります。
  • 3 回以上のウェーブで PERSISTENT となっている検出結果が最も信頼できます（セキュリティチームもパッチ適用の定期サイクルもありません）。

関連スキル

  • attack-patterns-reference — 検出結果をパターン ID（P-01〜P-25）に対応付けます
  • recon-playbook — ウェーブデータを生成する 4 フェーズのパイプライン
  • cross-attack-chains — NEW の検出結果を連鎖させ、重大な影響につなげます
  • cors-credential-wordpress — CORS の検出結果の分類を検証します
  • xmlrpc-exploitation — XMLRPC のリグレッション状況を検証します

コメント

Markdown 対応