BlackNevasランサムウェア、VMware ESXiサーバーを攻撃　仮想マシンとバックアップ基盤を破壊

ランサムウェアグループ「BlackNevas」が、10日間にわたって組織の仮想化環境全体を破壊した侵入事案が新たに明らかになりました。

Kaspersky のグローバル緊急対応チーム（GERT）の調査によると、攻撃者は4台のESXiホスト、その上で稼働するすべての仮想マシン、2台のvCenter Server Appliance（VCSA）、さらに接続されたバックアップ基盤をすべて消去しました。

攻撃者はハイパーバイザーの脆弱性、ゲストからホストへの脱出、メモリ破壊のいずれも悪用していません。すべての操作が正規のVMware管理インターフェースを通じて実行されたため、侵入は通常の管理作業のように見えていました。

StudySecurity

BlackNevasランサムウェアがVMware ESXiサーバーを攻撃

初期の横展開では、正規アカウントが悪用されました（MITRE ATT&CK T1078）。境界内にある仮想化以外のシステムから入手した認証情報で、vCenterアプライアンスにアクセスしています。

攻撃者はバックアップサーバーでも管理者権限での実行権限を得たうえで、保存されていた機密情報を抜き取りました。バックアップ基盤はサービスアカウント、ハイパーバイザーの認証情報、リポジトリへのアクセス権を保持しているため、他の階層へ移動するための足がかりとして好都合です。

バックアップソフトウェアでも同様の脆弱性は繰り返し見つかっています。たとえば、Veeam Backup & ReplicationにおけるBinaryFormatterのデシリアライズを悪用したRCEでは、権限の低いドメインユーザーがバックアップサーバー上でコードを実行できます。

災害復旧用のvCenterでは、攻撃者はrootとしてSSH接続し、MeshCentralのエンドポイントコンポーネントであるMeshAgentを43秒以内に展開しました。

約4時間後、攻撃者はMeshAgent経由で再び侵入し、リバーストンネルツールのLigolo-ngを、vmware-vdma.serviceという名前のsystemdユニットとしてインストールしました。

バイナリは/opt/vmware/bin/agentに置かれ、api.cloudvflare[.]com:443に対してビーコンを送信していました。このユニットにはVMware風の説明文とRestart=alwaysが設定されており、T1543.002（Systemd Service）とT1572（Protocol Tunneling）に該当します。攻撃者はその後、対話型のSSHを一切使わなかったため、SSHセッションのみを監視していた環境では検知できませんでした。

最も特異な手口は、vCenterのホストプロファイルの悪用です。攻撃者はコンプライアンスのワークフローを利用して設定変更を適用し、TSM-SSHを無効から実行中に切り替えました。

適用の33秒後にSSHはRUNNING状態に達し、その後は信頼されたvCenterのIPアドレスからESXiホストへの直接セッションが開始されました。防御側は、vpxa.logとvobd.logのエントリを突き合わせることで、この一連の動きを検知できます。

承認された変更時間帯以外にTSM-SSHを変更するホストプロファイルの修復が行われ、続いて管理アプライアンスから新たなSSHセッションが確立された場合は、アラートを出すようにしてください。

攻撃者は実行の数日前からバックアップ環境のアンチウイルスを無効化し、バックアップサービスを停止したうえで、復旧用リポジトリを暗号化しました。

この順序により、本番環境に手を付ける前に復元経路が断たれました。Veeam Backup & Replicationの重大なリモートコード実行の脆弱性は、こうしたバックアップ改ざんの経路として繰り返し使われています。

パッチ適用だけでは不十分です。本番環境と同じID基盤を共有する復旧システムは、そこを経由して侵害される可能性があるためです。Backup Viewerのデシリアライズの脆弱性（CVE-2025-64393）は、権限の低い単一のロールからバックアップサーバー上でSYSTEM権限の実行が可能になる例を示しています。

ペイロードはSFTP経由で届き、auth.logにはFlowSshのクライアント識別子が記録されていました。攻撃者は/tmp/esx64に対してchmod +xを実行し、/selftestスイッチを付けて約16秒間実行しました。

Securelistによると、約3時間後に最終コマンドとして./tmp/esx64 /p /vmfs/ /depth 5 /wipe /allsys /detach /-showvolumes を起動しました。スラッシュ形式のスイッチは、Trigona由来のBlackNevasファミリーの特徴と一致します。

災害復旧ホスト上のすべてのVMは23秒以内に停止し、vmksummary.logでは稼働中のVM数がゼロまで減少していました。各仮想ディスクの先頭約2KBが上書きされ、MBRとプライマリGPTヘッダーが破壊されました。バックアップGPTが残っていれば、部分的な復旧が可能な場合もあります。

防御側は、vCenterをTier 0の資産として扱い、フィッシング耐性のある多要素認証（MFA）を備えた専用の管理者IDを割り当てる必要があります。また、execInstalledOnlyランタイムオプションとVIBの受け入れレベルを承認済みのベースラインに維持し、運用上可能であればロックダウンモードを有効にしてください。

ESXiのログは再起動で消去されるRAMディスク上にあります。auth.log、shell.log、vpxa.log、vobd.logはリモートsyslogに転送してください。さらに、バックアップの管理権限を本番のActive Directoryから分離し、vCenterとADが利用できない状況を想定して復元テストを行うことが重要です。

IOC（侵害指標）

注： IPアドレスとドメインは、誤って名前解決されたりハイパーリンク化されたりするのを防ぐため、意図的にデファング（例： [.]）しています。元に戻す（リファング）のは、MISP、VirusTotal、SIEMなど、管理された脅威インテリジェンスプラットフォーム内に限ってください。

16,000以上のSOCチームが、脅威調査の効率化と手作業の削減のためにANY.RUNを活用しています。 自社チームでの活用を検討する