はじめに

2026年秋、日本では企業や団体のWebシステムからの情報漏えいの公表が相次ぎました。「攻撃にAIが使われているのでは？」という話もよく聞くようになりましたよね。

そんな中、10月27日にThe Hacker Newsが、日本の組織を主な標的にした3つの攻撃インフラの分析結果を報じました。そのうち1件では、オープンソースのペネトレーションテストツールCyberStrikeAIが悪用され、44体のAIエージェントが偵察からデータの持ち出し、レポート作成までを分担していたそうです。

ただ、この報告には攻撃に使われたCVE番号や、狙われた製品のバージョンが書かれていません。IOCも非公開です。つまり、「うちの機器は対象？」をバージョンで判断することができません。

では様子見でいいのかというと、そうではありません。
報告を読むと、侵入の起点は新しい脆弱性ではなく、外部に露出している管理画面、VPN機器、設定不備のあるシステムでした。さらに、AI関連システムも攻撃対象に入っていました。

そこで今回は、攻撃者が狙った「入口」を種類ごとに整理し、 Criminal IP IT資産検索で、日本国内でどれくらい外から見えているのかを実際に確認してみました。

3つの攻撃インフラ、AIの使われ方はバラバラだった

研究者らは、攻撃者が公開ディレクトリに残したツールやスクリプト、標的リスト、ログ、コマンド履歴を分析しました。

3件とも2026年に活動しており、作業言語は簡体字中国語でしたが、同じ攻撃者かどうかは分かっていません。また、国内で報告されているARTEX関連のインフラとは別物です。

いちばんの違いは、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ワークフローシステムや推論サービスも標的リストに入っていました。
Case C： AIの使用は「可能性が高い」という評価にとどまります（プロンプトやAPIキーなどの直接的な証拠はなし）。攻撃者自身は、自動化と証拠管理の手順が整った熟練者だったようです。

AIで変わったこと・変わらなかったこと

報告では、AIの影響を次のように整理しています。

区分	内容
変わったこと	並行して扱える標的の数、試行の速さ、標的国の言語への適応、記録とレポートの自動化
変わらなかったこと	悪用される弱点の種類、入口の性質（外部公開された古いシステムや初期設定）

Case Aで最も深く侵入された事例も、起点は認証なしで公開されていた古いWebシステムの管理画面でした。

新しい脆弱性は使われていません。研究者らはこれを、AIで攻撃者の「人手」は増えたが、やっていることは相変わらず鍵のかかっていないドア探しだ、と表現しています。

つまり、CVEが分からないことは、点検を後回しにする理由になりません。攻撃者がAIで数千の候補を一気に試せるなら、守る側も「何が外から見えているか」を先に知っておく必要があります。

国内でも続く「AI×攻撃」の発表

今回の報道は単発のニュースではありません。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絡みの攻撃インフラが、複数同時に動いていると考えられます。

もう1つ押さえておきたいのが、10月21日のLiteLLMの事例です。日本を狙ったものではありませんが、リリースパイプラインが乗っ取られ、悪意あるlitellm==1.107.0がPyPIなどで配布されました。

起点は、5月に公開リポジトリへ誤ってコミットされ、失効されないまま残っていたマスターキーでした。

Case BでAI関連システムが狙われていたことと合わせると、AIゲートウェイやエージェントの実行環境が「おいしい標的」になっていることが分かります。

入口①：VPN・エッジ機器を探してみる

ここからは、実際にCriminal IPで検索していきます。

以下の件数は2026年11月2〜3日時点のものです。検索条件に一致した数であり、侵害された資産や脆弱な資産の数ではありません。また、確認は画面の閲覧にとどめ、ログインなどは行っていません。

Case Cの攻撃者は、少なくとも6つのキャンペーンを並行して進め、VPN機器を手当たり次第に狙っていました。Cisco SD-WAN、Citrix NetScaler、F5 BIG-IPでは公開済み脆弱性や管理機能の悪用が試みられ、Yamaha RTX1210では設定ファイル内の認証情報が使われました。

Cisco ASAのWebVPNログイン画面

報告で名前が挙がっているのはCisco SD-WANですが、ここではリモートアクセスでよく使われるASA（AnyConnect／WebVPN）のログイン画面を探してみます。/+CSCOE+/logon.htmlは、ASAのWebVPNログインページのパスです。

IT資産検索クエリ ▶ country: JP "/+CSCOE+/logon.html"

結果は2,740件。ポートは443番が2,713件とほぼすべてで、80番が18件、8443番が3件でした。レスポンスにはwebvpn、webvpnc、webvpn_portalといったWebVPN特有のCookieが含まれています。

