[レポート] Fire Ant：ハイパーバイザー層を標的とする中国の諜報グループ - CODE BLUE 2025 #codeblue_jp #codeblue2025

あしざわです。

本記事はCODE BLUE 2025で行われた以下のセッションのレポートです。

セッション情報

仮想化プラットフォームは長らく企業インフラの中核を担ってきましたが、いまや国家レベルのスパイ活動グループにとって新たな遊び場となっています。かつてランサムウェア攻撃者にとって「最大の被害をもたらすゴール地点」と見なされていたものが、現在では永続化、権限昇格、そして秘匿性の高い横展開のための「高速道路」へと進化しています。本セッションでは、Sygniaがいくつかのインシデント対応の現場で追跡した中国系の脅威アクター「Fire Ant」に関する詳細なケーススタディを紹介します。発表はまるでテクニカル・スリラーのように展開し、ゲストVM内での不可解なアラートから始まり、調査員をハイパーバイザー、さらにはその先へと導きます。

私たちは、Fire Antがどのようにして以下を行ったのかを詳述します：

vCenterおよびESXiの脆弱性を悪用し、永続的なバックドアを設置
PowerCLIを乱用し、ハイパーバイザー層からゲストVM内でコマンドを実行してエンドポイント防御を回避
ESXiのログを無効化し、調査者の目をくらます
インベントリシステムから見えない隠し不正VMを展開
侵害したVMにパブリックIPを割り当て、インターネットに直接さらされる侵入拠点へと変貌させる
ルートキットを含む高度なステルス技術を駆使し、対応作業中であってもレジリエンスを維持
さらに本プレゼンテーションでは、Fire Antの戦術を明らかにするだけでなく、我々が用いた調査手法についても解説します。NetFlow、ARPテーブル、PowerCLIスキャンを相関させ、通常なら見逃される攻撃者の活動を暴いたアプローチを紹介します。

参加者が得られるものは以下です：

ハイパーバイザー層におけるスパイ活動の技術的青写真
監視されていないインフラに対する実践的な検知・調査手法
国家レベルの適応型アドバーサリに直面したとき、インシデント対応がどう進化すべきかという戦略的な教訓
これは、ハイパーバイザーの下でAPTと戦う現実を、インシデント対応の最前線から伝える貴重な一幕となります。

Speakers: Asaf Karman, Sygnia シンガポール インシデントレスポンス チームリーダー

レポート

Sygniaについて

• EDR、脅威ハンティングサービス、インシデントレスポンスの3つの主要サービスを提供
• 中核となる専門知識はインシデントレスポンス
• 本日は過去数年間で最も魅力的な調査の1つ、『「Fire Ant」として知られる脅威アクター』ついて説明

Fire Antとは

• 中国の国家支援を受けた脅威アクターグループ
• APAC地域の重要インフラ組織を標的
• MandiantがUNC3886として追跡している脅威アクターとの間に強い脅威インテリジェンスの重複がある
• VMware提供の仮想化インフラストラクチャに関して最も専門性を持つ
• エコシステム全体を作成し、デバイスを最大限に活用
• 最大の特徴：調査活動にリアルタイムで適応する能力と、クライアントネットワークで確立した高いレベルのレジリエンス

背景

• 現在ほとんどの組織が持つ可視性の特性
  • 多くの組織はエンドポイントやサーバーなど従来のデバイス監視については優れている
• 問題点
  • スイッチ、ファイアウォールアプライアンス、WAF、NASデバイス、vCenter、ESXiアプライアンスなど非伝統的デバイスの監視状況は非常に悪い
  • これらはEDRソリューションがサポートしないすべてのデバイス
  • 監視されていないにもかかわらず、すべての組織のコアインフラストラクチャの一部
• 結果
  • 脅威アクター、特に国家支援型脅威アクターにとって理想的な遊び場になっている
  • 環境内に非常に長期間の永続性を維持可能

ESXiホストとサイバーセキュリティの歴史

• 2023年初頭、ESXiランサムウェアの台頭で初めてサイバーセキュリティの文脈で注目
• ランサムウェアギャングがESXiホストを標的にした2つの主な理由:
  • 1つのESXiホストを暗号化することの潜在的影響が非常に高い
  • 監視されていないデバイスである
