仮想化に潜む見えないリスク：なぜハイパーバイザーはランサムウェアの格好の標的なのか

著者：Dray Agha（Huntress Labs、Hunt & Response シニアマネージャー）

ハイパーバイザーは現代の仮想化環境の基盤ですが、ひとたび侵害されると攻撃者にとっての「増幅装置」になり得ます。この層での単一の侵害が、同時に数十、場合によっては数百の仮想マシンを危険にさらします。従来のエンドポイントとは異なり、ハイパーバイザーは可視性や保護が限定的なまま運用されることが多く、一般的なセキュリティツールでは手遅れになるまで攻撃を検知できない可能性があります。

HuntressのSOCおよび脅威ハンティングの現場から見ると、敵対者がハイパーバイザーを標的にしてランサムウェアを大規模展開する動きが増えています。具体的には2025年、Huntressの事例データによりハイパーバイザー・ランサムウェアの驚異的な急増が明らかになりました。悪意ある暗号化におけるその関与は、年の前半ではわずか3%だったのが、後半（現時点）では25%へと急上昇しています。

この傾向を主に牽引しているのはAkiraランサムウェアグループです。この変化は、エンドポイントやサーバーに適用しているのと同等の厳格さで、ハイパーバイザー層を強化する重要性を浮き彫りにしています。

本記事では、実際の攻撃で観測した脅威を整理し、パッチ適用やアクセス制御から、実行時のハードニング、堅牢な復旧戦略に至るまで、ハイパーバイザー基盤を保護するための実践的な指針を提示します。

ハイパーバイザー：ランサムウェア作戦における新たな戦場

2025年のここ数か月、Huntressはエンドポイントおよびネットワークのセキュリティ制御を回避する目的で、敵対者がハイパーバイザーを標的にする事例を観測しています。

これは理にかなっています。防御側がエンドポイントやサーバーの強化を進めるにつれ、敵対者は仮想化インフラの基盤であるハイパーバイザー層へと焦点を移しつつあります。Type 1（「ベアメタル」）ハイパーバイザーはサーバーハードウェアに直接インストールされる基盤であり、Type 2（「ホスト型」）ハイパーバイザーは通常のコンピューターOS上で動作するアプリです。このシフトは、見慣れた手口に沿っています。

VPNアプライアンスへの攻撃でも同様でした。脅威アクターは、ホストOSが独自仕様または制限付きであることが多く、防御側がEDRのような重要なセキュリティ制御を導入できない点に気づきます。これにより大きな死角が生まれます。

同じ原理がType 1ハイパーバイザーにも当てはまります。従来のエンドポイントセキュリティが届きにくい領域であり、まさに究極の「侵入して拡大（land-and-expand）」ターゲットです。

また、ランサムウェア運用者がハイパーバイザー経由でランサムウェアのペイロードを直接展開し、従来のエンドポイント保護を完全に回避する複数の事例も観測しています。

場合によっては、攻撃者がopensslのような組み込みツールを利用して仮想マシンのボリュームを暗号化し、独自のランサムウェアバイナリをアップロードする必要すら回避します。

• ネットワーク内に侵入すると、攻撃者はしばしばハイパーバイザーへとピボットします。ネットワークセグメンテーションが機能せず、ハイパーバイザー管理ページへの横移動を拒否できない環境では、侵害された内部認証情報が利用されます。この動きにより、単一の管理インターフェースから複数のゲストシステムに対する高い権限の制御を得られます。
• Hyper-V管理ユーティリティの悪用により、VM設定を変更してセキュリティ機能を弱体化させる事例も確認しています。これには、エンドポイント防御の無効化、仮想スイッチの改ざん、そして大規模なランサムウェア展開に向けたVMの準備が含まれます。

このシフトは、増大しつつある不都合な傾向を示しています。攻撃者はすべてのホストを制御するインフラそのものを狙っており、ハイパーバイザーへのアクセスを得ることで侵入の影響を劇的に増幅させます。

アクセスを安全にし、最小権限を徹底し、管理プレーンを分離する

攻撃者がハイパーバイザーの管理者資格情報を入手できれば、ホスト上のすべてのVMに影響するランサムウェアのペイロードを展開できます。また、ESXiの管理にドメイン参加アカウント（例：Active Directory（AD）アカウント）を使用すると、横移動のリスクが高まります。 