面白かったのは証明書です。コモンネームがvpn.sse.cisco[.]comのサブドメインになっている例がありました。

これはCiscoのクラウド型サービスのVPN接続点である可能性があり、自社で運用しているASAとは管理する人が違います。

自社資産と照合するときは、証明書のCNやIPの持ち主を見て、自社機器とクラウドの接続点を分けるのがポイントです。

Citrix NetScaler：新旧2つの名前で検索

NetScalerは、Citrix ADC、Citrix Gatewayと名前が変わってきた製品です。機器によってページタイトルが違うので、両方で検索します。

IT資産検索クエリ ▶ title: "NetScaler Gateway" country: JP
IT資産検索クエリ ▶ title: "Citrix Gateway" country: JP

クエリ	件数	傾向
NetScaler Gateway（新名称）	54件	443番は半数以下。非標準ポートに分散し、クラウド上の資産が多い
Citrix Gateway（旧名称）	79件	ほとんどが443番。国内の通信事業者の回線が上位

旧名称のほうが多いという結果になりました。Citrix Gatewayの結果には国内企業名入りの証明書が多く、企業が自社回線で運用しているリモートアクセスの入口だと考えられます。

中には、ログインページのLast-Modifiedが2022年3月のままの例もありました。タイトルやLast-Modifiedだけで脆弱とは言えませんが、旧名称が表示されている自社機器は、ファームウェアとサポート状況を優先して確認しておきたいところです。

一方、NetScaler Gatewayの結果には、数百のポートが同時に開いていてCritical判定のクラウド資産も混ざっていました。これは実際のゲートウェイではなく、ハニーポットの可能性があります。

Yamaha：狙われたのは脆弱性ではなく「認証情報」

日本ならではの標的がYamahaのルーターです。RTXシリーズは中小企業や支店で広く使われており、研究者らは、狙われたRTX1210の台数から「攻撃者は日本の導入状況をよく知っていた」と分析しています。

IT資産検索クエリ ▶ product: YAMAHA country: JP

結果は25,575件。すべて国内で、ポートは1723番（PPTP） でした。PPTPの応答に含まれるベンダー名（YAMAHA Corporation）とファームウェアの識別値から、Yamahaのルーターと判定されています。

同じIPで500番（IPsec）や8080番、7547番が開いている例もありました。回線は国内の法人向け・個人向けに幅広く分布しており、本社や支店、店舗のルーターがVPNの入口として外に出ている様子がうかがえます。

なお、これはPPTPで識別できた分だけなので、実際に公開されているYamahaルーターはもっと多いはずです。

ここで大事なのは、攻撃に製品の脆弱性が使われていないことです。PPTPはユーザー名とパスワードで接続する仕組みなので、設定ファイルが流出したり、認証情報を拠点間で使い回したりしていれば、ファームウェアが最新でも普通にログインされてしまいます。

PPTP自体も古いプロトコルで、IPsecやIKEv2などへの移行が推奨されています。

入口②：WebLogicを探してみる

Oracle WebLogic Serverは、Java／Jakarta EEアプリケーションを動かすミドルウェアです。業務システムで長く使われているぶん、古い環境が残りやすい製品でもあります。

Case Cの攻撃者は、WebLogicの候補を1,300件以上リスト化していました。リストに載っていても侵害されたとは限りませんが、リストに載る条件は「外から見えていること」 です。

IT資産検索クエリ ▶ title: WebLogic country: JP

結果は4件と少なめでした。国の条件を外すと214件で、中国、韓国、米国が上位です。ただ、タイトル検索で見つかるのは初期画面などが残っている資産だけなので、実際にはもっとあると考えられます。

さらに4件を1つずつ見てみると、本物のWebLogicらしいのは1件だけでした。残りは数十のポートが開いていたり、WebLogicとは違うサーバー情報を返していたりと、ハニーポットっぽい資産です。

本物と見られる1件は国内ISPの回線上にあり、アクセスするとWebLogic Server 14.1.1の初期画面がそのまま表示されました。

インストール直後に出るサンプルのトップページで、右上には管理コンソールを起動するボタンまで見えています。

初期画面が残っているということは、サンプルの削除や公開範囲の見直しがされていない可能性があります。

管理コンソールが外から届く状態は、脆弱性の有無に関係なく見直したいポイントです。

入口③：AIゲートウェイ（LiteLLM）を探してみる

Case Bでは、AIワークフローシステム、LLM前処理システム、推論サービスが標的リストに入っていました。

