VMware vCenterの重大脆弱性、修正公開から5日で悪用か　逆SSHで「完全侵害」と判断

CVE-2026-59310は、単なる「優先度の高いパッチ適用案件」ではありません。Broadcomは2026年7月29日にVMware vCenterのSyslog Serverにある重大な脆弱性を公表し、修正版を提供しました。しかし、QUIRSOの調査では、わずか5日後の8月3日から悪用の兆候が確認されています。攻撃は47カ国の観測IPアドレス361件に及び、逆SSHによるアクセス維持も行われました。Shadowserverは、逆SSHが導入されたシステムを完全に侵害されたものとして扱うよう呼びかけています。

CVE-2026-59310で何が可能になるのか

Broadcomと米国立標準技術研究所（NIST）のNational Vulnerability Database（NVD）によると、CVE-2026-59310はvCenterのSyslog Serverに存在するディレクトリ・トラバーサル脆弱性です。ネットワーク経由でvCenterに到達できる攻撃者は、認証なしでこの問題を悪用し、影響を受けるvCenter上で任意のコードを実行できる可能性があります。CVSS基本値は9.8で、重大（Critical）に分類されます。

実務上は、インターネットや広い内部ネットワークから到達可能なvCenterアプライアンスが、永続化や仮想基盤内部へのさらなる侵入の足がかりになり得るということです。攻撃事例の報告には、アプライアンス上でroot権限のコンテキストによるコード実行に言及したものもあります。ただし、ベンダーとNVDが最も明確に示しているのは、認証不要の任意コード実行リスクであり、個々の侵入でどの権限が使われたかについての完全な説明ではありません。

Broadcomは修正版を提供していますが、回避策は提示していません。したがって、脆弱なシステムに対する公式の対処は、同社が案内する更新プログラムを適用することです。

公開からわずか5日で悪用

Broadcomは7月29日にCVE-2026-59310を公表し、修正をリリースしました。QUIRSOは8月3日から実際の悪用の兆候を報告し、その後、攻撃キャンペーンが急速に拡大したとしています。

この時間差は、インシデント対応において重要です。8月3日以降にパッチを適用したからといって、更新に成功したシステムがクリーンだとは限りません。管理者は、脆弱性を修正する作業と、すでに侵害されていないかを確認する作業を分けて考える必要があります。まず脆弱性を塞ぎ、そのうえで攻撃者がアクセスを確立していなかったかを調査します。

47カ国・361 IPアドレスに広がった攻撃

研究者は、この活動を47カ国で観測された361件の被害IPアドレスと関連付けました。報告によると、ドイツ、米国、トルコ、イラン、フランスの5カ国だけで、観測されたIPの半数以上を占めています。

ただし、IPアドレスの数がそのまま組織数を意味するわけではありません。「361の被害企業・機関」と断定することはできません。一方で、公開インターネットまたはその他のネットワーク経路から到達可能なvCenterシステムを対象に、広範な攻撃が行われたことは、利用可能な報告から示されています。

中国との関連を示す材料と限界

QUIRSOは、このキャンペーンについて中国との関連を「中程度の確度」で評価しました。根拠として挙げられているのは、中国語の痕跡、ツールや公開済み研究の再利用、UTC+08:00の勤務時間帯と整合する活動、そして中国本土を標的から外しているように見える被害分布です。

これらは地域的・言語的な関連を示す手がかりではありますが、特定の中国政府系グループを特定したり、政府の指示による作戦だと証明したりするものではありません。マルウェアの特徴、活動時間、標的選定に基づく帰属評価は、追加の証拠によって変わる可能性があります。現時点で最も慎重な表現は、「中国との関連が疑われる攻撃者」であり、国家支援が確認された作戦ではありません。

報告された侵入の流れ

攻撃者はCVE-2026-59310を初期侵入に利用した後、複数の手段で永続化とアクセス維持を図ったとみられています。

1. ディレクトリ・トラバーサル：Syslogサービスに細工したリクエストを送り、本来のパスの外側に攻撃者が管理するファイルを書き込んだとされます。
2. cronによる永続化：不正なcronエントリを作成し、定期タスクから後続コマンドを起動したと報告されています。
3. バックドアの配信：curlやwgetを使い、WebSocket通信とXORで難読化されたlinuxFileバックドアを取得したとされています。
4. 逆SSH：攻撃者側のインフラへ外向きの接続を作る逆SSHツールを導入し、遠隔アクセスを維持しました。Shadowserverは、特別レポートで扱った全被害システムにこの永続化手段が確認されたと報告しています。
5. 認証情報とアカウントの悪用：不正なvCenterおよびESXi管理者アカウントの作成や、VMware Directory Serviceの認証情報の悪用が報告されています。
6. ランサムウェアの展開：少なくとも一部の報告では、ファイルに.babyk拡張子を付けるBabuk派生ランサムウェアとの関連が指摘されています。

