利便性を超えたリスク: VMware vSphere Active Directory 統合の危険性の顕在化

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

エグゼクティブ サマリー

Broadcom の VMware vSphere プロダクトは、プライベート クラウドの仮想化に依然として広く利用されており、重要なインフラストラクチャを支えています。vSphere は、安定性と制御の面で組織に大きく貢献しており、その重要性は高まるばかりです。また、 Mandiant は、重要なワークロードがパブリッククラウドサービスからオンプレミスの vSphere環境へ回帰する明確な傾向を観察しています。この傾向は、イノベーションと安定性のバランスを重視する戦略や、より直接的な運用管理の必要性から生じている場合が少なくありません。

vSphere を Microsoft Active Directory（AD）と直接統合する一般的な手法は、管理タスクを簡素化する一方で、現存のリスクを誤解しているために見逃されがちな攻撃経路を生み出します。この構成では、AD の攻撃対象領域がハイパーバイザまでつながってしまいます。脅威アクターの観点からすると、この統合は格好の機会です。AD 認証情報の漏えいという比較的よくある行動が、潜在的価値の高いシナリオに変わります。サーバーをホストする基盤インフラストラクチャへのアクセスが許可され、その結果、ESXi ホストと vCenter の管理制御権限を取得し、最終的には仮想化インフラストラクチャを完全に制御できるようになります。

ESXi ホストと vCenter Server の両方を含む vSphere インフラストラクチャを標的としたランサムウェアは、インフラストラクチャを即座に広範囲にわたって麻痺させる可能性があるため、特に深刻なリスクをもたらします。Mandiant の調査によると、大多数の組織が vSphere 7.x バージョンを運用していますが、2025 年 10 月にこの一般サポートが終了することを受け、標的型ランサムウェアの脅威が喫緊の課題となっています。このような攻撃からの復旧には多大な時間とリソースが必要となるため、事前の防御が最も重要です。そのため、組織はこれらのコア コンポーネントに対する具体的な脅威を理解し、効果的かつ統合された対策を実装して、サポートの期限切れによるリスクが加わる前に侵害を防ぐことが重要です。

このブログ投稿では、vSphere と Microsoft AD の統合に伴う固有のリスクと誤解を論理的に分析します。Mandiant の vSphere ランサムウェア インシデントと AD および vSphere の事前評価に関する豊富な経験を活かし、企業における vSphere 管理に関して、リスクを理解し、今日の脅威に合わせたセキュリティ ポスチャーを向上させるための指針を提供します。

リスクについて学んだら、次のブログ投稿でVMware vSphere 環境を防御するための実用的なガイダンスをご覧ください。また、今後のウェブセミナーに登録して、Mandiant のエキスパートから直接これらの戦略を学びましょう。

vSphere インフラストラクチャの概要

vSphere 環境のセキュリティ リスクを理解するには、そのアーキテクチャを理解することが不可欠です。1 つのレイヤで侵害が発生すると、仮想化環境全体に連鎖的な影響が及ぶ可能性があります。

vSphere は、コンピューティング、ストレージ、ネットワーキングなどの物理データセンター リソースを柔軟な仮想インフラストラクチャ レイヤにプールするプラットフォームです。このタスクは、主に ESXi と vCenter という 2 つの主要コンポーネントによって実行されます。次の図をご覧ください。

• ESXi（ハイパーバイザ）: vSphere の基盤となるレイヤです。ESXi はベアメタル ハイパーバイザです。つまり、基盤となるオペレーティング システムを必要とせずに、物理サーバー ハードウェアに直接インストールされます。その主な役割は、サーバーを複数の独立した仮想マシン（VM）に分割することです。各 VM は、基本的にはファイルの集まりにすぎませんが、独自のオペレーティング システムとアプリケーションを実行し、独立したコンピュータのように動作します。ハイパーバイザは意図的に最小限の設計となっており、サーバーのリソースを効率的に管理しながら、ハイパーバイザ自体の攻撃対象領域を縮小することを目的としています。

• vCenter（コントロール プレーン）: ESXi ホストが「作業者」であるとすると、vCenter Server は環境全体の「頭脳」、すなわちコントロール プレーンになります。接続されているすべての ESXi ホストと、それらのホストで実行される VM を管理するための単一のウェブベースのインターフェースが提供されます。ESXi ホストは vCenter に登録されます。vCenter は各ホストのエージェントを使用して、オペレーションを管理し、自動ワークロード バランシングやフェイルオーバー保護のための高可用性などの高度な機能を有効にします。

