JPCERTがAIペンテスト基盤の悪用試行を追記｜IP一致だけに頼らない調査

JPCERT/CCは2026年10月23日、国内組織で相次ぐ不正アクセスに関する注意喚起を更新し、Cairn、CyberStrikeAI、ARTEXなど、AIを用いたペネトレーションテスト基盤を悪用した攻撃試行を「ケースE」として追記しました。主な標的はインターネットに公開されたWebアプリケーションで、既知の脆弱性の探索と悪用、環境設定ファイルやバックアップファイルの窃取の試行に加え、公開されたWSUSサーバーを狙う試行も確認されています。

これは「AIが自律的に国内の全事案を起こした」と断定する発表ではありません。JPCERT/CCは、寄せられた情報などを基に複数のケースを整理しており、すべての事案で同じ手法が使われたことを示すものではないと明記しています。本稿では、10月23日に新たに確定した範囲と既報を分け、Web運営者がログ調査、公開面の縮小、検知ルールの見直しをどう進めるかを整理します。確認日時は2026年10月24日です。

今回の新事実は複数基盤と観測用IPの明示

JPCERT/CCの更新版注意喚起は、AIペンテスト基盤としてCairn、CyberStrikeAI、ARTEXの名称を挙げ、攻撃試行に関連する不審な送信元IPアドレスを9件掲載しました。日付が示されたものは、早いもので9月23日、遅いものは10月20日まで観測されています。一部は開始日または終了日が明示されていません。

JPCERT/CC掲載の送信元	掲載された観測期間
31.59.92[.]155	10月4日〜10月20日
31.56.206[.]187	9月27日〜10月20日
38.244.50[.]120	期間記載なし
46.8.227[.]73	9月27日〜10月19日
64.44.24[.]195	10月15日〜
94.183.184[.]98	10月13日〜10月19日
94.183.184[.]254	10月3日〜10月20日
95.182.99[.]112	10月4日〜10月19日
176.65.144[.]71	9月23日〜10月17日

注意点があります。JPCERT/CCは、これらのアドレスが調査時点で正規利用されている可能性、記載期間外にも試行があり得ること、掲載外の送信元が存在し得ることを明記しています。したがって、一覧は過去ログを絞り込む手掛かりであり、永続的な遮断リストでも侵害の判定表でもありません。

既報のARTEX調査と何が違うのか

本サイトでは10月20日に、GMOサイバーセキュリティ byイエラエの調査を基にARTEXの使用確認で何が分かった？国内企業へのAI攻撃と防御の優先順位を公開しました。そこでは、特定の攻撃元インフラでARTEXの使用が確認された事実と、個々の被害企業の侵入原因を分けて説明しています。

今回の差分は、JPCERT/CCが複数のAIペンテスト基盤をケースEとして整理し、WebアプリケーションだけでなくWSUSの公開面も挙げ、調査に使える送信元と観測時期を追加した点です。一方で、ツール名が分かっても、どの脆弱性が使われたか、どの要求が成功したか、データが持ち出されたかは環境ごとに確認する必要があります。「AI攻撃」というラベルを原因調査の代わりにしてはいけません。

AI利用の確認が示すのは、探索や試行の速度、組み合わせ、反復が人手中心の運用より拡大し得ることです。新しい種類の脆弱性が自動的に生まれたことや、従来の防御がすべて無効になったことを意味しません。未修正の既知脆弱性、公開された管理機能、弱い認可、置き忘れた設定・バックアップといった既存の入口が、より継続的に試される前提へ運用を変える必要があります。

IP一致は入口であり結論ではない

最初に、掲載IPからのアクセスを、JPCERT/CCが示した期間だけでなく前後を広げて検索します。確認先はCDN、ロードバランサー、WAF、リバースプロキシ、Webサーバー、APIゲートウェイ、アプリケーション、認証基盤です。タイムゾーンと時刻同期を記録し、同じアクセスを層ごとに対応付けます。ログの保持期間が短い場合は、上書き前に対象データを別領域へ保全します。

一致があったら、次の五つを一つのイベント列として確認します。

1. 入口：ホスト名、URL、HTTPメソッド、クエリ、User-Agent、TLSフィンガープリントを確認する
2. 応答：200や302だけでなく、401、403、404、500の変化、応答サイズ、処理時間を見る
3. 後続操作：ログイン、パスワード再設定、管理API、ファイル取得、設定変更、アカウント作成へ続いたかを調べる
4. サーバー側：新規ファイル、プロセス、ジョブ、サービス、コンテナ、外向き通信、資格情報の利用を照合する
5. 影響：閲覧・変更されたデータ、付与された権限、持ち出しの可能性を別々に判定する

