DockerへのpingからAIコマンドプレーンへ：Hermes攻撃ワークベンチとCarbonatoモデルゲートウェイの実態（第2部：攻撃オペレーション）
Key Takeaways
- AIエージェントが複数の攻撃タスクを統括できることを確認しました。1つの永続的な親セッションが29個のワーカーにタスクを委任し、一連の活動を単一のオペレーションとして管理していました。
- 短時間しか稼働しないAIエージェントも、攻撃能力の蓄積に寄与します。エージェントが作成した19個のスキルパッケージと430件のパッチが見つかりました。攻撃手法、修正点、失敗したアプローチが、再利用できる形で保存されていました。
- 攻撃オペレーションを継続したままAIモデルを変更できます。攻撃者はCarbonatoを通じてモデルを切り替え、同じツールと実行環境を使い続けました。
- AIを活用した攻撃の検出には、複数のシステムにまたがる可視性が必要です。このオペレーションはDockerにとどまらず、データベース、監視プラットフォーム、アプリケーションサービスも標的にしました。個別のセキュリティアラートでは見逃し得る攻撃を捉えるには、コンテナ、ホスト、ネットワーク、アプリケーションの活動を関連付ける必要があります。
分析の詳細（日本語版）は、 こちら の技術解説をご覧ください。
はじめに
本リサーチの 第1部 では、Dockerハニーポットへの攻撃未遂を追跡しました。その結果、Hermes、Carbonatoモデルゲートウェイ、その他の攻撃用ツールを組み合わせた攻撃インフラが外部に公開されていることがわかりました。
攻撃者は、このインフラを使ってどのようにタスクを実行していたのでしょうか。
Hermesのセッションデータベース、エージェントログ、スキルのテレメトリを分析すると、1つの親セッションが29個のワーカーにタスクを委任し、攻撃タスクを実行するとともに、再利用できる攻撃手法をライブラリに蓄積していたことがわかりました。
これらの記録から、指示を受け取る段階から、過去のタスクで使った手法や得られた知見を保存する段階まで、AIエージェントが攻撃オペレーションにどのように組み込まれるのかを詳しく確認できます。
分析の詳細は、技術解説をご覧ください。
1つのAIエージェントが複数のタスクを統括
攻撃者はTelegramを通じてHermesに指示を送りました。Hermesは指示を永続的な親セッションに渡しました。親セッションは会話のコンテキストを保持し、ツールを選択し、個別のタスクを短時間稼働のワーカーに委任しました。
委任を受けたワーカーは、14回に分けて起動された計29個でした。各ワーカーには、公開データベースを調べる、管理インターフェースを確認する、周辺インフラの情報を収集するといった範囲の限られたタスクが割り当てられました。ワーカーは結果を親セッションに返し、別のワーカーに再委任する機能はありませんでした。
多数のワーカーが動いていましたが、作業の大部分は親セッションが処理しました。モデルへのリクエストの約81％は親セッションによるもので、記録に残る「execute_code」の処理もすべて親セッションが実行しました。ワーカーは主に範囲を絞った検索や探索を行い、要約を返しました。
この構成により、攻撃者は各エージェントのコマンドや途中経過を逐一追わずに、1つの会話で複数のタスクを管理できました。
AIモデルと攻撃用ツールは独立して稼働
攻撃者は、AIモデルへのリクエストとツールの実行を分離していました。Hermesは一方のサーバでコマンドや攻撃用ツールを実行し、Carbonatoは別のOpenAI互換エンドポイントでモデルへのリクエストを処理しました。
この構成では、ほかのコンポーネントを再構築せずにモデルを変更できました。Hermesはオペレーションの途中で「modelo2」から「modelo13」に切り替え、親セッション、ゲートウェイのルート、ツール、ワークベンチをそのまま使い続けました。
攻撃能力は特定のAIモデルに依存していませんでした。モデルの切り替え後も、同じ実行環境でツールやワークフローを使い続けることができました。
Hermesが攻撃手法を蓄積し、更新する仕組み
エージェントが作成したスキルパッケージが19個見つかりました。用途は偵察から侵害後の活動まで及びます。ライブラリには使用435回、パッチ430件が記録されており、コマンド、参照資料、指示の更新が含まれていました。
Hermesはタスクの終了後にバックグラウンドレビューを開始し、その結果を使って既存のスキルを更新できます。成功した手法や修正点に加え、誤検出や失敗したアプローチも、後の作業で参照できる知見として記録されました。
たとえば、Dockerを悪用するスキルには、ハニーポット、APIバージョンの不一致、読み取り専用プロキシについてのノートが残っていました。ほかのパッケージには、公開データベース、アプリケーションサービス、インフラの偵察に関する情報が記録されていました。
委任されたワーカーがタスクを終えた後も、得られた知見を引き継げます。親セッションはワーカーの要約を保持でき、スキルライブラリには後のタスクで使える手法が残ります。更新の対象はスキルファイルで、AIモデルの再学習は伴いません。手法を更新する機能はHermesの標準機能であり、攻撃者は特別な手を加えずに利用できました。
Docker以外の標的
発見のきっかけはDockerハニーポットでしたが、攻撃者の活動はほかの公開サービスにも及んでいました。図3のとおり、保全したログには、データベース、監視プラットフォーム、Javaアプリケーション、メッセージブローカー、管理インターフェースなどに関わる活動の証拠が残っていました。
標的や利用可能な攻撃手法の記録だけで、侵害の成否を判断することはできません。そこで、証拠を評価するため、活動を以下の4段階に分けました。
- 能力。ツール、スキル、探索手段のいずれかが利用可能でした。
- 試行。実際のリクエストやコマンドがログに記録されていました。
- アクセス。取得データやツールの出力から、アクセスが確認できました。
- 永続化または収集。追加の痕跡が、アクセスの維持やデータの収集を示していました。
AIを活用した攻撃では、リクエスト、タスク、ツールの利用が重なって大量の記録が残るため、これらの段階を区別して評価することが重要です。
企業や組織がAIを活用した攻撃のリスクを軽減する方法
コンテナ、ホスト、ネットワーク、アプリケーションの各環境で観測された不審な活動を関連付け、防御を強化する必要があります。
- Dockerの管理操作を監視する。無許可のAPIアクセスを制限し、異常なコンテナの作成、実行、削除、イメージ取得を検出したら、アラートを出します。特権モードやホストのファイルシステムのマウントを伴う場合は、特に注意が必要です。
- コンテナとホストの挙動を関連付ける。予期しないDockerソケットのマウント、ホストの名前空間へのアクセス、「nsenter」の実行、SSHで許可されている公開鍵の変更を監視します。特権コンテナやホストのファイルシステムへのアクセスを伴う場合、これらの挙動はより有力な手がかりになります。
- 不審なネットワーク通信を調べる。外部のコンテナレジストリ、非公開のモデルゲートウェイ、メッセージングサービスへの予期しない接続を監視します。無許可のコンテナ操作やプロセスの活動と同時に発生している場合は、特に注意が必要です。
- 公開サービスを横断して関連する活動を探す。データベース、監視プラットフォーム、管理インターフェース、アプリケーションサービスへの異常なアクセスを突き合わせます。一見無関係なシステムへの活動も、同じオペレーションの一部である可能性があります。
結論
今回の調査では、攻撃者がAIエージェントを使い、従来の攻撃用ツールを統括し、タスクを委任し、再利用できる攻撃手法を蓄積していたことがわかりました。永続的な親セッション、短時間稼働のワーカー、更新を重ねるスキルライブラリを組み合わせることで、異なるタスクやサービスをまたいでコンテキストと手法を引き継いでいました。
この調査結果からは、AIが攻撃の成功率を高めたかどうかまでは判断できません。一方、AIエージェントフレームワークによって攻撃活動を統括し、作戦で得た知見を蓄積できることが確認されました。防御側は、コンテナ、ホスト、ネットワーク、アプリケーションの証拠を関連付け、一連の攻撃を特定して、その影響を評価する必要があります。
分析の詳細（日本語版）は、 こちら の技術解説をご覧ください。
参考記事：
By: Alfredo Oliveira , Nelson William Gamazo Sanchez
翻訳：与那城 務（Platform Marketing, TrendAI™ Research）