vSphere と AD を統合すると、ID 管理が簡素化された柔軟な環境が作成されますが、重大なセキュリティ リスクも発生します。この直接リンクにより、AD の侵害が vSphere デプロイ全体に対する重大な脅威に変わる可能性があります。

時代遅れのブループリント: vSphere の基本的なセキュリティを再検討する

仮想化は、20 年近くにわたって企業 IT の基盤として、サーバーの乱立を解消し、運用上のアジリティを大きく向上させてきました。AD は、エンタープライズ IT の柱として引き続き重要な役割を果たしています。そのため、vSphere などの重要なインフラストラクチャを含むすべてのエンタープライズ テクノロジーは、一元化された認証のために AD と統合する必要があるという長年の指示につながっています。その結果、リスクの高い依存関係が生じます。基盤となるインフラストラクチャのセキュリティが AD のセキュリティに直接結び付けられるため、AD 内の侵害は仮想化環境全体に対する直接的な脅威となります。

これまで、vSphere のセキュリティは、サイロ化された別々のレイヤで対処されることが多くありました。境界セキュリティは厳格で、脅威は通常、外部の脅威アクターではなく、構成エラーなどの内部のものと見なされていました。これに、画像ベースのバックアップが容易になったことが加わり、セキュリティ対策は、事前防御よりも堅牢なビジネス継続性と障害復旧機能に重点が置かれることが多くなりました。環境が拡大するにつれて、ローカル ユーザー アカウントの管理が大きな管理オーバーヘッドを生み出したため、一元的な ID 管理のために AD 統合のサポートが導入されました。

多くの vSphere 環境が現在もこの基本的なアーキテクチャで運用されており、進化する脅威の状況に追いついていないセキュリティの前提を引き継いでいることが、Mandiant の広範なインシデント対応業務で確認されています。Mandiant の評価で頻繁に特定されているように、これらのアーキテクチャでは、現在の脅威に基づいたセキュリティ設計よりも、機能と安定性が優先されることがよくあります。

では、何が変わったのでしょうか？境界防御のみに頼ることは、時代遅れのセキュリティ戦略です。最新のセキュリティ境界はユーザーとデバイスに焦点を当てており、通常はエージェントベースの EDR ソリューションによって保護されます。しかし、ここに重大なギャップがあります。多くの人が誤解していますが、ESXi ハイパーバイザは専用のアプライアンスであり、標準的な Linux ディストリビューションではありません。この特殊なアーキテクチャは、EDR エージェントなどのセキュリティ ツールを含む外部ソフトウェアのインストールを本質的に防止します。vSphere のドキュメントでは、この点について次のように明白にしています。

そのため、ほとんどの組織は、ゲスト オペレーティング システム内でセキュリティ対策と EDR のデプロイに注力しています。これにより、仮想化環境全体の基盤となる ESXi ハイパーバイザが、セキュリティ チームにとって大きな盲点となります。

vSphere の脅威の状況

前のセクションで詳しく説明したハイパーバイザ レイヤのセキュリティ ギャップには、脅威アクターもすでに気づいています。高度な EDR ソリューションによって Windows ベースのオペレーティング システムのセキュリティが成熟するにつれ、脅威アクターはより脆弱で価値の高い標的である ESXi ハイパーバイザ自体に軸足を移しました。

この方向転換は、一般的な運用上の現実によって増大されています。ESXi ホストは重要な役割を担っているため、中断を恐れてパッチを迅速に適用することをためらうことがよくあります。多くの組織は、リスクを軽減するための猶予期間が急速に短くなっている状況に直面しています。しかし、脅威アクターはパッチが適用されていない脆弱性だけに依存しているわけではありません。攻撃者は、漏えいされた認証情報、MFA の欠如、単純な構成ミスを頻繁に利用してアクセス権を取得します。

ハイパーバイザを重視したランサムウェアの台頭

vSphere を標的とするランサムウェアは、従来の Windows を標的とするランサムウェアよりも根本的に破壊的です。サーバーやエンドユーザー コンピューティングのファイルを暗号化するのではなく、仮想ディスク ファイル（VMDK）を暗号化してインフラストラクチャ全体を麻痺させ、数十台の VM を一度に無効化することを目的としています。

