Microsoft Threat Intelligenceは、AIの運用に関連する3つの環境を標的とした攻撃について、広範な分析を提示している。対象は、LiteLLMゲートウェイ、文書処理と検索拡張生成を行うRAGFlowプラットフォーム、そしてワークフローをオーケストレーションするKestra環境である。侵害経路は異なっていたものの、攻撃者の目的はほぼ共通していた。認証情報の窃取、永続的なアクセス手段の設置、そして暗号資産マイニングへの利用を目的としたコンピューティングリソースへのアクセスである。
この3件が重要なのは、攻撃者がこれらのツールを単なる個別のアプリケーションとして扱ったのではなく、認証情報、モデルプロバイダーとの通信、コマンド実行機能、データベースやコンテナーへのアクセスが集約される制御ポイントとして標的にした点にある。Microsoftによれば、この集中により、AIゲートウェイや管理・オーケストレーションプラットフォームは、企業環境内で高価値な標的となる。
3つの侵害経路、共通する結果
LiteLLMのケースでは、Microsoftは初期アクセスが、外部に公開されたゲートウェイの悪用によって行われた可能性が高いと高い確度で判断している。記事では、LiteLLM MCP stdioのテストエンドポイントにおける認証済みコマンド実行に関連するCVE-2026-42271など、公開されている脆弱性経路に言及している。また、StarletteにおけるHostヘッダー検証回避の脆弱性であるCVE-2026-48710と関連付ける調査経路も示されている。この組み合わせにより、影響を受ける構成では、正しい認証情報なしでリモートコード実行が可能になる場合がある。
侵害後、マルウェアはコンテナー内の主要プロセス環境を読み取り、/proc/1/environを含めて、モデルプロバイダーのキー、LiteLLMのマスターキー、データベース接続文字列、パスワード、トークンを探した。その後、Linuxサービスを装った実行ファイルをダウンロードし、ホスト、ポート、プロセスを調査して、XMRigまたはRandomXを利用したマイニングを準備した。また、PostgreSQLの接続文字列を使ってLiteLLMのテーブルにアクセスし、モデル設定、プロバイダーのキー、プロキシが発行したデフォルトキーを取得した可能性がある。永続化の手段には、サービスアカウントのauthorized_keysファイルの変更、cronジョブの変更、隠しファイルや偽装したサービス名の利用が含まれていた。
RAGFlowでは、観測された活動の中心は、テナントが追加または変更した大規模言語モデルの認証情報の傍受だった。Microsoftはまず、SSRFリクエストに似た挙動を確認し、続いてFlaskサービスのコンテキスト内でのコマンド実行と、隠しフックを読み込むためのアプリケーション起動経路の変更を確認した。このフックは、プロバイダーの種類、モデル名、APIキーの内容、エンドポイント情報を取得して外部へ送信した。記事は、実行を引き起こした脆弱性をMicrosoftが高い確度で特定していないことを強調している。CVE-2026-45312、CVE-2026-28797、CVE-2026-24770、CVE-2025-68700は、確定した原因ではなく、技術的に考えられる背景として挙げられている。
Kestraでは、認証を回避し、Process runnerを使う悪意あるワークフローを定義したうえで、ワーカー上でシェルコマンドを実行できる重大な脆弱性CVE-2026-49869に関連していた可能性が高いと、Microsoftは高い確度で判断している。この経路は、Dockerソケットへのアクセス、コンテナー環境の調査、マイニングワーカーの展開、ファイルを隠すための処理に利用された。その後、ワークフロータスクを使ってリモートスクリプトを取得し、直接実行するとともに、Kestra独自のキーバリューインターフェースを通じて暗号化された出力を保存した。
防御チームにとって実際に何が変わるのか
最も重要な結論は、リスク評価を組織内におけるAI環境の役割から始めなければならないという点である。ゲートウェイはモデルプロバイダーのキーやデフォルトキーのデータベースを保管している可能性があり、RAGプラットフォームにはテナント設定が含まれる場合がある。また、ワークフローエンジンにはコマンドを実行し、外部サービスとやり取りする権限が付与されている可能性がある。そのため、製品ごとの検知指標を個別に適用するだけでは不十分である。
Microsoftは、AIゲートウェイを最上位レベルの秘密情報ストアとして扱い、LiteLLMや類似ツールを更新し、APIと管理インターフェースに認証を強制し、管理ポートを制限してインターネットに直接公開しないよう推奨している。また、チームごとに個別の仮想キーを使用して支出上限を設定し、プロバイダーのキーをプロセス環境変数ではなく管理された秘密情報ストアに保存し、漏洩した可能性のあるキーをローテーションすることも推奨している。
その他の対策には、ゲートウェイとデータベースへの最小権限の適用、データベースを限定的なファイアウォールの背後にあるプライベートエンドポイントへ配置すること、デフォルトで接続を拒否し必要なエンドポイントだけを許可する送信ネットワークルールの適用が含まれる。/proc/1/environへのアクセス、ゲートウェイプロセスからのshell、Python、ダウンロードツールの起動、cronやSSHファイルの変更、Dockerソケットの利用、書き込み可能な一時パスからの実行も監視すべきである。
推論の限界とレビューのポイント
この3件は、LiteLLM、RAGFlow、Kestraのすべての展開が同じ方法で影響を受けることを証明するものではない。またMicrosoftは、一部の経路で確認された脆弱性と、RAGFlowのケースで考えられる脆弱性を明確に区別している。さらに、一部のマルウェアに補助ツールや生成ツールの利用を示唆する特徴が存在しても、それは出所や開発者の身元を示す証拠ではない。したがって、これらの結果は特定の攻撃者に攻撃を帰属させるためではなく、検知仮説の構築と設定のレビューに利用すべきである。
Microsoftは、ゲートウェイによるインタープリターやダウンロードツールの起動、主要プロセスの環境変数の読み取り、LiteLLMテーブルへのアクセス、書き込みを有効にしたMSRモジュールのロード試行、SSHキーやcronの変更など、行動の連鎖を検知するためのAdvanced huntingクエリを提供している。これらのクエリの実務的な価値は、単一のタイムライン上で関連付けたときに現れる。単独のshellプロセスは管理作業かもしれないが、秘密情報の読み取り、外部通信、一時パスからのファイル実行が組み合わさると、疑わしさのレベルは大幅に高まる。