概要

AI は、資料調査や文書作成、コード分析など、これまで人間が直接行っていたさまざまな業務に活用されている。 2026年の企業調査でも、AI を活用する組織においてその適用範囲が前年より拡大していることが明らかになった。最近では、個々の作業を支援するだけでなく、複数の段階にわたる作業を連続して実行させ、業務の大部分を自動化しようとする動きも見られる。

セキュリティ分野も同様である。代表的な例として、GitHub では LLM を使用してコードの脆弱性を検出する Vulnhuntr や、 Ghidra を LLM と連携させてリバースエンジニアリングを支援する GhidraMCP などが公開されている。ペネトレーションテストの分野にも PentestGPT、CyberStrikeAI のように、複数段階の作業をエージェントとセキュリティツールで連携させるオープンソースプロジェクトが存在する。

ARTEX も、こうした自律型侵入ツールの1つである。ユーザーが対象と目標を入力すると、複数のエージェントが資産を調査し、ツールを選択して作業を実行する。あらかじめ定められた手順を繰り返すのではなく、前の作業の結果に基づいて次の行動を決定する。
ARTEX に注目したきっかけは、インターネットに公開されていた Web コンソールである。この Web コンソールを手掛かりに関連インフラを追跡したところ、一部のホストで攻撃目的の活動と一致する運用資料も発見された。

実際の攻撃に利用された可能性を示す資料が確認されたことから、オープンソースとして公開されている ARTEX を別途用意したテスト環境にインストールし、自律型侵入がどこまで可能なのかを調査した。それぞれ異なる環境で実施したテストでは、対象、目標、許可範囲を伝えたものの、サービス名や脆弱性、具体的な攻撃手順は伝えていない。その結果、ファイルアップロードの脆弱性が存在する Web サーバーでは、Web シェルを介してプログラムを実行した。また、Apache ActiveMQ が公開されている環境では、初期アクセスに続いて内部ホスト4台でリモートコマンドを実行した。これは、ユーザーが攻撃の過程を細かく指示しなくても、脆弱な環境ではコマンド実行から内部ネットワークへの移動まで進行する可能性があることを示している。

本ブログでは、インターネットに公開されていた ARTEX を追跡する過程で攻撃活動の痕跡を確認した経緯とツールの動作構造を解説する。また、2つの再現実験で確認した攻撃範囲と対応の観点についても紹介する。

外部に公開された ARTEX と攻撃活動の痕跡

ARTEX 運用システムの分布状況

インターネットに公開されている ARTEX 関連の IP アドレスをすべて攻撃者のアドレスと分類したり、ツールをダウンロードしたユーザーや ARTEX が調査した対象の IP アドレスと解釈したりすることはできない。
アンラボが ARTEX の Web コンソールの特徴を手掛かりに公開インフラを追跡した結果、ARTEX のインスタンスをホスティングしているパブリック IP アドレスが600個確認された。詳細については、AI が攻撃の参入障壁を下げる：ASEC が追跡した ARTEX インフラ | AhnLab で確認できる。確認された IP アドレスは、インターネットに公開されている ARTEX 運用システムの分布状況を示している。

[表1] 国・地域は IP アドレスの所在地に関する推定値。データ提供：DB-IP.com Country Lite 2026年10月版、CC BY 4.0。

IP アドレスの国・地域情報だけで運用者の国籍や攻撃の発信元を判断することはできない。しかし、600個のホスティング IP アドレスを DB-IP Country Lite 2026年10月版と照合した結果、米国、中国、香港、シンガポールに541個 (90.2%) が分布していることを確認した。
さらに、2026年10月14日時点で、インターネットに公開されている ARTEX 運用システムの IP アドレスは約900個以上に達していることが確認された。

ASEC が ARTEX 関連インフラで公開されている Web サービスを追加調査した結果 (ARTEX の進化：アンラボが追跡した AI ベースのペネトレーションテストインフラ | AhnLab)、AI API ゲートウェイの Sub2API が252件、攻撃対象領域管理ツールの Scope Sentry が22件、AI ペネトレーションテストプラットフォームの CyberStrikeAI が15件確認された。
ただし、この調査結果は、前述した600個の IP アドレスの国・地域別分布とは集計基準が異なる。それでも、ARTEX をホスティングしている一部の環境では、ほかの AI 関連ツールやセキュリティツールも同時に公開されていることが分かる。