これは理論上の脅威ではありません。Google Threat Intelligence グループ（GTIG）によると、vSphere に焦点が当てられることが急速に増えています。観測された新しいランサムウェア ファミリーのうち、vSphere ESXi システム専用に調整されたものの割合は、2022 年の約 2% から 2024 年には 10% 以上に増加しました。これは、脅威アクターがハイパーバイザを標的とするツールを構築するためにリソースを積極的に投入しているという、明確かつ加速的な傾向を示しています。GTIG が調査したインシデントでは、脅威アクターが REDBIKE、RANSOMHUB、LOCKBIT.BLACK のバリアントを最も頻繁にデプロイしていました。

GTIG のアナリストは、脅威アクターが Virtual Center にデプロイされたリバースシェルを介して vSphere 環境への永続性を獲得するという最近の傾向も指摘しています。これにより、vSphere コントロール プレーン内に足場を確保し、すべてのインフラストラクチャを完全に制御できるようになります。通常、これは 2 つの側面を持つアプローチとして現れます。1 つは AD データベース（NTDS.dit）などの戦術的なデータ漏洩、もう 1 つはランサムウェアのデプロイとすべての VM の大規模な暗号化です。

vSphere での Active Directory 統合を理解する

vSphere と AD の統合を決定する際、この接続が実際にどのように機能するかという具体的な点がしばしば見落とされます。リスクを適切に評価するには、この機能を可能にする技術的コンポーネントを、表面だけでなくより深層まで確認する必要があります。この分析では、認証を担う従来のエージェントが多要素認証（MFA）などの最新のセキュリティ制御をサポートできないという欠点や、安全でないデフォルトの信頼関係を構築してしまうという、重要な要素を分解します。これらの基本的なメカニズムを調べることで、認証情報の侵害からインフラストラクチャの乗っ取りに至る直接的な流れを明らかにできます。

vSphere の Likewise エージェント

vSphere と AD の統合について説明する際は、vCenter Server と ESXi ホストという 2 つの別々のコンポーネントを区別することが重要です。それぞれの AD 統合オプションは独立しており、機能も異なります。この接続は、Likewise エージェントによって全面的に実現されています。

Likewise エージェントは、Linux および Unix ベースのシステムが AD 環境に参加できるようにするために、Likewise Software によって開発されました。これにより、Kerberos、NTLM、LDAP/(S) などの標準プロトコルを使用して、一元化された ID 管理が可能になります。オープンソース エディションの Likewise Open には、domainjoin-cli などのツールや、lsassd などのシステム デーモンが含まれていました。これらは現在も ESXi と vCenter Server Appliance（VCSA）の内部に存在します。vSphere は、統合 Windows 認証（IWA）を容易にするために、ESX 4.1（2010 年リリース）からこのエージェントを組み込んでいました。ただし、機能は異なります。

• ESXi では、構成されている場合、Likewise エージェントが AD ユーザー認証を積極的に処理します。

• vCenter では、ID ソースとして統合 Windows 認証（IWA）が選択された場合の最初のドメイン参加にのみ使用されます。実際の認証はすべて、vCenter シングル サインオン（SSO）サブシステムによって処理されます。

元の Likewise Software は最終的に BeyondTrust に吸収され、エージェントのオープンソース エディションは現在メンテナンスが公開されていません。Likewise OSS プロジェクトはアーカイブされ、非アクティブとしてマークされています。コードベースは社内でのみ管理されていると思われます。注: エージェントのビルドバージョンは、ESXi 7 と 8 の両方で Likewise Version 6.2.0 と同じです。

次の表に、Virtual Center と ESXi の両方でネイティブ AD 接続方法を比較した結果を示します。

Likewise ベースの AD 統合（ESXi / vCenter）を避けるべき理由

vSphere Likewise エージェントによって管理される AD ベースの接続を使用する際の考慮事項を以下に示します。

• 非推奨ソフトウェア: Likewise はレガシー ソフトウェアであり、上流での保守やサポートが行われなくなっています。

• 最新の認証方法に非対応: Likewise は統合 Windows 認証（Kerberos）のみをサポートし、SAML、OIDC、FIDO2 はサポートしていません。

• MFA 非対応: Likewise では、MFA、位置情報による制限、時間ベースのアクセスなどのコンテキスト ポリシーを適用できません。

• 認証情報のローカル保存: Kerberos keytab とキャッシュされた認証情報が暗号化されずにディスクに保存されます。

VMware は、最新の ID プロバイダとの ID 連携を活用して、 旧式の Likewise ベースのスタックによる制限を回避することを推奨しています。Broadcom は 3 月 25 日に、IWA が削除されることを発表しました。

MFA のギャップ