• 従来: ESXi自体はサイバーキルチェーンの最終ライン（ゴール地点）
  • 暗号化フェーズにのみ関与
• 現在: サイバーキルチェーンのより早い段階でESXiホストとやり取り
  • 理由: 監視されていないデバイス + インフラのコアコンポーネント
  • 提供する機能: 永続性、特権昇格、ラテラルムーブメント
• ランサムウェアギャングもESXiをより早い段階で使用
• Fire Antのような国家支援型脅威アクターはESXiを最大限に活用

インシデントの発端

• 最初のアラート: vm-toolsd.exeがPowerShellコマンドを実行
  • vm-toolsd.exe: ゲスト仮想マシンにインストールされているVMwareツールデーモン
  • コマンド出力がrc.logというファイルにリダイレクト
  • これらの事実から、脅威アクターがPowerCLI（VMwareが管理者向けに提供する管理ツール）を活用していると判断
  • PowerCLI内のInvoke-VMScript機能を使用してゲスト仮想マシン上でPowerShellコマンドを実行
  • コマンド内容から脅威アクターの活動と判断（正当な活動ではない）

攻撃元の特定

• Invoke-VMScriptの仕組み
  • 脅威アクターはまずvCenterまたはESXiホストに対して認証が必要
  • 認証したという事実 = ESXiまたはvCenterホストに証拠が存在
• ミニプレイブック（攻撃元検出方法）
  • 影響を受けたゲスト仮想マシンを対応するESXiおよびvCenterホストにマッピング
  • これらのデバイスで認証ログを探す
  • 認証ログの中でPowerCLIユーザーエージェントを含む認証ログを検索
  • 認証イベントとゲスト仮想マシンで実行されたコマンドを相関
  • 相関関係確立後、PowerCLIコマンドの発信元を理解可能
• 認証ログから得られる情報
  • vCenterに認証するために使用されたユーザー
  • リクエストが発信されたソースIPアドレス
• IPアドレスからデバイス特定
  • 認証ログで発見したIPアドレスがどのデバイスに割り当てられているか調査
  • F5 BIG-IPデバイスの管理インターフェースに割り当てられていた
  • このデバイスはサードパーティベンダーネットワークからクライアントインフラへのトラフィック処理を担当
  • トラフィックがデバイス自体の管理インターフェースから発信 = 正当なトラフィックではない
• これらのデバイスが侵害されていたことがわかった

F5 BIG-IP侵害の詳細

• サードパーティベンダーネットワーク上に脅威アクターの永続性が存在
  • このアプライアンスを介してトンネルを掘り、クライアント環境のESXiホストに到達
• 侵害内容
  • Remote Code Execution (RCE) 脆弱性の悪用
  • 2組のWebシェルをF5 BIG-IPアプライアンスにアップロード
    • シェルファイルアップロード機能のみの限定的なWebシェル
    • 第1のWebシェルを使用してアップロードされるより洗練されたトンネリング機能を含むWebシェル

Fire Antと判明した根拠

• インジケーターの組み合わせ
  • 2つの異なるネットワーク間をジャンプ
  • ネットワークアプライアンスの侵害
  • ネットワークアプライアンス自体でのゼロデイ脆弱性悪用
  • PowerShellコマンドの使用
• 非常に洗練された脅威アクターに直面していることに気づく
• 2025年初めから、Fire Antによって実行された複数の異なるオペレーションに対処している

Fire Antの攻撃キャンペーン

• vCenterへの足場確立
  • 非認証Remote Code Execution脆弱性を使用
  • vCenterにバックドアを展開
  • バックドアの機能
    • リモートコマンド実行
    • ファイル転送
• VPXユーザー認証情報の抽出
  • vCenterへのアクセス取得後、VPXユーザー認証情報を抽出
  • VPXユーザー: vCenterが他のすべてのESXiホストを管理するために使用するユーザー
• ESXiホストへのラテラルムーブメント
  • VPXユーザーを使用してすべてのESXiホストへラテラルムーブメント
  • VIB（vSphere Installation Bundles）メカニズムを使用して追加バックドアをインストール