ARTEX の公開ホストで攻撃者の活動痕跡を確認

前述の IP アドレスでどのようなツールやファイルが公開されているかを追加調査した。
その結果、ARTEX が配布されていた、または関連コンテンツが確認されたホストにおいて、Web サーバー経由でアクセス可能な2つのオープンディレクトリを発見した。両ディレクトリには、内部ネットワークの探索やアクセス、ピボット、後続ペイロードの運用に関するファイルが残されており、合計51個のファイルを取得した。

1つ目のディレクトリからは、ARTEX の作業パスが残されたスクリプトを含む37個のファイルを取得した。取得したファイルを確認したところ、ASPX Web シェルにコマンドを送信するように作成された ws.sh ファイルや、外部接続を内部 RDP サービスに中継するように構成された pivot_relay.ps1 スクリプトファイルが存在した。さらに、リレーファイルのダウンロードと接続の記録、xfreerdp プロセスの実行痕跡も残されており、内部システムへの RDP 接続を試みた過程まで確認できた。

2つ目のディレクトリからは、スキャン結果、スクリプト、実行ファイルなど14個のファイルを取得した。スキャン結果には、Kubernetes Pod ネットワーク内の稼働中のシステム85台と、別の内部ネットワークにある8台が記録されていた。
同時に発見された extract_hprof.py は、JVM ヒープダンプから認証情報に関連する文字列を検索するように作成されていた。また、P.class は Linux 向けインプラントをダウンロードして実行するように設計されていた。LocaleMgr.exe からは、コマンド実行、ファイル操作、トンネリング機能に関する文字列も確認された。

前述の900個以上の IP アドレスすべてを攻撃者のインフラと分類したり、特定の攻撃グループやキャンペーンと関連付けたりすることはできない。また、2つのディレクトリから取得したファイルも、ARTEX の標準ツールキットだけで構成されていたわけではない。
ARTEX にはユーザー独自のツールを追加できるため、攻撃者は対象に合わせて別途入手したスクリプトや自ら作成したスクリプトおよびマルウェアを組み合わせて使用できる。
ただし、2つの運用ディレクトリに関連する IoC には、前述の600個のアドレスに含まれる IP アドレス2個と、マルウェアおよびファイルの MD5 ハッシュ18個が含まれていた。これらを運用ディレクトリ内の資料と併せて分析すると、ARTEX が確認された一部のホストは攻撃目的の活動またはその準備に使用されていたと推定される。取得した IoC 情報は [表2] のとおりである。

[表2]  IoC 情報

攻撃に使用された痕跡が残されていたツールや、後続の活動に向けて準備されていたツールの詳細、および2つの事例の詳しい経緯については、中国の AI ペネトレーションテストツール ARTEX のインフラ分析 #3 – AhnLab TIP で確認できる。

ARTEX の動作方式と構造

ユーザーが ARTEX の Web UI で資産と作業を登録し、LLM を接続すると、サーバーがエージェントの実行状態を管理する。収集した資産情報と作業履歴は PostgreSQL に保存される。ユーザーは同じ画面で進行状況と結果を確認できる。また、ARTEX は承認プロセスによって作業を制御し、Worker が使用する一部のツールの通信を記録用プロキシに保存する。

ARTEX は、対象そのものに関する情報と作業中に行った判断を、それぞれ資産グラフと探索グラフで管理する。
資産グラフに保存されたドメイン、IP アドレス、サービス、アプリケーション、エンドポイントの情報は、複数の作業で共有される。一方、探索グラフには、目標や確認した事実、発見した脆弱性、後続の判断がどのようにつながったかが記録される。
この2つの記録を関連付けることで次の作業を実行する根拠を確認でき、同じ資産を繰り返し調査する作業も減らせる。