IP一致がなくても安全とは言えません。JPCERT/CCは別ケースでTor出口ノードやレジデンシャルプロキシ経由のアクセスも確認しており、同じ自動化基盤が別のアドレスから動く可能性があります。反対に、IPが一致しても、正規利用へ転用されたアドレスや、遮断された探索だけなら侵害とは限りません。署名は単独判定ではなく、経路、時刻、応答、後続操作との相関に使います。

自動探索を想定した検知へ変える

AIを用いるかどうかにかかわらず、自動探索は短時間に複数のパス、パラメーター、認証状態、HTTPメソッドを試せます。防御側は特定のUser-Agentや固定IPだけでなく、挙動のまとまりを検知します。存在しないパスへの連続アクセス、環境設定・バックアップ・管理用パスの列挙、同一主体による認証エラーと成功の近接、通常画面から呼ばれない管理API、レスポンス差を測るような入力変化が候補です。

レート制限は必要ですが、サイト全体へ一つの上限を置くだけでは不十分です。ログイン、パスワード再設定、検索、ファイル取得、管理操作、SMSやメール送信など、悪用時の影響が大きい機能へ個別の上限と監視を設定します。利用者、トークン、セッション、IP、ASN、地域など複数の軸を組み合わせ、共有回線の利用者を一括で締め出さないようにします。

管理APIの機能・対象・項目ごとの認可と拒否試験は、関連記事の国内の不正アクセス注意喚起を踏まえた管理APIの認可と点検手順で具体化しています。今回の更新では、そのテスト結果に加えて、拒否した試行が監視側へ届き、相関IDから前後の操作を追えるかも確認してください。

公開WSUSを例外扱いしない

今回、JPCERT/CCがインターネット公開されたWSUSへの攻撃試行を明記したことは重要です。Webサイト以外でもHTTPまたはHTTPSで応答する運用基盤は、外部から探索される公開資産です。資産台帳を「顧客向けWebサイト」だけで作ると、更新管理、CI/CD、BI、監視、バックアップ、開発用ダッシュボードなどが漏れます。

業務上インターネット公開が不要なら、公開を停止し、VPN、ゼロトラストアクセス、踏み台、許可された管理経路へ戻します。公開が必要な場合は、所有者、目的、対象利用者、認証方式、許可元、保守版、ログ保存、停止手順を記録します。CISAのInternet Exposure Reduction Guidanceも、既定パスワードの変更、更新、サポート終了製品の置換、監視された踏み台、通信監視、多要素認証、定期的な外部公開資産の評価を勧めています。

24時間で進める実施順序

1. 公開資産を確定：DNS、証明書、クラウド、CDN、ロードバランサー、NAT、委託先の一覧を照合し、管理・更新・BI・開発用途を含める
2. ログを保全：掲載IPと観測期間を起点に検索し、対象URLと前後の操作を失わない形で保存する
3. 不要公開を止める：機能停止、経路制限、認証付きプロキシなど、構成に適した方法で到達可能性を減らす
4. 既知脆弱性と設定を確認：稼働版、配布元、修正版、既定認証情報、バックアップや設定ファイルの露出を確認する
5. 相関検知を追加：単一IPではなく、列挙、応答差、認証変化、管理操作、外向き通信の連続でアラートを作る
6. 侵害時の作業へ移る：不審な成功応答、アカウント・設定変更、Webシェル、資格情報利用があれば、更新作業と証拠保全・封じ込めを分けて進める

侵害が疑われる場合、更新しただけで調査を終了しません。証拠保全、認証情報のローテーション、信頼できる媒体からの再構築は、更新しても侵害は消えない｜Webサーバーの証拠保全と再構築ランブックへつなげて実施してください。同記事は一般的な復旧手順であり、今回の送信元IPだけを対象にしたものではありません。

AI固有の名前より公開面と証拠を管理する

今回の更新から得るべき結論は、特定のAIツール名を遮断すれば終わるということではありません。正規のペネトレーションテスト基盤と悪用は同じ名前を持ち得ます。攻撃者は送信元、User-Agent、ツール、経路を変えられますが、外部から到達できる入口、サーバーが返した応答、認証・設定・ファイルの変更は自社側で記録できます。

まず公開面を減らし、残す入口には機能別の認証・認可・利用制限を置き、ログを一つの時系列へ結びます。掲載IPは過去調査の出発点、AI基盤の名称は脅威の変化を理解する材料として使い、侵害判断は自社の証拠で行うことが実務上の境界です。