シグネチャ検知が沈黙するとき — sec-watch 調査事例

環境: 年商約1,800億円規模のビューティー・コスメ企業。ウェブ・アプリケーション・データベースの各層にわたり数百台規模のサーバーを運用し、マネージドシグネチャルールグループを備えた WAF と大規模な社内セキュリティ監視体制をすでに持っていた。
課題: シグネチャ検知は、すでに知っているペイロードにしか反応しない。2026年11月6日、単一の外部送信元が83分間の偵察キャンペーンを実行した — OAuth エンドポイントの探索、外部コールバックサービスを使った SSRF の試行、実際に動作する XSS ペイロード、同一ミリ秒内での User-Agent 10種のローテーション、パスとクエリパラメータへのカナリア総当たり、そして最後に認証後エリア（/login、/dashboard）の探索まで。顧客の WAF のマネージドシグネチャルールグループ（SQLi・Common・PHP・Known Bad Inputs）は、そのどれにも反応しなかった。リクエストが止まったのは攻撃検知ではなく、IP 許可リストルールのおかげだった。試行を「見る」ことと、それが何で、成功したのか、何に触れたのかを「知る」ことは違う。
AI 自動範囲: GIIP sec-watch（Jev ベースの二次判定、WAF・CDN・データベース監査ログが対象）は同日の2回のスイープで、この環境の疑わしいイベント30件を表面化させた。続いて監視マシンが全判定を原本記録 — WAF ログ、CDN ログ、DB 監査ログ — と全文対照し、タイムライン全体を復元した。30件を根拠とともに4グループに分けた: 悪性キャンペーン21件（全件 WAF で遮断、オリジン未到達）、許可リストに載る正規クライアント経路から実在するコンテンツ ID に注入文字を入れた手動テスト7件（許可されてオリジン到達、200/301 応答、実施者は未確認 — 静かに流さず「要注意」として報告）、誤検知2件（社内 CMS の通常操作、監視ツール自身の IP リストの既知の誤登録 — それぞれ根拠とともに通常として整理）。レポートは調査範囲、攻撃パターン、攻撃が成功したか、被害対象を判定単位で確定し、確認済みの事実と推定を明示的に分け、具体的な後続提案（明示的な拒否リストへの追加、テストされたパラメータのサーバー側検証、誤登録 IP の除外）まで含んだ。
人による確認: 判断と変更は人が担った: 送信元を明示的な拒否リストに載せるか、正規クライアントにその経路での注入テストの経緯を問い合わせるか、サーバー側検証を入れるかは、根拠とともに顧客チームへ提案として渡した — レポートは確認済みの事実と提言で線を引き、本番のセキュリティポリシーを勝手に変えない。

成果

同じ日のうちに、顧客は30件すべてへの判定を得た: キャンペーンはオリジンに到達しておらず、データ抽出の証跡はなかった。誤検知2件は通常操作として終了した。そして、シグネチャ検知の後ろに何もない許可リスト経路という、唯一現実的なリスク経路が、検証すべきパラメータとともに明示された。検知がイベントを上げ、調査がそれを判断に変えた。

シグネチャ検知は沈黙していた。GIIP sec-watch が偵察キャンペーンを検知し、侵入が成功しなかったことまで証明した。

この事例で導入した GIIP サービス