とりわけ重要なのが逆SSHです。Shadowserverは、この仕組みが導入されたシステムを完全に侵害されたものとして扱うべきだと結論付けています。バイナリを削除したりcronジョブを消したりするだけでは、アプライアンスへの信頼を回復し、特権認証情報を安全にするための復旧策として不十分です。

ランサムウェアはフォレンジック妨害が目的だった可能性

報告された.babykの活動は、広範な暗号化と身代金要求を主目的とする典型的なランサムウェア攻撃とは限りません。分析では、ESXiのログを選択的に暗号化し、調査を妨げて侵入の証拠を隠す狙いがあった可能性が指摘されています。

ただし、これは攻撃者が明示した目的ではなく、分析に基づく推測です。防御側は、仮想マシンへのランサムウェア被害と、侵入を隠すための意図的なログ改ざんの両方を調査する必要があります。

GitHub上で管理ツールを装った可能性

この作戦では、逆SSHバイナリをLinuxの一時ファイル削除ユーティリティに見せかけたGitHubリポジトリとの関連も報告されています。永続化ツールを管理用・クリーンアップ用のプログラムに偽装すれば、配布のハードルを下げ、通常の確認作業で目立ちにくくすることができます。

ただし、公開されている情報だけでは、そのリポジトリを誰が運営していたかは独立に確認されていません。リポジトリの存在だけを攻撃者の帰属を示す証拠とみなすべきではありません。

Broadcomの株価とVMware事業への影響

VMware製品への攻撃が報じられた8月14日、Broadcomの株価はおよそ5〜6％下落しました。ある報告では、株価が1セッションで417.82ドルから392.99ドルへ下落したとされています。

ただし、この下落のすべてをCVE-2026-59310だけに結び付けることはできません。同時期には、AI関連の債務負担を含む幅広い懸念も投資家のセンチメントに影響したと報じられています。したがって、脆弱性によって消失した市場価値を正確な金額で示すことも適切ではありません。

現時点の報告から、今回の攻撃がVMwareの売上高を測定可能な形で押し下げたと結論付ける十分な証拠はありません。短期的に見込まれる、より確かな影響は、顧客側の復旧・対策コスト、業務停止リスク、そして評判への圧力です。長期的な売上への影響を判断するには、Broadcomの開示や追加の財務情報が必要です。

vCenter管理者が取るべき対応

パッチ適用は出発点であり、完了ではありません。組織は次の対応を進めるべきです。

1. Broadcomの修正版を直ちに適用する：影響を受けるすべてのvCenterを更新し、特にインターネットに公開されたシステムや、広い内部ネットワークから到達できるアプライアンスを優先します。Broadcomは回避策を示していません。
2. 痕跡があれば侵害を前提にする：予期しないcronの変更、逆SSHの痕跡、linuxFile、説明のつかないcurlやwgetによるダウンロード、不審なvCenter・ESXi管理者、異常なVMware Directory Serviceの活動を確認します。
3. 疑わしいアプライアンスを隔離する：業務上可能であれば、再構築の前にディスクイメージ、ログ、揮発性データを保全します。
4. 特権認証情報をローテーションする：vCenter SSO、VMware Directory Service、ESXiまたはroot、API、サービスアカウント、連携先の管理者認証情報を更新し、アクティブなセッションを無効化します。フェデレーション経路も確認します。
5. 単純な削除ではなく再構築を検討する：永続化が確認されたシステムは、信頼できる状態に戻すため再構築します。不正アカウント、cronジョブ、バイナリ、SSHキー、トンネルの除去は、文書化したインシデント対応の一部として実施します。
6. 仮想基盤全体を横断して調査する：.babykの活動、予期しない外向きSSH・WebSocket接続、不正アカウント、ESXiログの改ざんを探索します。
7. 信頼できるデータと監視基盤を復元する：ログや設定が改変されている場合は、既知の正常な不変バックアップから復元します。
8. 将来の露出を減らす：vCenterの管理アクセスを分離された管理ネットワークに限定し、vCenterとESXiホストからの外向き接続を監視します。

実務上の結論は明快です。脆弱なvCenterはすべて更新する必要がありますが、パッチ適用が成功したことと、環境がクリーンであることを同一視してはいけません。短期間での悪用、逆SSHによる永続化、認証情報の悪用が報告されているため、外部から到達可能だったアプライアンスは完全侵害の可能性を前提に調査する必要があります。