AD 統合は管理上の利便性をもたらしますが、特に MFA に関して、重大なセキュリティ上の制限が生じます。Kerberos や NTLM などの従来の AD 認証方法は、本質からして一要素認証です。これらのプロトコルはネイティブで MFA をサポートしておらず、vCenter Likewise 統合では、AD MFA の適用が vCenter や ESXi に拡張されません。

重要な点として、ESXi はどのような形式の MFA もサポートしておらず、ID 連携、SAML、OIDC や FIDO2 などの最新のプロトコルもサポートしていません。vCenter の場合でも、MFA は vSphere.local ドメイン内のユーザーにのみ適用でき（RSA SecurID や RADIUS などのメカニズムを使用）、IWA または LDAP/S を介して認証された AD 参加ユーザーには適用できません。

補助ソリューションでは、AD と統合して vSphere に MFA を適用するプロキシベースの MFA を提供できます。AuthLite は、Windows 認証時に 2 つ目の認証要素を要求することで、ネイティブの AD ログイン プロセスを拡張します。これにより、統合 Windows 認証を使用している場合は、vCenter へのアクセスを間接的に保護できます。Silverfort はドメイン コントローラ レベルで動作し、エンドポイントにエージェントを配置したり vCenter を変更したりすることなく、認証フローにリアルタイムで MFA を適用します。どちらのソリューションも、ネイティブで MFA をサポートしていない vSphere 環境に MFA を適用するのに役立ちますが、AD が保護するインフラストラクチャに依存するようになった場合、複雑さの増大や認証ループの可能性などの注意点も生じます。また、コントロール プレーンや仮想アプライアンスを vSphere 環境内のティア 0 システムとして扱う必要もあります。

Active Directory フェデレーション サービス（ADFS）を介して vSphere で MFA を適用することは技術的には可能ですが、このアプローチは慎重に検討する必要があります。ADFS は Windows Server 2025 に含まれる機能であり、サポート終了日が記載された公式の廃止リストには掲載されていません。しかし、Microsoft Entra ID の急速なイノベーションと比較して、新しい重要な機能の開発が不足していることは、そのレガシー テクノロジーとしての地位を物語っています。これは、Microsoft が現在提供している、AD FS から Entra ID へのアプリケーション移行のための豊富なリソースによって裏付けられています。

そのため、ADFS はサポート対象の機能ではありますが、vSphere を保護するという目的においては、ESXi への直接アクセスには適用されず、Microsoft の最新のクラウドベースの ID ソリューションに向けた明確な戦略的方向性と相反する、複雑な回避策となります。

もう一つの一般的なアプローチは、特権アクセス管理（PAM）です。PAM 中心の戦略は、一元管理やセッション監査などのメリットがある一方で、考慮すべき注意点もいくつかあります。PAM システムは運用上の複雑さを増し、vCenter セッション自体は通常、主要なエンタープライズ ID プロバイダ（Entra ID や Okta など）と直接連携していません。そのため、コンテキスト アウェアな条件付きアクセス ポリシーは、通常、PAM の最初のログイン時にのみ適用され、vCenter セッション自体には適用されません。

最終的に、これらの回避策は根本的な問題に対処するものではありません。vSphere が Likewise エージェントと従来の AD プロトコルに依存しているため、AD ユーザーに対するネイティブの MFA の適用が妨げられ、環境が脆弱なままになります。

「ESX 管理者」の問題は ESXi の問題ではなく、信頼の問題である

2024 年 7 月、Microsoft は、重大な問題とみなされた「ESXi の脆弱性」である CVE-2024-37085 に関するブログ投稿を公開しました。この脆弱性については、vSphere がパッチリリースで迅速に対処しました。vSphere ESXi に長年存在していたこの CVE は、安全でないデフォルト構成を利用する複数の ESXi 詳細設定に関連していました。ESXi ホストを AD ドメインに参加させると、「ESX Admins」AD グループに ESXi 管理者ロールが自動的に付与され、管理アクセス権の範囲が意図したユーザー以外にも拡大する可能性があります。

これらの設定は、次の ESXi コントロールによって構成されます。

1. Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd

   1. 機能: この設定は、指定された管理者グループのユーザーがホストのローカル管理者グループに自動的に追加されるかどうかを制御します。

2. Config.HostAgent.plugins.vimsvc.authValidateInterval

   1. 機能: この設定は、ホストの管理サービスが接続されたクライアントの認証情報（またはチケット）を検証する時間間隔を定義します。

