インドのコンピューター緊急対応チーム（CERT-In）は注意喚起（CIAD-2026-0058）で、AIを使う攻撃グループ「Crafty Falcon（クラフティ・ファルコン）」がインドの銀行・金融サービス・保険（BFSI）分野を狙っていると警告した。The Hacker Newsが11月5日に報じた。同じ記事では、攻撃に使われるAI侵入テストツール「ARTEX」のバックドア入りDockerイメージが出回り、インターネット上の62台のコンソールが、認証なしでroot権限のコマンドを実行される状態だったことも伝えている。
事案の詳細
CERT-Inによると、Crafty FalconはインドのBFSI組織を標的とするAI支援型の脅威アクターで、活動は現在も続いている。CERT-Inは、使われているAIツールとしてARTEX、PentAGI、Cairn、CyberStrikeAIを挙げている。
CERT-Inが挙げた主な手口は次の通り。
- インターネットに公開されたアプリやAPIを悪用し、決済ゲートウェイや提携銀行のAPI認証情報を盗み、許可された接続元から送金APIを呼び出す
- 長期間有効な固定のAPIトークン、平文で保存された認証情報、多要素認証（MFA）のないリモートサービスを悪用する
- 1ルピーなどの少額の試し送金をしてから、複数の銀行の「受け子」口座へ大きな額を送る
- ログを消去し、端末のセキュリティ製品を改ざんする
- ファイルアップロードなどの弱点からWebシェルを仕込み、検証環境から本番環境へ侵入を広げる
暗号資産の取引所なども狙われ、鍵や資金が盗まれたという。
ARTEXのバックドアは、独立系の研究者Badbyte氏が見つけた。GitHub上のコピー版リポジトリ（スター数2,449、フォーク600以上）が「docker-compose.yml」の1行を変更し、Docker Hub上の「tomicdd/artex」イメージを取得するようにしていた。このイメージには、正規ソースにはない隠し関数「verifyCaptcha()」がログイン処理へ追加されていた。
CAPTCHA欄が特定の秘密の識別子で始まるリクエストを受けると、入力の残りの部分が「sh -c」に渡され、認証確認前にroot権限でコマンドが実行され、その出力が返される仕組みだった。これにより、認証を必要としないrootシェルが提供される状態になっていた。
同一のバックドア入りイメージとして「congdonglinux/artex」も確認された。バックドア入りのビルドを動かしていたインターネット公開のコンソールは、2026年11月2日から4日までに62台見つかった（米国26台、香港17台、中国7台など）。11月4日時点でARTEXのコンソールを公開しているホストは1,645台あったが、このうちバックドア入りが何台かは示されていない。「tomicdd/artex」は、Docker Hubの表示で約9,000回ダウンロードされている。
ARTEXのインスタンスには、未修正の検出結果、認証情報、取得済みセッション、ネットワーク上の位置情報などが保存される可能性がある。バックドアを利用できる攻撃者は、保存された情報を取得できるだけでなく、次回の実行時にエージェントの動作を変更できる可能性もある。
ARTEXの開発者が元のリポジトリをGitHubから取り下げた後、コピー版が出回り、その一つがこのイメージを参照するよう書き換えられた。バックドア入りのインスタンスは、遅くとも10月20日には稼働していたという。
また、ARTEXのようなAI支援型の攻撃ツールが侵害された場合、保存された標的情報や認証情報が追加の攻撃に利用されるおそれがある。Dockerイメージを信頼できないコピーから取得すると、アプリケーションのコードレビューでは見つけにくい実行時のバックドアが持ち込まれる可能性がある。
日本への影響
ARTEXは、日本企業を狙った最近の不正アクセスでも攻撃元での使用が確認されている（関連コラム）。今回確認されたARTEXのバックドア入りイメージは、国や業種を問わず、Dockerイメージの出所確認とインターネット公開コンソールの管理が重要であることを示している。日本企業でも、AI開発・セキュリティ検証用のコンソールを公開している場合、認証なしのコマンド実行によってホストや接続先の環境へ影響が及ぶ可能性がある。
特に、公開された管理画面、コンテナ内の環境変数、保存済みのAPIキーや認証情報、接続先ネットワークへの権限が攻撃者に取得されると、ARTEX自体にとどまらず、周辺システムへの侵入や不正操作につながるおそれがある。
対策・今後の展望
- 使用イメージの確認：ARTEXを利用している場合、「tomicdd/artex」および「congdonglinux/artex」を使用していないか、docker-compose.ymlと実際に取得したイメージを確認する。
- 公開コンソールの停止：ARTEXなどの管理・検証用コンソールをインターネットへ直接公開しない。必要な場合は、VPNやIP制限、強固な認証を組み合わせる。
- 侵害を前提とした再構築：該当イメージを使用していた場合はコンテナを削除し、レビュー済みの信頼できるソースから環境を再構築する。コンテナ内で使用したデータベースパスワード、LLM・検索APIキー、対象システムの認証情報、JWT署名鍵などは失効・再発行する。
- イメージの出所と変更履歴の確認：公式リポジトリ、固定ダイジェスト、署名、SBOMなどを確認し、コピー版や出所不明のDockerイメージを使用しない。
- ログ保全と侵害調査：ログインエンドポイントへの不審なリクエスト、異常なコンテナプロセス、root権限でのコマンド実行、外部への不審な通信を調査する。重要ログは別基盤へ保管し、改ざんを防ぐ。
CSRIからのアドバイス
AI関連ツールやセキュリティ検証用コンソールは、標的に関する情報、セッション、認証情報、ネットワーク情報を扱うことがあります。利用するDockerイメージの取得元を確認し、管理画面をインターネットへ公開しないことが基本的な防御になります。
今回の事例では、アプリケーションのソースコードに目立つ変更がなくても、Docker Composeの参照先を1行変更するだけでバックドア入りイメージが配布されました。依存イメージを含め、実際に実行されるコンテナの内容を検証してください。
まず、ARTEXを含むAI・セキュリティ関連コンテナのイメージ名とダイジェストを確認します。次に、インターネット公開の有無、コンテナ内の環境変数や保存済み認証情報、ログイン処理への不審なリクエストを点検してください。該当するイメージを使用していた場合は、関連する認証情報を失効させ、信頼できるソースから再構築します。
参照: CERT-In Flags AI-Driven Attacks as Backdoored ARTEX Exposes 62 Consoles to Root Access