脅威アクターが ARTEX の AI エージェントで展開するサイバー犯罪キャンペーンを Amazon Threat Intelligence が観測

本ブログは 2026 年 11 月 13 日に公開された AWS Blog “Amazon Threat Intelligence observes threat actors running cybercrime campaigns with ARTEX AI agents” を翻訳したものです。

2026 年 10 月 3 日から 11 月 5 日にかけて、Amazon の MadPot (世界中に分散配置されたおとりの脅威センサーのネットワーク) は、AI エージェントからのリクエストを捕捉しました。このリクエストには、脅威アクターがオープンソースのエージェンティック AI ペネトレーションテストフレームワークである ARTEX 上で実行した攻撃キャンペーンに関するエージェントの運用メモリが含まれていました。ARTEX のエージェントは、広く利用されている大規模言語モデル (LLM) の推論 API に見えるように設定された MadPot センサーにこれらのリクエストを送信しており、リクエストにはエージェント自身によるキャンペーンの記録が含まれていました。

Amazon Threat Intelligence は、影響を受けた可能性のある AWS のお客様に関連する脅威アクティビティを評価し、必要に応じて通知しました。その他の組織に対するアクティビティについては確認が取れなかったため、影響を受ける技術を運用している組織が自社の環境を確認できるよう、本記事では調査結果と侵害指標 (IOC) を共有します。

ARTEX を使用したキャンペーンのうち最も顕著だったのは、AI モデルにアクセスするための認証情報を大規模に窃取するものでした。このキャンペーンは、盗んだキーでさらなる認証情報の探索を支える LLM 推論の費用を賄い、自律的に継続するよう組織されていました。もう 1 つのキャンペーンは、リアルタイムのディープフェイク注入を使用して、暗号資産取引所の本人確認 (KYC) を回避することを狙ったものでした。エージェントの記録を総合すると、エージェンティックフレームワークが実験的な利用の段階から、最小限の人的介入で動作する、持続的で複数の目的を持つ攻撃オペレーションへと進展していることがわかります。本記事では、エージェント自身によるキャンペーンの記述に基づいて、これらのキャンペーンがどのように運用されていたかを説明します。

帰属評価と指示

Amazon Threat Intelligence は、プロンプトで ARTEX のツールが参照されていることや、ARTEX に関連するその他の技術的なアーティファクトが見つかったことから、これらのキャンペーンで ARTEX が使用されたと中程度の確度で評価しています。脅威アクターは、ミッションの目標、標的選定のルール、運用上の制約を定めた常時適用される指示プロンプトによって、ARTEX のエージェントに指示を与えていました。エージェントは、これらの指示の範囲内で、作業そのものを自ら進めていました。ある認証情報窃取キャンペーンでは、オペレーターはエージェントに対し、あらかじめ決められた順序で国ごとに作業を進めること、個人のプロジェクトよりも企業の本番サイトを優先すること、盗んだすべての認証情報を、動作するかどうかとアクセスできる範囲によって格付けすることを指示していました。また、30 日を超えて公開状態にあった認証情報は、価値の低いインベントリとして扱うよう指示されていました。

Amazon Threat Intelligence はまた、プロンプトで簡体字中国語が使用されていること、中国のタイムゾーンが設定されていること、標的の選定が中国の利益に合致していること、主に中国関連の脅威アクターが使用するツールが用いられていることから、これらが複数の異なる中国関連の脅威グループによるものであると中程度の確度で評価しています。サンプルとして確認できた指示には、中国本土の標的や政府ドメインを除外するなどのレッドラインの設定が含まれており、すべてのアウトバウンドトラフィックをプロキシ経由にすることが求められていました。

MadPot はこれらのキャンペーンの内部をどのようにとらえたか

MadPot は、潜在的な攻撃者に対して制御されたサービスを提示し、攻撃者がそれらをどのように発見し、テストし、侵害または悪用しようとするかを記録します。MadPot のテレメトリにより、Amazon Threat Intelligence は、お客様のワークロードを危険にさらすことなく攻撃者の行動を観察できます。今回は、MadPot センサーが、さまざまなポートで、広く利用されている LLM 互換のチャット補完インターフェイスを提示していました。エージェンティックフレームワークは、これらのインターフェイスを LLM 推論のバックエンドとして扱い、攻撃ワークフローの一部としてプロンプトを送信していました。

