インターネット上の公開資産を調査するCensysは2026年11月5日、AIを利用した侵入テストツール「ARTEX」の管理画面が公開されているホストを、11月上旬の時点で1,465件確認したと発表した。ARTEXは自然言語で与えられた目標を基に作業計画を立て、外部のAIモデルと既存のセキュリティツールを組み合わせて処理を進める仕組みで、正当なセキュリティ診断だけでなく、不正な侵入にも悪用される可能性がある。観測された1,465ホストのうち、同一構成とみられる2つの大きなグループを除くと約815件が残るが、これらがそれぞれ異なる攻撃者によって運用されているわけではない。一方、Check Point Researchによる別の調査では、ARTEXが追加指示なしで攻撃を継続した記録や、金銭的な利益を得られなかったにもかかわらず侵害が成立した事例が確認された。公開ホストの数と実際の攻撃活動を区別することで、AIを利用した自律的な攻撃の実態が見えてくる。

AD

ARTEXの公開ホストは1,465件、重複構成を除くと約815件

Censysが公表した調査結果によると、1,465件という数字は、ARTEXの管理画面に使われるページタイトルと、Webアプリケーションの構築に利用されるNext.jsの静的ファイルを手掛かりに検出したホスト数だ。このうち493ホストと157ホストは、それぞれ同一構成とみられるグループに属していた。両グループの計650ホストを除くと815件となり、Censysはこれらを異なる構成を持つ導入例とみている。ただし、構成が異なるからといって運用者も異なるとは限らず、815件を攻撃者数や攻撃組織数と解釈することはできない。

Censys自身も、確認されたARTEXのすべてが悪意を持って運用されているわけではないと明記している。また、インターネットから管理画面にアクセスできることと、認証なしで管理機能を操作できることは別の問題だ。今回の調査では管理画面の公開状況が確認されたものの、1,465件すべてが認証を回避して操作できる状態だったとは示されていない。公開されているホストの数、構成の種類、実際の攻撃活動、被害の発生状況は、それぞれ異なる指標として扱う必要がある。

この違いは、Check Point Researchが実施したARTEXの内部記録に関する調査と比較すると明確になる。同社は外部に公開されていた10件のデータベースを分析し、実際の指示内容やエージェントの動作を調べている。Censysの調査がインターネット上の公開状況を捉えたものであるのに対し、Check Point Researchの調査は内部に残された実行記録から具体的な攻撃活動を分析したものだ。両者の観測対象と、そこから判断できる範囲を整理すると次のようになる。

観測対象 観測数・規模 調査主体 判断できる範囲
ARTEXの管理画面が公開されているホスト 1,465ホスト（2026年11月上旬） Censys 検出条件に一致した公開ホスト数。攻撃者数や被害件数は示さない
同一構成の650ホストを除いた導入例 約815件 Censys 異なる構成とみられるホスト数。固有の運用者数とは限らない
内部記録を分析できた公開データベース 10件 Check Point Research 記録された作戦の動作や実行結果。ARTEX全体を代表する標本ではない
侵害の成立と暗号資産の獲得 個別の作戦記録から判断 Check Point Research データ流出などの侵害と、攻撃者が得た金銭的利益を区別して確認できる

このように、約815件という数字が示すのは、異なる構成とみられるARTEXの公開ホストが一定数存在するという事実までだ。それらが実際に攻撃に使われているかどうかや、どれだけの被害が発生したかは、別の証拠によって確認する必要がある。また、両社の調査は観測対象や集計方法が異なるため、数字を直接比較して攻撃活動の増減を判断することもできない。

公開ディレクトリから操作履歴やSSH関連ファイルも発見

Censysはさらに、ARTEXが稼働するホストのうち32件で、外部からファイルの一覧や内容を閲覧できる公開ディレクトリを確認した。これらのディレクトリには、侵入後の活動に利用されるツールや操作履歴が残されており、SSH関連のファイルも含まれていたという。単に管理画面が外部から見えるだけでなく、実際の運用環境に関係するファイルまで公開されていた点が重要だ。こうした情報は、攻撃に使用されたツールの構成や操作内容を分析する手掛かりになる一方、公開した運用者自身にとってもセキュリティ上のリスクとなる。

ただし、公開状態は固定されているわけではない。Censysの観測では、多くのディレクトリが数時間から数日で閉鎖されており、11月3日から5日にかけて10件が閉鎖された一方、新たに15件が別のホストで公開されていた。つまり、ある時点で確認された公開ディレクトリの一覧が、そのまま継続的な公開状況を表しているわけではない。公開と閉鎖が短期間で繰り返されるため、実態の把握には継続的な観測が必要となる。

CensysはARTEXのホスト上で動作するほかのサービスについても調査している。1,465ホストのうち155件（10.6%）では、別の脅威分類に該当するサービスが検出され、43件には大規模言語モデル（LLM）への接続を中継・再販するソフトウェアが存在した。ただし、同じホスト上で別のサービスが動作しているという事実だけで、ARTEXが悪意を持って使われているとは判断できない。また、複数のホストやサービスが同一の攻撃者によって運用されていることを示す証拠にもならない。