3. Config.HostAgent.plugins.hostsvc.esxAdminsGroup

   • 機能: このパラメータは、メンバーが自動的にホスト管理権限の対象となるグループの名前（または ID）を指定します（最初の設定で自動追加が有効になっている場合）。

vSphere では、次の設定に基づいて、vSphere ESXi 8.0 Update 3 の以前のバージョンに対する手動の回避策が作成されました。

以下は、vSphere ESXi 8.0 Update 3 のデフォルト設定に対する構成の修正です。

ESXi ホストを Microsoft AD と統合すると、見落とされがちな根本的なセキュリティ上の問題が発生します。つまり、IdP の管理者が ESXi ホストとその信頼に依存する他のシステムに対する管理制御を事実上獲得することになります。一般的な認識では、エンドポイントに焦点を当てる説明が多く、ESXi ホスト自体が主な脆弱性であるとされています。しかし、より重大なセキュリティ上の懸念は、信頼できる IdP の管理者が行使する暗黙的で広範囲に及ぶ管理権限です。特に、ESXi で AD 認証を使用する場合はそうです。

その結果、ESXi ホストが AD に参加している場合、デフォルト設定を調整するだけの回避策や構成の修正では、この根本的な問題を解決できません。この問題は特定の CVE に限定されるものではなく、暗黙の信頼モデル自体に内在するセキュリティ上の影響に起因しています。特に、ESXi や AD のようなシステムが関与する場合、これらのシステムはすでに独自のセキュリティ脆弱性を抱えており、脅威アクターの標的となることが多いため、問題が深刻化します。

ESXi に関しては、以下の内容にコンテキストを適用する必要があります。

• 自動的な完全管理者アクセス: ESXi ホストが AD に参加すると、デフォルト（またはカスタム構成）の AD グループ（例: "ESX Admins"）には、ESXi ホストに対するルートレベルの完全な管理権限が付与されます。この AD グループのメンバーは、ESXi ホストを無制限に制御できるようになります。

• グループ名: AD が侵害された場合、脅威アクターは Config.HostAgent.plugins.hostsvc.esxAdminsGroup  の詳細設定で指定されたグループ名を 操作できます。これは "ESX Admins" というグループ名に限定されません。

• セキュリティ識別子（SID）の追跡の欠如: ESXi に追加された AD グループ名（"ESX Admins" に限定されない）は、SID で追跡されません。つまり、脅威アクターは、Config.HostAgent.plugins.hostsvc.esxAdminsGroup を介して ESXi で同じ名前を維持しながら、"ESX Admins" などの削除された AD グループの名前を変更したり、再作成したりして、昇格された権限を保持できるということです。これは、Likewise ESXi エージェントの制限事項です。

• Active Directory グループの管理: ドメインに参加している ESXi ホストにアクセスしようとする脅威アクターは、Config.HostAgent.plugins.hostsvc.esxAdminsGroup で定義された AD グループに自分自身を追加するのに十分な権限を要求するだけで済みます。

CVE-2024-37085 などの脆弱性に関する最近の議論は、vSphere ESXi ホストを AD ドメインに直接参加させることによるセキュリティの問題を最前面に押し出しました。このような統合は、管理の利便性をもたらすように見えますが、簡単に悪用される可能性のある信頼レベルを確立します。

ESXi ホストを Active Directory ドメインに参加させるべきではない理由

これまでの議論を踏まえると、ESXi ホストを AD に参加させることは大きなリスクを伴うと断言できます。セキュアブート、TPM、execInstalledOnly、vCenter 統合、包括的なロギング、SIEM 統合などの包括的な ESXi セキュリティ管理がない場合、このリスクはさらに高まります。ESXi に参加しているグループに関連付けられた AD 認証情報が侵害されると、リモートの脅威アクターは、昇格された権限を簡単に悪用し、SSH 経由で仮想マシンのシャットダウンやランサムウェアのデプロイなどのアクションを実行できるようになります。これらのリスクを、次にまとめます。

• MFA 非対応: ESXi では、AD ユーザーの MFA はサポートされません。ドメインに参加すると、重要なハイパーバイザ アクセスが単一要素のパスワード ベースの認証にさらされます。

• 従来の認証プロトコル: ESXi は、IWA と Kerberos / NTLM / Windows セッション認証（SSPI）に依存しています。これらは、パスザハッシュや認証情報の転送など、さまざまな攻撃に対して脆弱な古いプロトコルです。

• Likewise エージェントのサポート終了: 基盤となる Likewise エージェントは、サポートが終了したオープンソース プロジェクトです。引き続き使用すると、メンテナンスとセキュリティのリスクが生じます。