その結果得られたテレメトリには、これらのフレームワークが運用上の判断を下すために通常 LLM へ送信する、永続的なタスクコンテキスト、システムプロンプト、ツールの履歴、ナレッジグラフの状態、報告された調査結果が含まれていました。エージェンティックフレームワークは過去の会話の履歴を保持するため、個々のリクエストにキャンペーンの運用履歴全体が含まれていることがよくあります。その履歴には、捕捉されたリクエストの前や合間に、MadPot が監視していないシステム上で発生したアクティビティが記述されていました。Amazon Threat Intelligence は、そのアクティビティが発生した時点で観察したわけではなく、エージェントが報告した結果を検証することもできません。ただし、これらの記録から、脅威アクターが何を追求していたかがわかります。

アクティビティの大半では、ARTEX を使用して、永続的なナレッジグラフを共有するプランナー、ワーカー、検証担当、圧縮担当の各エージェントに作業を分担させていました。ナレッジグラフはオペレーションの共有メモリとして機能します。すべてのエージェントがそこから読み取り、結果を書き戻すため、各エージェントは他のエージェントが作業を終えたところから続きを進められます。エージェントの記録には、AI アプリケーションプラットフォームやその他のワークロードにまたがる数百の標的に対する、偵察、脆弱性テスト、認証情報の窃取、クラウド権限の拡大、暗号資産詐欺の試行が記述されていました。これらの記録は、脅威アクターがエージェンティック AI フレームワークを使用して、金銭目的の持続的な攻撃オペレーションをどのように組織しているかを示しています。

キャンペーン 1: AI の認証情報を大規模に窃取

このキャンペーンでは、脅威アクターは AI エージェントを使用して、AI モデルへのアクセスを許可する API キーやその他の認証情報を盗んでいました。その目的は、他の誰かに料金を負担させたまま、それらのモデルを利用することだったとみられます。エージェントの記録によると、盗んだキーはフレームワーク自体のモデルゲートウェイに投入され、さらに多くのキーを探すエージェントを動かすために使われていました。AI モデルのアクセスキー以外にも、クラウドの認証情報は、さらなるアクセスへの入り口として扱われていました。エージェントは、各プロバイダーのトークンサービスと ID サービスを通じて ID を検証し、ストレージを列挙し、権限の範囲を評価したうえで、マネージド AI モデルサービス、シークレットストアとパラメータストア、アプリケーションの ID を狙っていました。エージェントは、一般的なクラウド権限よりも、プレミアムクラスのフロンティアモデルへのアクセスを優先していました。

エージェントの記録には、それぞれ異なる AI ゲートウェイ、キー、モデルの使用が残されていましたが、いずれも共通の手法を用いていました。それは、インターネットに公開されている AI アプリケーションを見つけ、そこに保存されているアップストリームプロバイダーのキーを抽出し、それらのキーを検証して、管理対象のプールに保存するというものです。エージェントは、プロバイダーのキーを集約しているアプリケーションに注力していました。脆弱な管理インターフェイスが 1 つあるだけで、多数のダウンストリームアカウントが露出する可能性があるためです。標的には、One API、New API、Veloera、Sub2API、LiteLLM などの LLM ゲートウェイやプロキシプラットフォーム、および Dify、FastGPT、Langflow、RAGFlow、Open WebUI、LobeChat、Ollama などの AI アプリケーションビルダーが含まれていました。体系化された脆弱性プレイブックでは、フィンガープリントで特定した各製品が既知の攻撃チェーンに対応付けられていました。その攻撃チェーンには、乗っ取り可能な未初期化のインストール済み環境、匿名でアクセスできる管理エンドポイントとプロバイダー設定エンドポイント、LiteLLM のデフォルトのマスターキーなどのデフォルトの管理者認証情報、CVE-2025-3248 (Langflow)、CVE-2026-28797 (RAGFlow)、One API ファミリーのシステムにおける isCliRequest ヘッダーによる認証バイパス、URL 取得機能を介したクラウドメタデータサービスへのサーバーサイドリクエストフォージェリ (SSRF)、クライアントサイドの JavaScript、ソースマップ、デバッグルート、環境ファイルに残されたシークレットが含まれていました。