他人のAIサービスへのアクセスを乗っ取って組み合わせる仕組みもあり、目的は大量の推論能力を安く手に入れることと推定されています。

AIゲートウェイやLLMプロキシには、複数のAIサービスのAPIキーがまとめて登録されていることが多く、1か所破られると被害が広がります。

費用の不正利用：利用料は正規の持ち主が払い、AIは攻撃者が使う
攻撃インフラ化：盗まれた推論能力が、別の組織への攻撃の自動化に使われる
認証情報の連鎖流出：LiteLLMの事例のように、AI関連システムが持つ開発者トークンからリポジトリやリリースパイプラインまで侵害が広がる

LiteLLMの公開状況

LiteLLMは、100以上のLLMをOpenAI互換の1つのAPIで扱えるオープンソースのAIゲートウェイです。

IT資産検索クエリ ▶ title: LiteLLM country: JP

結果は2,779件……と思いきや、そのうち2,749件がAWS上の資産で、数十のポートが開いたCritical判定の資産がずらりと並んでいました。WebLogicと同じく、ハニーポットなどが大量に含まれていると見られるので、この数字をそのまま「公開数」とは言えません。

そこで、LiteLLMプロキシの既定ポートである4000番に絞り込みました。

IT資産検索クエリ ▶ title: LiteLLM AND port: 4000 country: JP

結果は10件で、いずれもLiteLLMのAPIドキュメント（Swagger UI）を閲覧できる状態でした。そのうちクラウド上の1件では、画面上部にバージョン（1.98.0） が表示され、管理パネル（/ui）へのリンクも見えていました。

国内の教育機関のネットワーク上で動いているLiteLLMでも、同じくAPIドキュメントを閲覧できました。

Swagger UIの鍵アイコンは、API定義上の認証設定を知る手掛かりにはなりますが、実際に認証がかかっているかまでは分かりません。とはいえ、WebLogicの初期画面と同じく、管理画面へのリンクやAPI構成がログイン前に見えてしまっている例です。管理UIやAPIドキュメントへのアクセスは社内ネットワークに限定しておきましょう。

検索結果の「ノイズ」に注意：ハニーポットの見分け方

今回の調査では、NetScaler、WebLogic、LiteLLMのいずれでも、本物ではなさそうな資産が多く混ざっていました。

攻撃者の動きを観測するためのハニーポットなどと考えられます。検索結果を自社の点検に使うときは、次のような点をチェックすると見分けやすくなります。

チェック項目	怪しいサイン
開放ポートの数	数十〜数百のポートが同時に開いている
ホスティング	同じクラウド事業者に大量に集中している
証明書	IPの持ち主と関係のない組織名の証明書を返している
バナーと本文	サーバー名と本文の内容がかみ合わない
Last-Modified	製品が登場する前の日付になっている

逆に、自社の組織名やドメインが入った証明書で、必要なポートだけが開いている資産は、実機である可能性が高いと言えます。点検ではまずこちらを優先しましょう。

CVEがなくてもできる点検リスト

CVEを起点にできないときは、資産を起点に点検します。報告で示された対策の優先事項をもとに、すぐできることをまとめました。

外から見える資産を洗い出す：本記事のクエリに自社のIP帯やドメインの条件を足して検索し、資産台帳と照合する
管理画面とログインの入口を優先する：管理画面、VPNのログインページ、AIゲートウェイの管理UIが外から届くなら、社内ネットワークやVPN経由に限定する
認証情報を棚卸しする：初期パスワード、拠点間で共通の認証情報、退職者や委託先のアカウントが残っていないか確認する
APIキーは「消す」だけでなく「失効」させる：LiteLLMの事例では、履歴から消したのに失効しなかったキーが、約5か月後に悪用された
個別IPレポートで周辺も見る：同じIPでSSHやデータベースなどが開いていないか確認する
定期的に見直す：一度閉じた資産も、設定変更やテスト環境の放置でまた開くことがある

おわりに

44体のAIエージェントが動いていたCase Aでも、最も深い侵入の入口は認証なしの管理画面でした。AIが変えたのは攻撃の規模と速度で、攻撃者が探している弱点の種類ではありません。

今回の報告にはCVEもバージョンも書かれていませんが、それは「自社は関係ない」という意味ではありません。攻撃者のリストに載る条件は、まず外から見えていることです。

CVEが出るのを待つのではなく、自社の何が外から見えているかを先に把握しておくことが、AIで加速する攻撃への現実的な備えになります。

Criminal IPは無料アカウントでも検索できるので、まずは自社のドメインやIP帯で検索してみてください。

参考