• ゲスト仮想マシンへの攻撃
  • ESXiホスト上のバックドア設置後、ESXiホストに直接接続可能
  • ESXiホスト上のVMXプロセスに対する追加脆弱性を悪用
  • ゲスト仮想マシン上で非認証Remote Code Executionを実行
• 結果
  • 仮想化インフラストラクチャのすべてのコンポーネントに足場を確立
  • 非常に高いレジリエンスを提供

VIB（vSphere Installation Bundles）の詳細

• 目的
  • VMwareが提供する正当なメカニズム/機能
• 理由
  • ESXiホストのオペレーティングシステムは揮発性
  • 管理者がESXiホストにソフトウェアを永続化させるにはこのメカニズムが必要
• 3つの主要コンポーネント
  • VIBペイロード
    • VIBによって実行される実際のバイナリ
    • Fire Antはここに実行されるバックドアを挿入
  • XML記述子
    • VIBの構成ファイル
  • 署名ファイル
    • VIB全体の信頼性を検証
• Fire Antの悪用方法
  • VIB展開時に--force引数を使用
  • この検証メカニズムを効果的にバイパス
  • VIBを使用してバックドアを展開可能に

認証情報ダンプ技術

• 手法
  • ESXiホスト自体に足場があるという事実を悪用
• プロセス
  • ゲスト内の仮想マシン（特にドメインコントローラー）のメモリスナップショットを取得
  • スナップショット取得時、デバイスのメモリダンプも確実に取得
  • Volatility（有名なメモリフォレンジックフレームワーク）のコンパイル版を使用
  • メモリダンプに対してhashdumpおよびlsadumpモジュールを実行
  • スナップショットを削除して痕跡を隠蔽
• EDR回避の仕組み
  • 活動がESXiレベルで発生
  • エンドポイントにインストールされているEDRを効果的にバイパス
  • エンドポイントのEDRにはこの活動の可視性がない

侵害範囲の特定

• APT攻撃調査の重要要素
  • 侵害範囲の特定（スコーピング）
• 理由
  • 脅威アクターはクライアントネットワークに非常に長期間永続
  • 環境内に多くの異なる足場を保持
  • すべてを確実にカバーする必要
• 対応方法
  • PowerShellスクリプトを作成
  • 環境内のすべてのvCenterとESXiホストに対して実行
  • 侵害されたデバイス数の把握が目的
  • 侵害されたデバイスのリストを取得

根絶と修復

• アクセス制限
  • サードパーティベンダーネットワークからクライアント環境へのアクセスを制限
• バックドア削除
  • ESXiホストとvCenterからすべてのバックドアを削除
• 永続化メカニズムの削除
  • Fire Antが実行した異なる永続化メカニズムを削除
• ファイアウォール制限
  • ESXiホストとvCenterへのアクセスをローカルファイアウォールルールで制限
  • ホワイトリストに登録されたジャンプホストからのアクセスのみに制限
• 結果
  • 修復、根絶、強化の取り組み完了、Fire Antの排除完了と判断

Fire Antの再侵入

• 2日後にアラート再発
  • 真夜中にvm-toolsd.exeがPowerCLIを実行
  • PowerShellコマンド実行のインジケーター
  • Fire Antが再びクライアントネットワークに存在
• 初期対応
  • プレイブックを使用して調査可能と判断
  • 手順
    • ゲスト仮想マシンをマッピング
    • ESXiおよびvCenterホストにマッピング
    • 認証ログ検索
    • PowerCLIユーザーエージェント検索
    • 認証ログとコマンド実行の相関
    • 攻撃元特定

再侵入時の新たな課題

• ESXiホストに認証ログが存在しない
  • 調査の結果、Fire AntがESXiホスト上でvmsyslogdプロセスを積極的に停止
  • vmsyslogd: デバイスのホストログを担当するプロセス
  • 新たな監視メカニズムの必要性
    • アウトオブバンド型の監視が必要
    • NetFlowを採用
      • ESXiホストへのトラフィックをルーティングする関連スイッチでNetFlowを設定
      • ESXiホストに向けて開始されるネットワークトラフィックの監視機能
      • PowerShellコマンド実行時 → ESXiホストへのトラフィック発生
    • 次回Fire AntがPowerShellコマンド実行時、調査すべきソースIPを取得する