ARTEXの特徴は、独自のAIモデルを内蔵するのではなく、外部のモデルと既存のセキュリティツールを組み合わせて動作する点にある。自然言語で目標を与えると、AIが作業計画を立て、複数のエージェントがツールを実行し、その結果に応じて次の処理を進める。CERT-EUの解説によると、元のリポジトリが非公開になった後も派生版の存在が確認されている。この仕組みでは、AIが目標の解釈から実行結果の評価、次の操作の選択までをつなぐため、人間が個々の操作を細かく指示しなくても作業を繰り返せる。

AD

AIが追加指示なしで攻撃を継続、収益ゼロでも侵害は成立

Check Point Researchは、外部に公開されていた10件のARTEX関連データベースを分析し、実際の攻撃指示やエージェントの実行結果を調査した。同社の報告には、過去に観測されたシステムを含む累計2,557件と、調査時点で稼働・公開していた1,608件という数字も記されている。ただし、これらはCensysの調査とは観測時点や重複を除外する方法が異なるため、1,465件から1,608件へ増加したと解釈することはできない。両社の調査結果はそれぞれ独立した観測として扱う必要がある。

内部記録からは、ARTEXが人間の継続的な指示なしに攻撃を進めていた事例も確認された。暗号資産の獲得を目的としたある作戦では、最初に目標を与えられた後、エージェントが追加指示なしで作業を継続したという。この作戦では292件の標的が設定され、230件の指摘と40万791件のメッセージが記録されていた。ただし、230件という数字はツールが出力した指摘の数であり、実際に悪用可能と確認された脆弱性の数や、侵害された組織の数を示すものではない。

興味深いのは、これほど大量の処理を実行しても、攻撃者が金銭的な利益を得られなかったことだ。Check Point Researchによると、ARTEXのエージェントがAPIから返された成功応答を、暗号資産の送金が完了した証拠と誤認した事例があった。しかし、攻撃者のウォレット残高は0ドルで、実際の取引記録も確認されなかったという。システム上の処理が成功したという応答と、ブロックチェーン上で資金の移転が成立したことを区別できていなかったわけだ。

一方、金銭的な利益が得られなかったからといって、攻撃による被害もなかったわけではない。同社は、データベースからの情報流出やAmazon S3上のデータ書き換えなど、実際の侵害が成立した事例も報告している。これは、AIエージェントが自律的に作業を継続できること、システムへの侵入やデータ改変が成立すること、攻撃者が最終的に収益を得ることが、それぞれ異なる結果であることを示している。攻撃者が金銭を獲得できなかった作戦でも、被害を受けた側には情報漏えいやデータの完全性が損なわれるリスクが残る。

ただし、こうした自律実行の記録は、今回分析された特定の作戦に関するものだ。ARTEXを使ったすべての作戦が同じ程度の自律性を持ち、追加指示なしで侵入に成功することを示したわけではない。AIエージェントの実際の能力を評価するには、実行回数や生成されたメッセージ数だけでなく、個々の操作が成功したかどうかを分けて確認する必要がある。

防御の焦点は公開管理画面と認証・権限の管理

CERT-EUは2026年11月5日の解説で、ARTEXが許可された作業範囲を守ることや、破壊的な操作を避けることは、設定された規則と利用するAIモデルの判断に依存していると指摘した。同機関によると、こうした制約を技術的に強制する仕組みは備わっていない。自然言語で目標を指定できる利便性と、AIエージェントの操作を許可された範囲に確実に制限できることは、別の問題だ。そのため、AIモデルへの指示だけに頼らず、実際のシステム側でアクセスや操作の権限を制限することが重要となる。

CERT-EUは対策として、インターネットからアクセスできる資産の削減、管理画面の隔離、修正プログラムの適用、多要素認証の導入、アクセス権限の監視を推奨している。また、一見すると軽微な設定ミスであっても、修正対象から除外しないよう求めている。AIエージェントが複数のツールを連続して操作する環境では、個々の設定不備が次の操作につながる可能性があるためだ。管理画面が公開されている場合は、認証の有無だけでなく、認証後に利用できる機能やアクセス可能なデータの範囲も確認する必要がある。

今回の調査では、公開ディレクトリに操作履歴や関連ファイルが残されていたことに加え、内部記録からAIエージェントが大量の処理を自律的に繰り返していた実態も明らかになった。ただし、公開ホストのすべてが攻撃に使われていたわけではなく、観測されたホスト数をそのまま脅威の規模とみなすことはできない。防御側にとって重要なのは、攻撃者が最終的に利益を得たかどうかではなく、公開された管理画面や設定不備を足掛かりに、どこまで操作を進められる状態にあるかを把握することだ。外部からのアクセスを制限し、認証と権限を適切に管理することで、AIエージェントによる連続的な操作が侵害へと発展する経路を断つことが求められる。