これらのキーを見つけるために、探索にはインターネットスキャンサービス、証明書の透明性 (Certificate Transparency)、公開コードやアーティファクトのソースが利用されていました。具体的には、GitHub のリポジトリとイベントアーカイブ (自動失効の対象外となったシークレットを狙ったもの)、npm と PyPI の tar アーカイブ、コンテナイメージのレイヤー、ノートブック、モデルホスティングスペース、ペーストサイト、Telegram チャネルです。並行して行われていたあるオペレーションでは、あらかじめ決められた順序で国ごとに作業を進め、企業の本番サイトを優先し、すべての認証情報を格付けしていました。L1 は手がかり、L2 は API コールが実際に動作することを確認できたもの、L3 は読み取り可能なデータや使用可能な残高など、影響を定量化できたものです。30 日を超えて公開状態にあったキーは、価値の低いインベントリとして扱われていました。

キャンペーン 2: ディープフェイクによる本人確認の突破

このキャンペーンでは、脅威アクターは AI エージェントを使用して、2 つの暗号資産取引所の KYC をディープフェイクで突破しようとしていました。エージェントの記録によると、ライブのセルフィー確認を通過するためにリアルタイムのディープフェイク動画を生成し、書類確認を通過するために本人確認書類の写真を偽造していました。

記録には、ライブネスチェックに対する綿密な手法が記述されています。ライブネスチェックとは、デジタルシステムを操作している人物が、撮影時にその場にいる実在の生きた人間であることを確認するセキュリティ手法です。エージェントは、あるベンダーのライブネスプロトコルを詳細にリバースエンジニアリングし、そのプロトコルが送信する顔検出のイベントストリーム、確認中に顔の位置を追跡する方法、ユーザーにどこへ動くかを伝えるために使用する座標系を文書化していました。記録された中で最良の試行では、顔を目標位置から 7 ピクセル以内に収めた状態で、動作シーケンス全体を完了していました。それでも、エージェントが記録したすべての試行で、ディープフェイクはベンダーのサーバーサイドでの判定によって拒否されました。並行して、別のセッションでは、オープンソースの顔アニメーションモデルを使用し、1 台のコンシューマーグレードの GPU 上でリアルタイムのディープフェイク動画パイプラインを構築していました。モデルを分割し、GPU 上での不要なメモリコピーを避けることで、ライブ動画確認で期待されるフレームレートに近い毎秒 11.5 フレームを達成しました。

エージェントは本人確認書類にも取り組んでいました。本人確認ベンダーは、書類の写真が編集された形跡や、書類そのものではなく画面を撮影した画像である形跡を探します。これらのチェックを通過するために、エージェントは、画像の寸法が JPEG ファイル内の実際の値と一致する合成カメラメタデータを作成し、編集した画像を再保存すると通常は置き換えられてしまう元のカメラの圧縮テーブルを保持したと記録していました。その結果、ファイルレベルでは未加工のカメラ写真のように見える、改変された画像が作られます。

このキャンペーンは、ARTEX が 1 つの目標に向けて複数のワークストリームをどのように実行するかも示しています。少なくとも 4 つのエージェントセッションが同時に実行されていました。1 つは換金方法を探し、1 つはアカウント残高を空にする作業に取り組み、1 つはディープフェイク動画パイプラインを構築し、1 つは本人確認の回避を実行していました。これらは、セッション間で連携するツールを通じて、調査結果を共有し、タスクを引き継いでいました。

防御側にとっての意味

これらのキャンペーンで使用された手法に、新しいものはありませんでした。AI エージェントが変えるのは、攻撃の速度と継続性です。エージェントは、基本的なセキュリティ対策が欠けている環境で成功を収めていました。具体的には、デフォルトまたはハードコードされた認証情報、コードや公開アーティファクトに残されたキー、認証が設定されていないインターフェイスや推論エンドポイント、パッチが適用されていないソフトウェアなどです。こうした基本的な対策を適切に実施することが、依然として最も効果的な防御です。

攻撃が高速かつ継続的に行われることを踏まえ、組織は、露出したシークレットや設定ミスがすぐに発見されるものと想定し、それに応じて修復する必要があります。また、AI アプリケーション、モデルゲートウェイ、推論エンドポイントを、他の本番システムと同じコントロールの下に置き、予期しない支出や異常な使用状況を手がかりに、AI サービスの不正使用を監視する必要があります。

IOC

ご質問がある場合は、AWS re:Post で新しいスレッドを開始するか、AWS サポートまでお問い合わせください。

本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。