DockerへのpingからAIコマンドプレーンへ：Hermes攻撃ワークベンチとCarbonatoモデルゲートウェイの実態（第1部：発見）
Key Takeaways
- Dockerの乗っ取り未遂を調査し、外部に公開されたDocker APIがホストへの侵害の足がかりになり得ることを確認しました。
- 攻撃者はホストのファイルシステムにアクセスし、リモートアクセスと永続化を目的とするペイロードを展開しようとしました。この試みを追跡した結果、攻撃者の不正なスクリプト、インフラ、AIを活用したツールチェーンにたどり着きました。
- 攻撃者のコンテナレジストリを分析した結果、イメージ名やタグが実際の機能を覆い隠し得ることがわかりました。243個のタグがわずか7種類のビルドを指し、一見無関係なイメージも同じエントリポイントスクリプトを共有していました。イメージの中身を調べることが重要です。
- 攻撃オペレーションにAIエージェントを組み込む実例を確認しました。攻撃者はHermes、Carbonato、スキャナなどを組み合わせたツールチェーンを構築し、29個のエージェントにタスクを委任して、複数のサービスを標的に活動していました。
はじめに
2026年7月、ハニーポットの1つで、攻撃者がDocker APIを探索する様子を観測しました。7月上旬から10月までのうち、断続的に少なくとも7週間にわたって活動を観測しました。単純なpingから始まった探索は、コンテナの作成、ホストのファイルシステムへのアクセス、不正なスクリプトの展開を試みる段階へと進みました。
これらの試みは失敗しましたが、調査の手がかりが残りました。攻撃者のペイロード配信サーバをたどると、以下の要素を組み合わせた、はるかに大規模なオペレーションが見つかりました。
- AIエージェントフレームワーク「Hermes」
- 非公開のモデルゲートウェイ「Carbonato」
- 複数のサービスを標的とする攻撃に使われたスキャナ、スクリプト、コンテナイメージ
本リサーチでは、攻撃者が既存の攻撃手法にAIを組み合わせてツールチェーンを構築した経緯と、その基盤となるインフラ、企業や組織にとってのリスクを詳しく調べました。
調査結果と分析の詳細（日本語版）は、 こちら の技術解説をご覧ください。
Dockerの探索から乗っ取りの試みまで
攻撃者はまず、TCPポート2375で外部に公開されていたDocker APIにリクエストを送りました。コンテナを列挙し、イメージが実行できるかを試し、ホスト環境の情報を収集しました。
次に、ホストのルートファイルシステムを読み取り専用でマウントするよう指定し、コンテナの作成と、外部サーバから取得したスクリプトの実行を試みました。この試みが失敗すると、コンテナの構成、ベースイメージ、権限設定、実行方法を変えて再試行しました。
コンテナはいずれも起動しませんでした。ハニーポットのDockerランタイムがネストされていたため、「runc」が「/proc」の構成を受け入れなかったことが原因です。一連の試行は失敗したものの、攻撃者が実行しようとしたペイロードを調べることができました。攻撃者のサーバには、以下の2つのスクリプトが置かれていました。
- リバースシェルを確立するためのスクリプト
- アクセスを永続化するため、対象アカウントの認証設定に攻撃者のSSH公開鍵を追加するスクリプト
これらのスクリプトは、Dockerの管理インターフェースを外部に公開すると、ホストへのアクセス、コマンドの実行、アクセスの永続化を試みる攻撃者に足がかりを与え得ることを示しています。
AIを活用した攻撃ワークベンチの実態
ペイロード配信サーバを追跡したところ、Hermes、Kali Linuxベースのツール、スキャナ、補助コンテナなどが稼働するワークベンチが外部に公開されていました。別のサーバでは、攻撃者の非公開のOpenAI互換モデルゲートウェイ「Carbonato」が稼働していました。
これらのコンポーネントを組み合わせることで、AIエージェントと従来の攻撃用ツールが連携する環境が構築されていました。
エージェントフレームワークであるHermesは、永続セッション、タスクを委任できるサブエージェント、シェル・コード・ファイルを扱うツールを提供していました。Carbonatoがモデルへのリクエストを処理し、攻撃者はTelegramを通じて指示を送り、報告を受け取っていました。
回収したHermesのログから、長時間稼働した1つの親セッションが、14回に分けて短時間稼働のエージェントを29個起動したことがわかりました。親セッションとワーカーからのモデルへのリクエストは、合計2,938件でした。
標的はDocker以外にも及びました。同じ環境には、Redis、etcd、Spring Cloud Config、Prometheus、Jupyter、Grafana、メッセージブローカー、アプリケーションのログイン機能を標的とした活動のスクリプトやログが残っていました。
注目すべきは、こうした機能の組み合わせ方です。攻撃者は個々のツールや手作業に頼るだけでなく、AIエージェントにタスクを委任し、複数のサービスに対して活動できる環境を構築していました。
ただし、このインフラと観測したエージェントの活動だけでは、AIによって攻撃の効果や成功率が高まったかどうかは判断できません。AIを活用した攻撃に何ができ、どのような影響を及ぼし得るかを評価するには、観測した活動と、その効果を区別することが重要です。
機能を覆い隠していたコンテナイメージ
分析の結果、攻撃者のインフラにイメージを供給する2つの外部Dockerレジストリも見つかりました。
- プライマリレジストリのカタログには72個のイメージと243個のタグがありました。243個のタグが指していたビルドはわずか7種類で、そのうち1種類に161個のタグが付いていました。
- セカンダリレジストリには、一般的なアプリケーションやサービスに見える名前のイメージがありました。
レイヤーとエントリポイントスクリプトを調べると、名前からはわからない機能が見えてきました。たとえば、プライマリレジストリの「apk:latest」とセカンダリレジストリの「android-remote/logger-api:latest」は、同じエントリポイントスクリプトを共有していました。そのスクリプトには、Hermes、Telegram、Carbonato、SSH、Dockerに関連する機能が含まれていました。調査したほかのイメージには、ビーコン用スクリプトを起動するものや、リモートアクセス用の設定を含むものもありました。
結論
今回の調査では、外部に公開された管理インターフェース、コンテナへの過剰な権限付与、信頼できないイメージといった、以前から知られているセキュリティリスクに対処する重要性が改めて確認されました。また、攻撃者が既存の手法とAIエージェントフレームワークを組み合わせ、複数の標的に対して活動できることもわかりました。
防御にあたっては、コンテナ管理インターフェースへのアクセスを制限し、イメージ名に頼らず中身とエントリポイントスクリプトを確認することが重要です。未承認のSSH鍵や不審な外部向け接続も監視する必要があります。
本リサーチの第1部では、このオペレーションを発見した経緯と、背後にあるインフラやツールを取り上げました。第2部では、Hermesのセッションデータベースを調べ、攻撃者がエージェントにどのような指示を出したのか、記録された活動からAIを活用した攻撃の能力と限界について何がわかるのかを検討します。
調査結果と分析の詳細（日本語版）は、 こちら の技術解説をご覧ください。
参考記事：
By: Alfredo Oliveira , Nelson William Gamazo Sanchez
翻訳：与那城 務（Platform Marketing, TrendAI™ Research）