• IPアドレス特定が困難に
  • 通常はソースIPをデバイスに紐付け
  • 調査時の試行
    • クライアントが持つすべてのインベントリで検索 → どこにも見つからない
    • EDRを活用して検索 → 見つからない
    • ネットワークスキャン、Ping実行 → どこにも見つからない
  • 組織内でIPアドレスを見つけることは通常時間のかかるタスクではない
  • 脅威アクターによるIP操作の可能性

MACアドレスへの転換

• IPアドレスからMACアドレスに焦点を移行
• MACアドレス調査のプロセス
  • 関連するスイッチからARPテーブルを抽出
  • 追跡中のIPアドレスのリストでMACアドレスを紐付け
  • IPアドレスを対応するMACアドレスに紐付け
  • MACアドレスのリストでMACベンダー検索を実行
• 追跡中のすべてのIPがVMware製品だとわかった
• Fire Antが仮想化インフラストラクチャに非常に強力な足場を持つことから、完全な仮想マシンを追跡していると判断

仮想マシンの特定

• Fire Antが使用しているすべての仮想マシンを特定
  • MACアドレスのリストを取得するPowerShellスクリプトを作成
  • すべてのvCenterとESXiホスト全体でMACアドレスを検索
• 結果
  • シナリオ1:MACアドレスに紐付けられた仮想マシンを発見可能
    • 後で調査実施
  • シナリオ2:クライアントのネットワークで特定できないMACアドレスのセットが残存

隠された仮想マシンの発見と検出

• 完全に機能している仮想マシンがどのインベントリにもリストされていないことは可能か？
  • 一方で、これらのMACアドレスがPowerShellコマンドを開始している証拠がある
  • 他方で、vCenterのどのインベントリにもリストされていない
• 答えは可能である
• Fire Antの手法：完全に隠された仮想マシンをスピンアップ
  • 条件
    • ESXiホストへのSSHアクセス
    • このESXiへのroot権限
    • 特定の方法で仮想マシンを実行/スピンアップ
  • 結果
    • 完全に機能する
    • ESXiホストインベントリにリストされない
    • vCenterインベントリにリストされない
    • vCenterの既存インベントリを偵察するための一般的なAPIコールや関数にもリストされない
  • これがスクリプト使用時にもリストに表示されなかった理由
• 隠された仮想マシンの検出方法
  • プロセスリストの確認
    • ESXiホスト上のすべての実行中プロセスをリスト化
    • -x引数を持つVMXプロセスを探す
  • プロセス数の比較
    • インベントリに表示される仮想マシンのリストを取得
    • ESXiホスト上のVMXプロセス数と比較
    • 各VMXプロセスは仮想マシンを表すべき

主要な教訓（Key Takeaways）

• 従来のエンドポイント監視だけでは不十分
  • 現時点では、従来のエンドポイントのみを監視するだけでは不十分
  • 非伝統的なエンドポイント、アプライアンス、ネットワークデバイスを標的とする脅威アクターが増加
  • これらのデバイスを監視し、不正な活動を検出する機能を確保
• IRチームの能力要件
  • 内部チームまたは外部プロバイダーを利用するかにかかわらず必要な能力
    • これらのデバイスからデータを収集する能力
    • 調査する能力
    • 対応する能力
• APTグループの特性
  • APTグループは社内リソースを多用
  • 非常に創造的
  • 調査チームによって行われるリアルタイムの活動に非常によく適応

感想

Fire Antの事例を通じて、洗練された脅威アクターの攻撃手法の巧妙さ、秘匿技術の高さを知りました。

Key Talkawayにもあるように、このような攻撃に対しては従来のエンドポイント型セキュリティでは全く歯が立たないと思いました。私が当事者として恒久対策をするなら、多層防御・ゼロトラスト・デバイスの監視による可視化など考えられること全てを実装しないと立ち向かえないなと思いました。もちろん、専任のインシデント対応チームも必須ですね。

ここまで高度なセキュリティ対応の経験はありませんが、基本的なセキュリティの実装と運用の重要さを再認識しました。