ARTEX AI エージェントの武器化:ネットワークへの侵入の自動化と機密データの窃取

Hackers Weaponize ARTEX AI Agents to Automate Network Intrusions and Steal Sensitive Data

2026/11/02 gbhackers — 自律型ペンテスト・フレームワークである ARTEX を攻撃に転用する攻撃者が、ネットワークへの侵入の高速化/権限昇格/機密情報の窃取などを実行している。Google Threat Intelligence Group (GTIG) と Mandiant のレポートに記載された調査結果から明らかになったのは、連携する AI エージェントに対して、侵害後の活動の大部分を委ねる攻撃者が、一連の処理を数秒で実行していることである。2026年8月下旬から確認されている、ARTEX に関連する活動に含まれるのは、金銭目的の恐喝グループと、サイバースパイ活動への関与が疑われる攻撃主体である。

この状況が示すのは、2026年9月に Google が公開したレポート From Prompting to Autonomy で説明された、チャットボットによる作業支援から、ツールの実行/結果の解釈/処理中に発生した問題の解決などを行う、エージェント型ワークフローへの移行がさらに進んでいることである。

ARTEX は Go 言語で開発され、Next.js ベースのコンソールを組み込んでいる。6つの専門的なサブエージェントを通じて、オペレーターが指定した目的をシステムコマンドに変換する。

調査担当者が確認した機能には、Active Directory の偵察/クラウド環境の権限調査/認証情報の収集/権限昇格/カスタム Web シェルの設置などが含まれる。

オペレーターが侵害済みの認証情報を ARTEX に渡し、侵入を継続するよう指示する場合もあった。その後に、ARTEX が実行したのは、アクセス権限の検証/スクリプトの生成/エラーへの対応などである。

個々の処理は約 2~25秒で実行された。ある調査で記録されたのは、ARTEX が AWS の権限を調査する 23秒間で、27件のイベントが発生したことである。

ただし、処理速度の向上が精度の向上につながったわけではない。インターネットに公開された Weaver OA サーバに対して、ARTEX は認証済みのアプリケーション API を使用して SQL コマンドを発行し、データベースへのアクセス権限を利用して OS 上でコマンドを実行しようとした。この反復的な手法により 240件のログイベントが生成されたが、その中にはサブエージェント間の競合により発生した可能性のある失敗も含まれていた。

ARTEX は MySQL のログ機能を悪用し、Web からアクセス可能なディレクトリに JSP Web シェルを配置しようとした。コンパイルエラーが発生すると、一部のファイルから有効なコマンド実行結果が返されるまで修正を繰り返した。この活動は、状況に応じて攻撃手法を調整する能力を示す一方、大量のフォレンジック上のノイズも発生させていた。

ARTEX の AI エージェント

ARTEX に関連する攻撃キャンペーンの一つを、GTIG は UNC7228 として識別しているが、この活動は、Microsoft が中国との関連を指摘する Storm-0940 の活動と重複している。

提示された調査結果では、米国と欧州のソフトウェア/産業オートメーション/半導体/通信分野などの組織が侵害された事例が報告されている。

攻撃者は通常、最初に侵害したアカウントを起点として、約 4時間でシステム内部の広範なアクセス権限を獲得していたが、ある事例では僅か 15分で到達していた。

2026年10月に Wiz が公開した調査でも、Okta/Microsoft Entra ID/AWS Cognito/Microsoft 365 との連携機能を含む IT ベンダーやソフトウェア・ベンダーを標的とした、重複する攻撃活動が確認されている。

一連の攻撃では、アプリケーションの構造調査/認証機能の探索/パスワードスプレー攻撃/アカウント復旧機能の悪用/テナント間アクセスの検証が組み合わされていた。

AI エージェントがダウンロードしたソースマップから、API ルートを抽出した Wiz が確認したのは、その数分後に抽出されたルートへ向けてリクエストを送信する活動である。アクセスがブロックされると、攻撃対象のエンドポイントや使用するインフラが変更された。一部のセッションは 24~30時間継続したが、個々の攻撃試行の大半は失敗していた。

Mandiant の調査では、データベースからのデータ抽出/大量の BLOB データの読み取り/広範なディレクトリの列挙/データ流出に使用する可能性のあるクラウドストレージの準備が確認された。調査担当者は、送信先を切り替えながら “webhook.site” のエンドポイントを経由して、コマンドの実行結果を送信する活動も確認した。


防御側に求められるのは、短時間に集中する権限確認/繰り返される認可の失敗/予期しない管理者アカウント/Web シェルの作成/異常なスナップショット操作/外部への Webhook 通信などを、関連付けて分析することである。

個別のファイル名や一般的な User-Agent だけでは、攻撃主体を特定するための十分な指標にはならない。公開されている多くの User-Agent 指標を、脅威ハンティングに使用すると大量のノイズを引き起こすと、Wiz も警告している。

推奨される対策として挙げられるのは、管理プレーンの分離/有効期間の短い認証情報の使用/最小権限の原則の適用/ネットワークのセグメンテーション/迅速な封じ込めなどを開始するための、振る舞いの検知である。これらの対策が目的とするのは、AI エージェント型ツールにより、これまで以上に高速で悪用される、既知のセキュリティ上の弱点への対応である。


ARTEX の開発者は、悪意の目的での悪用を受け、10月08日にプロジェクトの終了とメンテナンスの停止を発表した。ただし、この発表により、コピーやフォークが使用できなくなるわけではない。

現在の証拠が示しているのは、侵入の複数の段階にわたり、大量のログを残しながら自動化された攻撃が成功していることである。あらゆる環境に対して、検知を回避しながら完全自律型の侵害を実現できることを示すものではない。

当面の課題は、自動化された試行により悪用可能なアクセス経路が発見される前に、防御側が対応できる時間を短縮することである。