対策：

• ローカルのESXiアカウントを使用する。 管理に汎用のドメイン管理者アカウントを使うのは避けてください。代わりに、専用のローカルESXiアカウント、または必要最小限の権限のみを付与し監査可能な厳格に制限されたドメインアカウントを作成します。ドメイン管理者アカウントが侵害されても、この分離によりハイパーバイザーとその仮想マシンへの即時の不正アクセスを防げます。
• 多要素認証（MFA）を強制する。 重要インフラでは妥協できません。ホスト管理インターフェースおよびvCenterアクセスにMFAを適用し、資格情報の窃取から保護してください。盗まれたユーザー名とパスワードだけでは攻撃者は阻止され、侵害成功に必要な労力が大幅に増えます。この制御は、一般的なフィッシングやブルートフォース攻撃に対する強固な防御となります。強力なパスワードを使用し、安全なパスワード保管庫に保存する。 ESXiの資格情報は極めて強力なものにし、共有ドキュメントや安全性の低い場所ではなく、専用のパスワード保管庫にのみ保存してください。侵害されたファイル共有や不適切なパスワード管理といった一般的な攻撃経路による漏えいを防ぎます。
• ホスト管理ネットワークを分離する。 ハイパーバイザーの管理ネットワークを、本番ネットワークおよび一般ユーザーネットワークから分離してください。論理的および/または物理的に分離された専用VLANまたはネットワークセグメントを作成します。ハイパーバイザー管理インターフェースへ接続を試みられるエンドポイント数を制限することで、潜在的な攻撃対象領域を大幅に縮小できます。
• ジャンプボックス（踏み台）またはバスティオンサーバーを導入する。 すべての管理アクセスを監査・制御するため、IT管理者がまずアクセスし、そこからハイパーバイザーへ移動するジャンプボックス／バスティオンを導入してください。これにより、比較的安全性の低い管理者ワークステーションからの直接接続を排除できます。ジャンプボックスは監視されたチェックポイントとして機能し、セッション記録、全コマンドのログ取得、重要インフラへのアクセス付与前のセキュリティポリシー適用を可能にします。
• 最小権限の原則（PoLP）を適用する。 コントロールプレーン（vCenterおよび各ホスト）へのアクセスを厳格に制限してください。リソース管理やパッチ適用など、必要な管理機能に対して、人間の管理者とサービスアカウントの双方に最小限のロールのみを付与します。PoLPを徹底することで、単一アカウントの侵害が仮想化環境全体への全面的な変更に悪用されることを防げます。
• 管理アクセスを専用の管理端末に限定する。 ESXi管理インターフェースへのアクセスを、固定IPアドレスを持つ特定の管理端末に限定してください。既知かつ許可されたエンドポイントのみがハイパーバイザーへ接続を試みられるようにする追加の障壁となり、攻撃対象領域をさらに縮小します。

ハイパーバイザーの実行時環境をロックダウンし、コード／実行制御を強制する

ハイパーバイザーレベルのランサムウェアに固有のリスクの一つは、攻撃者がホスト上に到達すると、ゲストOSの制御を回避してハイパーバイザーレベルでコードを実行できる点です。想定された署名済みコードと信頼されたモジュールのみが動作するよう、ホストをハードニングする必要があります。

対策：

• 高度なホスト設定 VMkernel.Boot.execInstalledOnly = TRUE を有効化し、署名済みVIBでインストールされたバイナリのみが実行できるようにします。これにより、カスタムの悪意あるバイナリがホスト上で実行されるのを防ぎます。

• 不要なサービス（SSHやESXi Shellなど）は未使用時に無効化／閉鎖し、ロックダウンモードを有効にします。

ハイパーバイザーをパッチ適用し最新状態に保ち、露出面を最小化する

攻撃者は既知の脆弱性を通じてESXiホストを積極的に狙い、大規模暗号化を行っています。0dayやCVEが最も一般的／現実的な侵害理由になる可能性は高くなく、実際にはセグメンテーションの不備が原因であることが多いでしょう。しかし、パッチ適用の維持は極めて重要です。