• 最新の認証統合に非対応: ESXi は、フェデレーション ID、SAML、OIDC、FIDO2、条件付きアクセスをサポートしていません。

• AD ポリシーの適用がない: グループ ポリシー オブジェクト（GPO）、条件付きアクセス、ログイン時間制限は、AD 参加を介して ESXi に拡張されないため、一元化されたセキュリティ制御が損なわれます。

• メリットのない複雑さ: ドメイン参加は、特に vCenter をプライマリ アクセス ポイントとして使用する場合、有意義なセキュリティ上のメリットをもたらすことなく、管理オーバーヘッドを増加させます。

• ロール マッピングの粒度が限定的: ESXi のグループベースのロール マッピングは基本的なもので、vCenter で利用できる RBAC の精度に匹敵せず、アクセス制御の忠実度が低下します。

ESXi ホストを AD から安全に削除するには、アクセス管理を明示的に vCenter に移行する多段階のプロセスが必要です。これには、現在の AD の使用状況の評価、詳細な vCenter ロールの設計、vCenter の RBAC の構成、PowerCLI によるドメインからのホストの削除、今後の AD の再統合の防止が含まれます。その後、すべての管理が vCenter に移行され、ESXi への直接アクセスは最小限に抑えられます。この包括的なアプローチでは、ESXi の認証と認可で AD に依存するのをやめ、vCenter を中心としたきめ細かい RBAC モデルに移行することで、セキュリティと効率性を優先します。vSphere では、ESXi ホストを AD に参加させることは明示的に推奨されていません。

vSphere Virtual Center - 主な標的

vSphere vCenter Server は、仮想化インフラストラクチャの一元管理を行う権威ある役割を担っているため、脅威アクターにとって戦略的な標的となっています。vCenter インスタンスが侵害されると、接続されているすべての ESXi ハイパーバイザ、仮想マシン、データストア、仮想ネットワーク構成を含む、仮想環境全体に対する包括的な管理制御が事実上譲渡されます。

広範なアプリケーション プログラミング インターフェース（API）を通じて、攻撃者は管理対象のすべての ESXi ホストとそれらに常駐する仮想マシンをプログラムで操作できます。これにより、ランサムウェアの一括デプロイ、大規模なデータ漏洩、不正な仮想アセットのプロビジョニング、セキュリティ ポスチャーの変更などのアクションが可能になり、検出を回避して広範囲にわたる運用の中断を引き起こすことができます。

さらに、永続的なバックドアを埋め込むことで vCenter Server アプライアンス自体を転覆させ、隠蔽されたコマンド アンド コントロール（C2）チャネルを確立して、根強い永続性と継続的な悪意のある操作を可能にします。そのため、重要な機能を備えた vCenter は、価値の高い標的となっています。次の点を考慮する必要があります。

• セキュリティ依存関係の結合（侵害の拡大リスク）: vCenter を AD に直接リンクすると、vSphere のセキュリティが AD の完全性に依存するようになります。AD は主要な標的であるため、vCenter にマッピングされた特権 AD アカウントが侵害されると、vSphere 固有のセキュリティ レイヤをバイパスして、仮想インフラストラクチャへの即時かつ無制限の管理アクセスが許可される可能性があります。vSphere の AD アカウントに最小権限を十分に適用しないと、このリスクが増大します。

• 単一要素認証の弱点（認証情報の漏洩リスク）: AD パスワードの検証のみに依存すると、vCenter は一般的な認証情報の漏洩方法（フィッシング、ブルート フォース、スプレー、スタッフィング、マルウェア）に対して非常に脆弱になります。MFA が必須でない場合、特権 AD アカウントのパスワードが 1 つ盗まれるだけで、認証を完全にバイパスして、不正アクセス、データ侵害、ランサムウェア、または重大な混乱を引き起こす可能性があります。

• ネイティブ MFA の欠如: vSphere.local と AD の直接統合では、フィッシングに強い FIDO2 のような強力な認証の組み込みの適用は提供されません。外部システム（スマートカード、RSA SecurID）との互換性はありますが、これらには専用のインフラストラクチャが別途必要であり、固有の機能ではありません。実装しないと、認証保証に大きなギャップが生じます。

• ラテラル ムーブメントと権限昇格の促進: AD 認証情報を不正使用すれば、vSphere の権限が最小限の管理者以外の認証情報であっても、脅威アクターは vCenter への初期アクセスができます。その後、vCenter をピボット ポイントとして利用し、ネットワークへのさらなる侵入、仮想環境内での権限昇格、コンソール/API アクセスを介したゲストシステムへの攻撃を行うことができます。これらはすべて、最初の単一要素の認証情報の侵害に起因します。