ユーザーが目標と許可範囲を入力すると、Goals がその内容を整理する。次に、Planner が取得済みの資産情報と観測結果に基づいて次の探索作業である Intent を作成する。Worker がその作業に応じてツールを実行し、新たに確認した情報を記録すると、Planner は返された結果を検討し、後続の作業を決定する。

[表3] 自律型作業に利用されるエージェント

LLM がテストの方向性を決定すると、Skill がツールの使用手順を案内し、Tool がコマンド実行や HTTP リクエストを通じて対象とやり取りする。
使用可能なツールや権限、ネットワークへのアクセス範囲によって、同じ目標を入力しても結果は異なる場合がある。また、対象システムに記録されるのはエージェントの名称ではなく、実際にツールが送信したリクエストと、その後に発生した実行行為である。

ARTEX によるペネトレーションテスト

ARTEX を使用して実際の侵入に至ることができるかを確認するため、ARTEX を活用したペネトレーションテストを実施した。テストでは、対象、目標、許可範囲を伝えたうえで、ARTEX が公開されている機能を調査しながら、どこまで作業を進めるかを確認した。
テストは合計2回実施し、それぞれ異なる環境と目標を対象とした。
Web サーバーを対象とした実験では、Web ページに存在するファイルアップロード機能を利用し任意のプログラムを実行することを目標とした。一方、The DFIR Report に記載された初期の露出条件を別の実験ネットワーク上に再現した ActiveMQ の実験では、初期侵入後に内部ネットワークへ移動することを最終目標としてテストを実施した。

2つの実験でユーザーが伝えたのは、対象、目標、許可範囲のみであり、ARTEX はサービスの探索結果に基づいてそれぞれ異なる侵入経路を選択した。
入力したプロンプトは非常に単純なものであった。セキュリティ分野の専門知識を持たないユーザーでも入力できる程度の 「攻撃対象に侵入してほしい。指定した対象だけを攻撃してほしい」 というレベルの指示である。それにもかかわらず、ユーザーの短い指示1つだけで、人間が途中で介入することなく、Web サーバーではアップロード機能を通じて単一ホスト上でプログラムを実行するという目標を達成した。また、ActiveMQ では外部サーバーへの初期アクセスを足掛かりとして内部ホスト4台でリモートコマンドを実行する段階まで到達したことを確認した。
ARTEX の構造と動作方式、テスト環境および攻撃過程の詳細については、「AI  ベースの自律型ペネトレーションテストツール ARTEX の構造と動作分析」 で確認できる。

2つのテストの実施方法と最終結果をまとめると、以下のとおりである。

2つのテストで確認した自律型侵入の範囲

[表4] テストごとの実施方法と結果

ARTEX の攻撃フローと User-Agent ベースの検知の限界

ASEC のテスト結果から、ARTEX は外部に公開されているサービスや機能を探索し、セキュリティ設定が不十分な環境や脆弱な状態で運用されている環境を対象にさまざまな攻撃を試みることが確認された。

この過程で、ARTEX が直接送信したリクエストや外部ツールを介して送信したリクエストには異なる User-Agent が記録される場合がある。ただし、すべての作業でリクエストが発生するわけではなく、HTTP 以外の通信には User-Agent という値自体が存在しない。
HTTP リクエストであっても、ツールの設定やログの収集方法によっては値が記録されない場合があり、攻撃者が変更することもできる。そのため、特定の User-Agent だけを根拠として ARTEX の活動を検知したり遮断したりすることは困難である。

機能別の User-Agent 確認結果

PoC テストの結果、ARTEX の機能や呼び出すツールによって異なる User-Agent が記録されることが確認された。
ARTEX の実行ホストが GitHub に更新を確認する際には artex-selfupdate、攻撃対象の Web ページを参照する際には norma/0.4、ファイルをアップロードする際には curl/<バージョン> が確認された。このうち、artex-selfupdateはGitHub に送信されるリクエストであるため、攻撃対象の Web サーバーのアクセスログには記録されない。

ネットワーク偵察や侵入範囲の拡大には、nmap、nxc、impacket などの外部ツールが使用される場合がある。HTTP リクエストが発生すればそれぞれのツールの User-Agent が記録される可能性があるが、HTTP 以外の通信では User-Agent は記録されない。
したがって、関連する活動を確認するには、Web アクセスログだけでなく、ファイアウォールのログ、ネットワーク接続記録、サービスへのアクセス記録も併せて確認する必要がある。

