BlackNevasの攻撃者が10日間にわたり、ある組織の仮想化基盤を丸ごと破壊した侵入事案が新たに明らかになりました。
Kasperskyのグローバル緊急対応チーム（GERT）の調査によると、攻撃者はESXiホスト4台とその上のすべての仮想マシン、2台のvCenter Server Appliance（VCSA）、そして接続されていたバックアップ基盤をすべて破壊しました。
攻撃者はハイパーバイザーのメモリ破壊やゲストからホストへのエスケープを使っていません。すべての操作は正規のVMware管理インターフェースを通じて実行されており、被害組織はサポート対象外のESXiビルドを使用していました。
初期アクセスには、有効なアカウントの悪用（T1078）が使われました。攻撃者は仮想化レイヤー外のシステムから入手した管理者認証情報を再利用してvCenterに認証しており、その挙動は通常の運用操作と区別がつかない状態でした。この種の管理プレーンを狙う手口は、Fire Antのスパイ活動でも確認されています。
このキャンペーンでは、vCenterのDCERPCサービスにおけるCVE-2023-34048の悪用がvpxuser認証情報の窃取につながり、さらに強制的に受け入れさせる形で悪意あるvSphere Installation Bundleが導入されました。
次に攻撃者は、災害復旧を管理するvCenterアプライアンスにrootとしてSSH接続しました。その43秒後には、シェルスクリプトを使ってMeshCentralのエンドポイントコンポーネントであるMeshAgentを展開しています。
SSHセッションはわずか2分26秒で終了し、攻撃者がこのアプライアンスで再びSSHを使うことはありませんでした。約4時間後、攻撃者はMeshAgent経由で再び侵入し、Ligolo-ng v0.8.2をsystemdユニット「vmware-vdma.service」としてインストールしました。
ExecStartは/opt/vmware/bin/agentを指しており、api.cloudvflare[.]com:443にビーコンを送信していました。これはSystemdサービス（T1543.002）およびプロトコルトンネリング（T1572）に該当します。
インプラントを正規コンポーネントに偽装する手口はたびたび見られます。WARP PANDAの関与が指摘されるBRICKSTORMバックドアも、updatemgrやvami-httpになりすましていました。
続いて攻撃者は、vCenterを攻撃用のコントロールプレーンに変えました。ホストプロファイルを使って、Tech Support Mode SSH（TSM-SSH）の構成変更を一斉に適用したのです。
サービスは33秒以内にRUNNING状態に達し、その後は信頼されたvCenterのIPアドレスからESXiホストへ直接SSHセッションが張られました。防御側はvpxa.logとvobd.logのイベントを突き合わせることで、この一連の動きを検知できます。
ペイロードの配布にはSFTPが使われ、auth.logにはFlowSshのクライアント識別子が残っていました。まずtrue実行のみの探査セッションがあり、続いてchmod +x /tmp/esx64が実行されました。そして実行の約3時間前に、約16秒間の/selftestが走っています。
公開された管理サービスを武器化する攻撃者の動きは素早いものです。vCenter SyslogのパストラバーサルCVE-2026-59310を悪用したキャンペーンがその例です。reverse_sshを展開したこのキャンペーンは、脆弱性の公表から数日のうちに361のIPアドレスの被害者に到達しました。
暗号化（破壊）の実行には、./tmp/esx64 /p /vmfs/ /depth 5 /wipe /allsys /detach /-showvolumes というコマンドが使われました。スラッシュ形式のスイッチは、Trigona由来のBlackNevasファミリーの特徴と一致します。対応にあたった担当者は、データストア全体で._wipeというアーティファクトを発見したほか、仮想ディスクの先頭約2KBが上書きされていることを確認しました。
この損傷はMBRとプライマリGPTヘッダーに及びます。バックアップGPTが残っていれば復旧できる可能性はありますが、ほかにどこが改変されたかによって左右されます。災害復旧用ホストでは、すべての仮想マシンが23秒以内に停止し、vmksummary.logには稼働中のVM数がゼロに減少する様子が記録されていました。
最初に破壊されたのはバックアップ環境でした。攻撃者は実行の数日前から、バックアップサーバー上のウイルス対策ソフトを無効化しています。その後、バックアップサービスを停止し、復旧システムを暗号化し、管理者アクセスを妨害しました。これらはすべて、ESXiへの攻撃フェーズより前に行われています。
攻撃者はさらに、バックアップ基盤に保存されていた認証情報も抜き取りました。この認証情報は、他のインフラ階層へ侵入するための足がかりになりました。Kasperskyは、vCenterをTier 0の資産として扱い、仮想化基盤のIDと企業の管理者IDを分離するよう推奨しています。
また、ESXiのRAMディスクは再起動で消去されるため、ESXiとvCenterのログをリモートsyslogに転送することも推奨しています。アラートでは、TSM-SSHに対するホストプロファイルの変更、弱められたexecInstalledOnly設定、/tmpに配置された実行ファイル、VMの大量電源オフを検知対象にすべきです。
16,000以上のSOCチームがANY.RUNを活用し、脅威調査を効率化して手作業を削減しています。チームで試してみる
翻訳元: https://cyberpress.org/blacknevas-ransomware-vmware-esxi-servers/