vSphere vCenter を ID 管理のために AD と直接統合することは一般的ですが、結合された依存関係、単一要素認証への依存、ネイティブの強力な MFA の欠如、攻撃経路の容易化に起因する重大なセキュリティ脆弱性が本質的に発生します。これらは仮想インフラストラクチャを重大なリスクにさらすだけでなく、基盤となる Linux シェルや包括的なエンドポイント検出と対応（EDR）機能の欠如など、VCSA アプライアンスの攻撃対象領域を悪用する手段も提供します。

vSphere の保護: ティア 0 の課題

ティア 0 サービスを vSphere ハイパーバイザ上で直接実行するという一般的な手法は、見落とされがちな重大なセキュリティ リスクをもたらします。その中でも最も重要なのは AD ドメイン コントローラで、多くの場合、直接的な ID 統合に使用されます。Active Directory ドメイン コントローラを vSphere に配置すると、ハイパーバイザに対する攻撃が成功した場合、脅威アクターに AD 環境全体の鍵が渡され、ドメインを完全に乗っ取られる可能性があります。Mandiant は、全般的に認識と事前対策が不足している状況が続いていることを確認しています。

たとえば、リスクが低いと思われる vSphere 権限や、運用上一般的な権限であっても、危険性は十分に存在します。たとえば、AD 仮想マシンをスナップショットする権限は、AD を完全に乗っ取るために悪用される可能性があります。この vSphere の機能は、多くの場合バックアップ ルーチンに割り当てられ、オフラインの NTDS.dit（AD データベース）のデータ漏洩を可能にします。この vSphere レベルのアクションにより、ゲスト内の Windows Server のセキュリティ管理の多くが無効になり、強力なパスワードや MFA などの従来型の対策だけでなく、主にオペレーティング システム内のアクティビティを監視する LSASS 認証情報ガードや EDR などの高度な保護もバイパスされます。この特定の権限を持つ脅威アクターは、事実上、ドメインを完全に侵害するための直接的なルートを確保できます。

Mandiant は、複数のインシデントでさまざまなランサムウェア グループに起因するこれらの戦術、手法、手順（TTP）を確認しました。VM の暗号化とロギングがない場合、検出されずに AD データベースを取得するのは比較的簡単な作業です。

次の表に、関連する権限と一致する脅威のサンプルを一覧表示します。

vSphere vCenter から AD への信頼の委任により、信頼されたシステムに対する暗黙の管理者権限が、AD ドメイン管理者に付与されます。これにより、AD 侵害のリスク プロファイルが上昇し、インフラストラクチャ全体に影響が及びます。これを軽減するために、2 つの側面からなる戦略を実装します。まず、AD を含む最も重要なティア 0 アセット専用の vSphere 環境を別途作成します。この隔離された環境は、他のシステムから物理的または論理的に分離され、堅牢なネットワーク セグメンテーションによって高度に保護されている必要があります。2 つ目は、この環境のコントロール プレーンにゼロトラスト セキュリティ モデルを実装し、ソースに関係なくすべてのアクセス リクエストを検証することです。この分離された環境内に、専用の「インフラストラクチャのみ」の IdP（オンプレミスまたはクラウド）をデプロイします。最小権限の原則を実装することが最も重要です。

ティア 0 アセット（例: Active Directory）は、管理アクセス（PAW 経由）を厳しく制限し、インフラストラクチャを直接管理するユーザーにのみ権限を付与する必要があります。これにより、ラテラル ムーブメントを防止し、被害を最小限に抑えることで、侵害の影響を大幅に軽減できます。環境のセキュリティを維持し、最小権限モデルを遵守するため、不要な統合は避ける必要があります。

vSphere 環境内で動作する重要なティア 0 アセット（具体的には、特権アクセス管理（PAM）、セキュリティ情報およびイベント管理（SIEM）仮想アプライアンス、仮想アプライアンスとしてデプロイされた関連する AD ツールなどのシステムなど）を効果的に保護するには、多層防御のアプローチが不可欠です。これらのアセットは、独立した自己完結型の環境として扱う必要があります。これは、ネットワーク トラフィックと運用上の依存関係を分離するだけでなく、認証と認可のプロセス専用の完全に分離された ID プロバイダ（IdP）を実装することを意味します。最高レベルの保証を実現するには、これらのティア 0 仮想マシンを専用の物理サーバーで直接ホストする必要があります。物理的および論理的な分離というこの手法により、共有仮想化環境よりもはるかに高いレベルの分離が実現します。