ARTEX のソースコードには artex-enrich/1.0 が、api-recon の参考スクリプトには Mozilla/5.0 (spa-api-recon) および Mozilla/5.0 (spa-api-recon spider) が User-Agent として設定されている。
しかし、分析対象の ARTEX のバージョンでは、artex-enrich 機能を呼び出す部分が接続されておらず、今回の PoC では api-recon スクリプトも実行していない。そのため、これらの値は実際の通信で確認された痕跡ではなく、機能やバージョンによって記録される可能性がある情報として区別する必要がある。

検知の限界と対応方針

ARTEX の活動を調査する際、特定の User-Agent だけで攻撃行為全体を把握することは困難である。ARTEX と外部ツールでは異なる値が使用され、機能や通信方式によっては User-Agent が記録されないこともあるためである。
また、攻撃者が値を変更したり削除したりすることも可能であり、curl のようなツールは通常の管理業務にも使用される。したがって、User-Agent は攻撃活動を追跡するための手掛かりとして活用すべきであり、特定の値が検出されたという理由だけで ARTEX の使用や侵入の成功を断定してはならない。

AI を活用した攻撃では、偵察、サービス探索、ファイルアップロード、コマンド実行、内部ネットワークへのアクセスを一連の連続したプロセスとして自動化できる。これに対応するには、特定の User-Agent や個々のツールの検知に依存するのではなく、それぞれの行為がどのような順序と関係でつながっているかを攻撃フロー全体の観点から分析する必要がある。

そのためには、サーバーや PC におけるファイルとプロセスの実行状況を確認できる EDR を運用するとともに、Web、ネットワーク、認証ログとエンドポイントの検知結果を連携させる XDR ベースの分析体制を整備する必要がある。複数のセキュリティ記録を組み合わせて分析することで、User-Agent が変更されている場合や記録されていない場合でも、初期侵入、コマンド実行、内部ネットワークへの移動の兆候を特定できる。

まとめ

2回の実験において、ARTEX はユーザーが提示した目標を細かな作業に分解し、各ツールの実行結果に応じて攻撃方法と次の作業を自律的に調整しながら侵入を継続した。
Web サーバー環境では、ファイルアップロードの経路を見つけてプログラムを実行した。また、ActiveMQ 環境では、初期アクセスの後、内部ホスト4台でリモートコマンドを実行する段階まで到達した。

インターネットに公開されている ARTEX のホスティングインフラを調査した結果、一部のサーバーでは ARTEX の作業パスと攻撃運用に使用されたとみられる資料が併せて確認された。別のサーバーでは、CyberStrikeAI や AI API ゲートウェイなど、複数の AI 関連ツールも発見された。
これは、公開されている AI ベースの攻撃ツールが単なる実験や概念実証にとどまらず、実際の攻撃を準備または実行する環境で利用されている可能性を示している。

今回の実験を通じて、ARTEX が公開サービスの脆弱性や設定不備を利用し、初期アクセスからコマンド実行、内部ネットワークへのアクセスまで侵入範囲を拡大できることを確認した。これは、AI ベースの自律型侵入ツールがすでに現実的な脅威となっており、今後その影響がさらに拡大する可能性があることを示している。

AI を活用した攻撃の試みは、今後さらに増加する可能性が高い。しかし、対応の基本原則が変わるわけではない。外部に公開されているサービスや管理機能を特定して不要な公開を減らし、脆弱性や設定不備を迅速に修正する必要がある。また、アカウントの権限と内部ネットワークへのアクセスも必要最小限の範囲に制限すべきである。
さらに、EDR を通じてサーバーや PC におけるファイルとプロセスの実行状況を確認し、XDR を基盤として Web、ネットワーク、認証ログとエンドポイントの検知結果を連携させる必要がある。これにより、初期侵入からコマンド実行、内部偵察、内部ネットワークへの移動まで続く攻撃フローを早期に特定し対応することが可能となる。