海外で報告された日本を狙う3つのAI活用攻撃を整理し、CVEや製品バージョンが明らかでない状況でも、Criminal IP IT資産検索で外部に公開されたVPN機器、WebLogic、AIゲートウェイを点検する方法を紹介します。
2026年秋、日本国内では企業や団体のWebシステムからの情報漏えいの公表が相次ぎました。こうした中、攻撃にAIが使われているのではないかという指摘も増え、複数のセキュリティベンダーが攻撃インフラの調査結果を公表しています。
2026年10月27日、海外のセキュリティメディアThe Hacker Newsは、セキュリティ研究者が日本の組織を主な標的とした3つの攻撃インフラを分析した結果を報じました。このうち1件では、オープンソースのペネトレーションテストツールCyberStrikeAIが悪用され、44体のAIエージェントが偵察からデータの持ち出し、レポート作成までを分担していたことが確認されています。
一方で、この報告には攻撃に悪用されたCVE番号や、標的となった製品のバージョンは記載されていません。IOCも捜査への影響を考慮して公開されていません。そのため、「自社の機器が該当するか」をバージョン情報から判断することはできません。
しかし報告では、Case AとCで外部に公開された管理画面やVPN機器、設定不備のあるシステムなどが侵入の起点として確認されました。また、Case BではAI関連システムも攻撃対象に含まれていました。本記事では、3つのケースで狙われた「入口」を種類ごとに整理し、Criminal IP IT資産検索を活用して、日本国内でこれらの資産がどのように外部へ公開されているかを確認する方法を紹介します。
AIは攻撃の何を変え、何を変えなかったのか
研究者らは、攻撃者が公開ディレクトリに残したツール、スクリプト、標的リスト、ログ、コマンド履歴を基に、3つの攻撃インフラを分析しました。3件はいずれも2026年に活動しており、作業言語は簡体字中国語でしたが、同一の攻撃者であるかどうかは確認されていません。
また、国内のセキュリティ企業などが報告したARTEX関連のインフラとは別のものです。
3つのケースの最も大きな違いは、攻撃のどこまでをAIが担っていたかという点です。
| 項目 | Case A | Case B | Case C |
|---|---|---|---|
| AIの関与範囲 | CyberStrikeAIによる攻撃全体の自律実行 | 人間が主導し、計画とツール開発でLLMを活用 | ツールやスクリプトの開発に限定（高確度の推定） |
| 活動期間 | 2026年10月（短期集中） | 2026年8〜9月（約24日間） | 2026年1〜10月（長期・並行） |
| 主な標的 | 中小企業・地方公共団体の古いWebシステム | 古いWebシステム、外部公開されたAI／GPU関連システム | VPN機器（Cisco SD-WAN、Citrix NetScaler、F5 BIG-IP、Yamaha RTX1210）、WebLogic |
| 試行の規模 | 少なくとも19組織（うち日本16組織以上） | 日本のIPアドレス6,000件以上をスキャン | WebLogic候補1,300件以上、VPNの入口35件以上 |
| 深い侵害の痕跡 | ごく一部 | 1〜2社で大規模なデータ窃取 | 一部（VPN接続の成功は多数） |
Case Aでは、44体のエージェントが役割を分担し、日本語の入力フォームや偽のログイン画面まで自動で生成していました。また、多数の標的に並行してアクセスしながら、1組織あたりの通信を抑えて検知を回避していたことも確認されています。
Case Bでは、攻撃者が「正規の診断業務」を装ってLLMに攻撃計画を作成させ、安全対策を回避していた記録が見つかりました。さらに、AIワークフローシステム、LLM前処理システム、推論サービスが標的リストに含まれており、他者のAIサービスへのアクセスを乗っ取って再利用する仕組みも確認されています。
Case Cでは、攻撃者がツールやスクリプトの開発にAIを使った可能性が高いと研究者らは評価しています。ただし、プロンプトやAPIキーなど、AIの使用を直接示す証拠は確認されていません。攻撃者は自動化と証拠管理の手順を確立しており、熟練した運用者だったと見られます。
AIによって変わったもの、変わらなかったもの
報告では、3つのケースを踏まえてAIの影響を次のように整理しています。
| 区分 | 内容 |
|---|---|
| AIによって変わったもの | 並行して扱える標的の数、試行の速さ、標的国の言語への適応、記録とレポート作成の自動化 |
| AIによって変わらなかったもの | 悪用される弱点の種類、入口の性質（外部公開された古いシステムや初期設定） |
Case Aで最も深い侵入が確認された事例も、起点は認証なしで外部に公開されていた古いWebシステムの管理画面でした。新しい脆弱性は使われていません。研究者らはこの状況を、AIが攻撃者の人手を増やしても、作業は依然として「鍵のかかっていないドア」を探すことだと表現しています。
つまり、CVEが明らかでないことは、点検を先送りする理由にはなりません。攻撃者がAIで数千の候補を一度に試せる以上、守る側も「どの資産が外から見えているか」を先に把握しておく必要があります。
国内で相次ぐAI関与の攻撃に関する発表
今回の報告は、国内で続く一連の発表の流れの中に位置付けられます。2026年10月以降に公表された主な内容は以下のとおりです。
| 公表日 | 発表元 | 主な内容 |
|---|---|---|
| 10月27日 | The Hacker News | セキュリティ研究者による3つの攻撃インフラ（CyberStrikeAIなど）の分析を報道 |
| 10月19日 | 国内セキュリティ企業 | 攻撃元インフラでAIペネトレーションテストツール「ARTEX」の使用を確認。約20社が標的となり、うち8社が9〜10月に情報漏えいを公表 |
| 10月9日 | 国家サイバー統括室 | 不正アクセスによる情報漏えい事案を受けて、企業へ注意喚起 |
| 10月8日 | JPCERT/CC | 国内組織における一連の不正アクセスについて注意喚起 |
ここで注目すべき点は、ARTEXとCyberStrikeAIが別のツールであり、それぞれ別の攻撃インフラで確認されていることです。日本を標的とするAI関与の攻撃インフラが、複数並行して稼働していると考えられます。
また、日本を狙った攻撃ではありませんが、2026年10月21日にはLiteLLMのリリースパイプラインが乗っ取られ、悪意のあるlitellm==1.107.0がPyPIなどで配布されました。LiteLLMによると、起点は5月に公開リポジトリへ誤ってコミットされ、その後も失効されなかったAgent Platformのマスターキーでした。Case BでAI関連システムが標的になっていたこととあわせて、AIゲートウェイやAIエージェント実行環境が攻撃者にとって価値の高い資産になっていることを示す事例です。
入口①：外部に公開されたVPN・エッジ機器
ここからは、3つのケースで狙われた入口を種類ごとに確認します。以下の検索件数は、2026年11月2〜3日に取得した画面を基準としています。各検索条件に一致した結果であり、侵害された資産や脆弱な資産の数を意味するものではありません。
Case Cの攻撃者は、2026年に少なくとも6つのキャンペーンを並行して進め、VPN機器を機会的に狙っていました。報告によると、Cisco SD-WAN、Citrix NetScaler、F5 BIG-IPに対しては公開済みの脆弱性や管理機能の悪用が試みられ、Yamaha RTX1210に対しては設定ファイル内の認証情報が使われました。いずれもリモートアクセスの入口であり、突破されると内部ネットワークへ直接つながる点が共通しています。
Cisco：SD-WANとASAのログイン画面を確認
報告で名前が挙がっているのはCisco SD-WANです。ここでは、Ciscoのリモートアクセスで広く使われているASA（AnyConnect／WebVPN）もあわせて確認します。/+CSCOE+/logon.htmlは、ASAのWebVPNログインページで使われるパスです。
Criminal IP検索クエリ: country: JP “/+CSCOE+/logon.html”
検索結果では、合計2,740件が確認されました。ポート別では443番（HTTPS）が2,713件と大半を占め、80番が18件、8443番が3件と続きます。個別の結果ではCisco WebVPNとして識別された資産が多く、HTTPレスポンスにはwebvpn、webvpnc、webvpn_portalといったWebVPN特有のCookieが含まれていました。また、「SSL VPN」「VPN」「Hosting」「Cloud Service」のタグが付与された資産も確認されました。
SSL証明書では、発行者がIdenTrust、組織名がCisco Systems Inc.、コモンネームがvpn.sse.cisco[.]comのサブドメインとなっている例が見られました。これは、Ciscoのクラウド型セキュリティサービスが提供するVPN接続点である可能性があり、組織が自社で運用するASAとは管理主体が異なります。検索結果を自社資産と照合する際は、証明書のコモンネームやIPアドレスの所有者を確認し、自社で運用している機器とクラウドサービスの接続点を区別して点検対象を整理する必要があります。
Citrix NetScaler：旧名称と新名称の両方で検索
NetScalerは、Citrix ADCやCitrix Gatewayなど名称が変遷してきた製品です。運用中の機器によってページタイトルが異なるため、新旧両方の名称で検索すると見落としを減らせます。
Criminal IP検索クエリ: title: NetScaler Gateway country: JP
Criminal IP検索クエリ: title: Citrix Gateway country: JP
検索結果では、NetScaler Gatewayが合計49件、旧名称のCitrix Gatewayが合計77件確認されました。新しい名称よりも旧名称のタイトルを表示している資産のほうが多いという結果です。
Citrix Gatewayの結果は大半が443番ポートで公開されており、ASネームも国内の通信事業者が上位を占めていました。個別の結果では、国内企業の組織名やドメインが入ったSSL証明書が多く、企業が自社回線で運用しているリモートアクセスの入口であることがうかがえます。ページタイトルはファームウェアのバージョンやログイン画面のテーマによって変わるため、旧名称であることだけで脆弱とは判断できません。
また、ログインページのLast-Modifiedヘッダーが2022年3月のままになっている例もありました。この値も更新状況を直接示すものではありませんが、旧名称のタイトルが表示されている自社の機器は、ファームウェアのバージョンとサポート状況を優先して確認する必要があります。
一方、NetScaler Gatewayの結果は443番ポートが半数以下で、残りは多様な非標準ポートに分散していました。この中には、数百のポートが同時に開放され、インバウンドのリスクがCriticalと判定されたクラウド上の資産も含まれています。こうした資産は、実際の業務用ゲートウェイではなく、攻撃者の動きを観測するためのハニーポットなどである可能性もあります。検索結果を点検に活用する際は、証明書の組織名、開放ポートの数、ホスティング事業者を確認し、自社が運用する実機を見分けたうえで点検対象を整理することが重要です。
Yamaha：脆弱性ではなく「認証情報」が狙われたルーター
YamahaのRTXシリーズは、日本の中小企業や支店で広く使われているルーターです。研究者らは、Case Cで狙われたRTX1210の台数から、攻撃者が日本国内の導入状況をよく把握していたと分析しています。
Criminal IP検索クエリ: product: YAMAHA country: JP
検索結果では、合計25,575件が確認されました。すべてが日本国内の資産で、ポートは1723番（PPTP）、サービスはpptpと表示されています。PPTPは、拠点間接続やリモートアクセスに使われるVPNプロトコルです。個別の結果では、PPTPの応答に含まれるベンダー名（YAMAHA Corporation）とファームウェアの識別値から、Yamahaのルーターとして識別されていました。同じIPアドレスで、IPsecのネゴシエーションに使われる500番ポートや、8080番（HTTP）、7547番ポートが同時に開いている例も見られました。
ASネームは、国内の法人向け・個人向け回線に幅広く分布しており、中小企業の本社や支店、店舗などに設置されたルーターがVPNの入口として外部に公開されている状況がうかがえます。
なお、この件数はPPTPの応答からYamaha製と識別できた資産に限られます。PPTPを使用していない機器やWeb管理画面だけが公開されている機器は含まれないため、外部に公開されているYamahaルーターの実数はこれより多い可能性があります。
このケースで重要なのは、攻撃に製品の脆弱性が使われていない点です。ファームウェアを最新に保っていても、設定ファイルが流出していたり、同じ認証情報を複数拠点で使い回していたりすれば、正規の手順で接続されてしまいます。特にPPTPは、ユーザー名とパスワードによる認証で接続する仕組みであり、認証情報が漏れれば外部から正規の利用者として接続できてしまいます。また、PPTPは古いプロトコルで、現在はより安全なIPsecやIKEv2などへの移行が推奨されています。PPTPを使っている機器は、利用を続ける必要があるかを見直したうえで、設定ファイルの保管場所、VPNアカウントの認証情報、管理画面の外部公開をあわせて確認する必要があります。
入口②：インターネットから到達できる業務ミドルウェア
Oracle WebLogic Serverは、Java／Jakarta EEアプリケーションの開発、デプロイ、実行に使われるミドルウェアです。業務システムを支える製品として長く使われているため、更新が後回しにされた古い環境が残りやすい製品でもあります。
Case Cの攻撃者は、少なくとも1,300件のWebLogicサーバーを候補としてリスト化していました。このリストには日本と韓国だけでなく、英国、フランス、イタリア、カタール、コロンビアの組織も含まれていました。研究者らは、これらの多くは広範なスキャンで収集されたものであり、リストに載っていることが侵害を意味するわけではないとしています。ただし、攻撃者にとってリストに載る条件は「外部から見えていること」である点に変わりはありません。
タイトルからWebLogicを特定
WebLogicは、ログインページやエラーページのタイトルに製品名が表示される場合があります。タイトル条件で検索すると、管理コンソールなどが外部から見えている資産を確認できます。
検索クエリ: title: WebLogic country: JP
検索結果では、日本国内で合計4件が確認されました。国の条件を外したグローバル検索では214件で、中国、韓国、米国が上位を占めており、タイトルから識別できる国内のWebLogicは多くありません。ただし、タイトル検索で見つかるのは初期画面などが残っている一部の資産に限られます。
また、日本国内の4件のうち、実際のWebLogic Serverと見られるのは1件でした。残りは数十のポートが同時に開いていたり、WebLogicとは異なるサーバー情報を返していたりする資産で、ハニーポットなどWebLogicを装った応答である可能性があります。実機と見られる1件は国内のISP回線上で稼働しており、IPアドレスに接続すると、WebLogic Server 14.1.1の初期画面がそのまま表示されました。
この画面は、WebLogicをインストールした直後に表示されるサンプルのトップページです。右上には管理コンソールを起動するボタンが表示されており、外部から管理コンソールへの導線がそのまま見える状態でした。初期画面が残っていることは、インストール後にサンプルアプリケーションの削除や公開範囲の見直しといった作業が行われていない可能性を示しています。
管理コンソールが外部から到達できる状態は、脆弱性の有無にかかわらず優先して見直すべき対象です。業務上WebLogicを外部に公開する必要がある場合でも、管理用のパスやポートは社内ネットワークやVPN経由に限定することが推奨されます。
入口③：攻撃対象として浮上したAIゲートウェイと推論サービス
3つのケースのうちCase Bでは、AI関連システムも攻撃対象の一つとして挙げられていました。攻撃者の標的リストには、AIワークフローシステム、LLM前処理システム、推論サービスが含まれていました。また、他者のAIサービスへのアクセスを乗っ取り、複数のサービスを組み合わせて利用するための仕組みも確認されています。研究者らは、その目的を大量の推論能力を低コストで入手することだと推定しています。
AIゲートウェイやLLMプロキシには、複数のAIサービスプロバイダーのAPIキーがまとめて登録されていることが多くあります。そのため、1つの管理画面やマスターキーが突破されるだけで、次のような被害につながる可能性があります。
- 不正な推論利用による費用の発生： 正規の所有者が利用料を負担したまま、攻撃者がAIを利用
- 攻撃インフラとしての悪用： 盗まれた推論能力が、別の組織に対する攻撃の自動化に使われる
- 連鎖的な認証情報の流出： LiteLLMの事例のように、AI関連システムが保持する開発者のトークンから、ソースコードやリリースパイプラインへ侵害が拡大
Criminal IPでは以前、外部に露出したAI APIトークンの追跡の記事で、Webページや.envファイルを通じたAPIキーの露出を取り上げました。今回は、キーを保持するゲートウェイ自体が日本国内でどのように外部公開されているかを確認します。
LiteLLMの外部公開状況
LiteLLMは、100以上のLLMプロバイダーをOpenAI互換の1つのAPIで扱えるオープンソースのAIゲートウェイです。チーム単位のキー管理や利用料の集計機能を備えており、組織内のAI利用システムとして導入されるケースが増えています。
検索クエリ: title: LiteLLM country: JP
検索結果では、日本国内で合計2,779件が確認されました。ただし、このうち2,749件がAmazon（AWS）上の資産で、個別の結果には数十のポートが同時に開放され、インバウンドのリスクがCriticalと判定された資産が多く含まれていました。WebLogicと同様に、LiteLLMを装ったハニーポットなどの応答が多数含まれている可能性があるため、この件数をそのまま実際の公開数と見なすことはできません。
そこで、LiteLLMプロキシの既定ポートである4000番に絞り込みました。
検索結果では、合計10件が確認され、いずれもLiteLLMのAPIドキュメント（Swagger UI）を閲覧できる状態でした。このうちクラウド上の1件では、画面上部にバージョン（1.98.0）が表示され、管理パネル（/ui）へのリンクも確認できました。Swagger UIに表示される鍵のアイコンは、API定義上の認証設定を確認する手掛かりになりますが、実際に認証が適用されているかまでは判断できません。WebLogicの初期画面と同様、管理画面へのリンクやAPI構成の一部がログイン前に表示される例です。国内の教育機関のネットワーク上で稼働するLiteLLMでも、APIドキュメントを閲覧できました。
LiteLLMの管理画面が外部から到達できる場合、マスターキーの総当たりなどにつながるおそれがあります。管理UIやAPIドキュメントへのアクセスは社内ネットワークに限定し、AI関連システムもWebサーバーやVPN機器と同様に資産管理の対象に含める必要があります。
CVE情報がないときの点検の進め方
通常の脆弱性対応では、CVEと影響バージョンを起点に対象資産を絞り込みます。しかし今回のように攻撃の入口が「露出」と「設定」である場合、起点を資産側に置き換える必要があります。報告で示された対策の優先事項を基に、Criminal IPを活用した点検の観点を整理すると次のとおりです。
| 点検の観点 | 根拠となったケース | Criminal IPでの確認方法 |
|---|---|---|
| 外部公開されたWebシステムの棚卸しと、古いシステムの更新・隔離 | A、B、C | 組織のIPアドレス帯やドメインで検索し、意図しない公開資産を抽出 |
| 初期認証情報と管理画面の外部公開 | A | title: フィルターで管理画面やログインページのタイトルを検索 |
| VPN・エッジ機器の設定管理と認証情報の使い回し | C | product: やtitle: でVPN機器を特定し、内部の機器台帳と照合 |
| 社内AIサービス（推論、ワークフロー、GPU環境）の外部公開 | B | LiteLLMやAIゲートウェイのタイトル、ポートで検索 |
| 低頻度・分散型の試行を前提とした監視 | A | 個別IPレポートで不審な挙動の履歴やリスクレベルを確認 |
これらの観点を、実際の作業手順に落とし込むと次の流れになります。
- 外部から見える資産を洗い出す: 本記事で紹介したクエリに、組織のIPアドレス帯やドメインの条件を加えて検索し、外部から識別できる資産を一覧化します。検索結果は内部の資産台帳と照合し、台帳にない資産や担当者が不明な資産を特定します。
- 管理画面と認証の入口を優先する: 抽出した資産のうち、管理画面、VPNのログインページ、AIゲートウェイの管理UIが外部から到達できるものを優先して見直します。業務上の必要がない場合は、社内ネットワークやVPN経由に限定します。
- 認証情報を棚卸しする: 初期パスワードのまま運用されている機器、複数拠点で共通の認証情報、退職者や委託先のアカウントが残っていないかを確認します。設定ファイルが外部に持ち出された可能性がある場合は、含まれていた認証情報をすべて変更します。
- APIキーは削除だけでなく失効させる: AIゲートウェイのマスターキーやプロバイダーのAPIキーが露出した可能性がある場合は、公開箇所を削除するだけでなく、必ず失効させて再発行します。LiteLLMの事例では、コミット履歴から削除されたキーが失効されないまま、約5か月後に悪用されました。
- 個別IPレポートで複合的なリスクを確認する: 優先度の高い資産は、Criminal IPの個別IPレポートで開放ポート、サービスバナー、マッピングされた脆弱性、リスクレベルを確認します。同じIP上でSSHやデータベースなど複数のサービスが公開されている場合は、単一のサービスにとどまらない攻撃対象領域として評価します。
- 定期的に再確認する: 設定変更やテスト環境の放置によって、一度閉じた資産が再び公開されることがあります。点検は一度で終わらせず、定期的に同じクエリで状態を確認します。
結論
今回報告された3つの攻撃インフラでは、外部に公開された古いシステムやVPN機器、初期設定のまま運用されている資産などが侵入の起点として確認されました。また、Case BではAI関連システムも攻撃対象に含まれていました。44体のAIエージェントが動いていたCase Aでさえ、最も深い侵入の起点は認証なしの管理画面でした。AIが変えたのは攻撃の規模と速度であり、攻撃者が探している弱点の種類ではありません。
今回の報告では、攻撃に悪用されたCVEや製品のバージョンは明らかになっていません。しかし、それは自社が無関係であることを意味しません。攻撃者の標的リストに載る条件は、まず外部から見えていることです。CVEの公開を待ってから対応を始めるのではなく、外部に公開されている資産を先に把握しておくことが、AIによって高速化した攻撃への現実的な備えとなります。
Criminal IP IT資産検索は、VPN機器、業務ミドルウェア、AIゲートウェイなど、外部から識別できる資産を製品情報やページタイトルを基に把握する際に活用できます。検索結果を内部の資産台帳と照合し、個別IPレポートで開放ポートやリスクレベルを確認することで、優先して見直すべき資産を整理し、点検の見落としを減らすことができます。
なお、関連して 外部に露出したAI APIトークンの追跡：インターネットに公開されたOpenAIとAnthropicのAPIキー の記事もご参考ください。
Criminal IP（criminalip.io/ja/register）に登録すると、すぐに脆弱資産の検知を開始できます。さらに、下記ボタンからデモをご依頼いただくことで、エンタープライズ環境において外部に露出した資産を対象としたCriminal IP の脅威インテリジェンス（TI）分析を直接ご確認いただけます。
本レポートは、サイバー脅威インテリジェンス検索エンジン Criminal IP のデータを基に作成されています。今すぐCriminal IP の無料アカウントを作成すれば、本レポートで引用された検索結果を直接確認したり、さらに膨大な脅威インテリジェンスを自由に検索することができます。
データソース: Criminal IP(https://www.criminalip.io/ja), The Hacker News(https://thehackernews.com/2026/10/cyberstrikeai-uses-44-ai-agents-to.html), LiteLLM(https://docs.litellm.ai/blog/security-incident-oct-21-2026-attack-chain), JPCERT/CC(https://www.jpcert.or.jp/at/2026/at260030.html), 国家サイバー統括室(https://www.cyber.go.jp/pdf/press/taiou.pdf)