ここでの主な目的は、認可の依存関係チェーンを断ち切り、ネットワークの他の場所で侵害された認証情報や権限を利用して、これらのティア 0 システムにアクセスできないようにすることです。この設計により、多層防御のセキュリティ バリアが構築され、システム全体が侵害される可能性と影響が根本的に軽減されます。

まとめ

Mandiant は、脅威アクターが vSphere を標的にするケースが増えていることを確認しています。その目的は、ランサムウェアのデプロイだけでなく、データ利用とデータ引き出しの重要な手段として vSphere を利用することです。この変化は、GTIG が最近観測した脅威アクターの活動に表れています。攻撃者は、侵害された vSphere 環境を利用して、ランサムウェアの実行前または実行と並行して、AD データベースなどの機密データを引き出しています。

このドキュメントで詳しく説明したように、vSphere が広く利用されていることと、AD との統合に固有のリスクが過小評価されがちであること、安全でないデフォルト構成が存続していることが組み合わさって、危険なほど脆弱な状況が生み出されています。脅威アクターは、こうした脆弱性を認識しているだけでなく、ESXi と vCenter を標的とする高度な攻撃を積極的に利用して、最大限の影響を及ぼしています。

vSphere がオンプレミスとプライベート クラウドの基盤となる標準となっているのは、その使いやすさと安定性によるものですが、これらは誤解を招く可能性があります。使いやすさと安定性は、固有のセキュリティと同義ではありません。脅威の状況が進化し、特にハイパーバイザ レイヤが直接標的となり、従来のエンドポイント防御が回避されるようになったため、vSphere のセキュリティに対するアプローチを根本的に変える必要があります。古い手法、バックアップ、境界防御のみに頼ったり、ゲスト VM の EDR が基盤となるインフラストラクチャを十分に保護すると想定したりすると、重大なセキュリティ ギャップが生じ、組織が深刻なリスクにさらされます。

ID 統合の脆弱性は悪用される可能性が高いため、組織は vSphere 環境の AD 統合ステータスを直ちに評価し、このドキュメントに記載されている軽減戦略の実装を優先することを強く推奨します。このプロアクティブな姿勢は、現代の脅威に効果的に対処するために不可欠であり、以下が含まれます。

1. 重要な依存関係の分離: ESXi ホストと AD の直接統合を断ち切ることは、AD の攻撃対象領域を縮小するうえで最も重要です。

2. 認証のモダナイズ: vCenter 向けに、フィッシングに強い堅牢な MFA を実装することは、もはやオプションではなく必須です。できれば、最新の IdP との ID 連携を介して実装してください。

3. 体系的な強化: ESXi と vCenter の安全でないデフォルトに事前に対処し、execInstalledOnly、セキュアブート、TPM、ロックダウン モードなどの機能を有効にして、厳格なファイアウォール ルールを構成します。

4. 可視性の強化: ESXi と vCenter の両方で包括的なリモート ロギングを実装し、ハイパーバイザ レベルの攻撃を検出するために特別に設計されたユースケースを使用して SIEM にフィードします。

5. ティア 0 アセットの保護: Active Directory ドメイン コントローラなどの重要なワークロードを、厳格で最小限のアクセス制御と暗号化された VM および vMotion を備えた専用の高セキュリティ vSphere 環境に戦略的に分離します。

2025 年 10 月に vSphere 7 のサポートが終了すると、インフラストラクチャを支えるプロダクトのプロダクト サポート、セキュリティ パッチ、アップデートを多数の組織が受けられなくなります。これは組織にとって重要な岐路であり、脅威アクターにとっては絶好の機会です。vSphere 7 からの移行は、単に新しい機能を実装してサポートを受けるためのルーチン アップグレードではなく、セキュリティのためにアーキテクチャを再構築する重要な機会と捉えるべきです。推奨される軽減策を実装して、これらの相互に関連するリスクに事前に対処しないと、組織は標的型攻撃にさらされ、仮想化されたインフラストラクチャ全体が迅速に機能停止に陥り、運用の中断や金銭的損失につながる可能性があります。これらの重要な vSphere 環境を保護するために、復元力のある多層防御のセキュリティ ポスチャーを採用する時期は、間違いなく今です。

-Mandiant、 執筆者: Stuart Carrera、Brian Meyer