例えば、CVE-2024-37085 はこのハイパーバイザーリスクを端的に示しています。この脆弱性により、十分なAD権限を持つ攻撃者は認証をバイパスして即座にESXiホストの完全な管理者権限を奪取でき、数秒で全VMを一括暗号化することにつながります。

この攻撃が成立するのは、脆弱なESXiホストがADグループ「ESX Admins」に自動的にフル管理者権限を付与するためです。脅威アクターはそのグループを再作成するだけで、即座に「王国の鍵」を手にします。

こうした初期侵害は、未パッチの管理インターフェースや、Service Location Protocol（SLP）のような露出したプロトコルから始まることが多く、低労力の侵入口になります。

 対策：

• すべてのESXiホスト（およびvCenterなど関連する管理コンポーネント）と、そのパッチレベルのインベントリを維持する。

• ベンダー提供のセキュリティパッチと更新を優先し、特にハイパーバイザー関連CVEに注力する。

• 不要なサービスは無効化または制限し、外部に露出しないようにする。Service Location Protocol（SLP/ポート427）はESXArgsなどのランサムウェアグループに悪用されており、無効化すべきです。VMwareの公式修復ガイダンスに従ってください。

• ESXiホストの管理用インターフェースをインターネットに直接公開しない。VPN、バスティオンホスト、または分離された管理ネットワークを使用する。

バックアップ戦略：イミュータブルなスナップショットと迅速な復旧能力

強力な予防策を講じても、リスクは残ります。ハイパーバイザー層は影響が大きいため、フォールバックは必須です。多くのガイドが、復旧は最後の防衛線だと強調しています。ESXiを狙うランサムウェアは通常、VMDKやホストファイルの暗号化を狙います。良質なバックアップがなければ、支払いを強いられる可能性があります。

対策：

• 「3-2-1」バックアップルールを採用する：データを少なくとも3コピー、2種類の媒体に保存し、1コピーはオフサイト／ハイパーバイザーネットワーク外に置く。

• イミュータブル（不変）なバックアップリポジトリやスナップショットを使用し、書き込み後に改変・削除できないようにする。

• バックアップリポジトリをActive Directoryや集中型ID管理システムに接続しない。代わりに、ドメイン非参加で専用のローカルアカウントを使用し、侵害されたAD資格情報によってランサムウェアが重要なバックアップ先へ直接拡散するのを防ぐ。 

• バックアップにVMのフルイメージと関連するハイパーバイザー状態を含め、迅速に再構築できるようにする。

• バックアップを定期的にテストする。バックアップをマウントしてファイルにアクセスできることを確認するだけでなく、OSが完全に起動し、既知の資格情報でログインできることを確認する。

• 少なくとも年1回、フルリカバリの訓練を実施する。思い込みはダウンタイムの長期化につながります。追加の検討事項は以下のとおりです。
  • オフサイトおよび/またはフェイルオーバー先でテストしましたか？
  • サーバーが正しいネットワーク／接続性を備えていることを確認できますか？本番のエンドポイントからこれらのフェイルオーバーサーバーへアクセスできますか？
  • バックアップサイト／フェイルオーバー先のファイアウォールには、EDR、RMM、VPNクライアントなど重要ツールからの適切な通信を確保するために必要な許可リストやファイアウォールルールが、あらかじめ設定されていますか？

監視し、異常を検知し、侵害を前提とする（多層防御）

ハイパーバイザー層はEDRのような従来のエンドポイントセキュリティツールから見えにくいことが多いため、代替の検知戦略が必要です。攻撃者は、VIB受け入れレベルの変更、SSHの有効化、ロックダウンモードの無効化、新しい管理者アカウントの作成などを、ランサムウェアのペイロード展開の前兆として行うことがよくあります。

監視がなければ、暗号化が完了した後にしか事象を検知できない可能性があります。

対策：

• ESXiログをSIEMへ転送し、主要な不審イベント（新規rootログイン、サービス有効化、VIB受け入れ変更、データストアのアンマウントなど）に対するアラートを作成する。

• 設定のドリフトを監視する。いずれかのホストでロックダウンモードが無効、SSHが有効、execInstalledOnlyがオフになっている場合は、レビュー対象としてフラグを立てる。

• 管理ネットワークのトラフィックをログ化する。先に、ESXiやその他の重要インフラのコントロールプレーンを専用VLANまたはネットワークセグメントに置くことを推奨しましたが、ここではハイパーバイザー管理インターフェースへアクセスする異常な送信元IP（理想的にはジャンプサーバーからのトラフィックのみ許可）、横移動の試行、またはVM暗号化に一致する大規模なデータストアI/Oパターンを探します。

• ハイパーバイザー管理にはゼロトラストの考え方を適用し、資格情報が侵害され得る前提で、アラートを設計する。

• 従来のsyslog形式とは異なり、ESXiは特定の活動ごとにログを別ファイルへ分割します。ハイパーバイザー侵害の検知・調査に最も重要なログファイルは、/var/log/auth.log（認証イベント）、 /var/log/hostd.log（ホストエージェントの活動）、/var/log/shell.log（ESXiシェルのコマンド）、/var/log/vobd.log（VMware observer daemon）です。ログ設定のガイダンスについては、 Broadcomのドキュメントおよび SygniaのESXi防御戦略を参照してください。

サードパーティのSOCまたはMDRプロバイダーと連携する場合、責任分担モデル（shared responsibility model）の確立を検討してください。外部のセキュリティパートナーは、日常的な内部メンテナンスと、午前2時に侵入してくる敵対者とを区別するために必要な業務コンテキストを持っていません。

この区別は重要です。サードパーティSOCは、ランサムウェア実行そのもののような「普遍的な悪」を検知するのに最適な立場にあります。これを補完するため、社内セキュリティチームは、内部者脅威や、深夜ログインの直後にSSHが有効化されるといった、社内でしか文脈化できない行動の監視に注力することを推奨します。

このモデルを成功させるには、ITチームが変更管理手順を厳格に遵守し、想定されるハイパーバイザー変更をすべて社内セキュリティへ共有する必要があります。これによりSOCは想定アクティビティを把握でき、関係者全員が最も効果的な領域に注力できます。

結論

ESXiのようなベアメタル・ハイパーバイザーをランサムウェアから守るには、多層的で能動的なアプローチが必要です。パッチ適用とアクセス制御から、実行時ハードニングと復旧準備、検知とログまで、あらゆる角度をカバーする必要があります。

最悪の事態に備えるためのより包括的なガイダンスが必要な場合は、災害復旧（Disaster Recovery）計画に関する当社ガイドをご覧ください。今こそ組織として問うべきです。IRP（インシデント対応計画）とDRP（災害復旧計画）を最後に全面更新・テストしたのはいつか、特にすべてのゲスト仮想マシンを復元して稼働できることを確認したのはいつか？

最善の予防・検知努力を尽くしても、侵害が成功する可能性に備えるべきです。ESXi環境の侵害対応に直面した場合は、この包括的なESXi IRガイドの確認を推奨します。このガイドは、ESXi環境に特化した詳細なインシデント対応手順とフォレンジック成果物を提供します。

Huntressを活用していれば、OS／エンドポイント層ではすでにこれらの多くを適用しているかもしれません。しかし、ハイパーバイザーは大量影響の可能性があるため、同等（そして多くの場合それ以上）の厳格さが求められます。

本記事の防御ガイダンスを環境とセキュリティプロセスに組み込めば、ランサムウェア攻撃者に対する障壁を大きく引き上げられます。

2026年も状況認識を維持する—Tradecraft Tuesdayに登録

Tradecraft Tuesdayは、サイバーセキュリティ専門家に対し、最新の脅威アクター、攻撃ベクトル、緩和戦略の詳細な分析を提供します。毎週のセッションでは、最近のインシデントの技術的ウォークスルー、マルウェア動向の包括的な分解、最新の侵害指標（IOC）が取り上げられます。

参加者が得られるもの：

• 新たに出現する脅威キャンペーンとランサムウェア亜種に関する詳細ブリーフィング
• エビデンスに基づく防御手法と修復テクニック
• インシデント対応の洞察を得るためのHuntressアナリストとの直接対話
• 実用的な脅威インテリジェンスと検知ガイダンスへのアクセス

Tradecraft Tuesdayに登録 →

組織の環境を守る責任を担う人のために特別に設計された、リアルタイムのインテリジェンスと技術教育で、防御態勢を強化しましょう。