Part-1では、攻撃者が悪意のある vSphere Installation Bundles（以下、VIB）を使用して ESXi ハイパーバイザーに複数のバックドアをインストールする方法について、VIB ペイロードに含まれるマルウェアに着目して説明しました。今回は、timestomping（タイムストンピング）などの攻撃者のその他の行動についてさらに詳しく説明し、プロセスメモリをダンプしてYARAスキャンを実行するESXi検出手法について述べ、ESXiホストの攻撃対象領域を最小化するためのハイパーバイザーのハードニング方法について説明します。詳細については、VMware が vSphere の保護に関する追加情報を公開しています。

ESXIロギング

VIRTUALPITAとVIRTUALPIEは、起動時にvmsyslogdプロセスが活動を記録することを停止しますが、ハイパーバイザー全体に複数のログプロセスが存在するため、攻撃者の活動を追跡するために使用することは可能です。

悪意のあるVIBのインストール

ESXiシステムでは、Descriptor XMLで受け入れレベルが変更された場合でも、設定された最低アクセプタンスレベル以下のVIBファイルの改ざんを許可しないことは、すでにPart-1で説明しました。これを回避するため、攻撃者は-forceフラグを用いて、悪意のあるCommunitySupported VIBをインストールします。このフラグは、ホストが要求するよりも低いアクセプタンスレベルを持つVIBまたはイメージプロファイルを追加します。

ESXiハイパーバイザー上の複数の場所で、VIBをインストールするために-forceフラグが使用されている証拠が発見されました。ESXi プロファイル XML ファイルは、システムにインストールされたすべての VIB を記録し、各 VIB のインストールに使用された日付、時間、およびフラグを指定します。このファイルは、/var/db/esximg/profile というパスに格納されています。図 1 は、プロファイル XML ファイルに記録された、攻撃者による --force フラグの使用例を示しています。

また、ログファイル /var/log/esxupdate.log には、VIB をインストールする際の --force フラグの使用状況も記録されています。図2には、強制的にインストールされた悪意のあるVIBを記録したイベントが含まれています。

さらに、VMware では、セキュア ブートの有効化を推奨しています。この有効化により、最初のシステム起動時に、ESXi が暗号化手法を使用してソフトウェア、ドライバ、およびその他のコンポーネントを検証し、これらのコンポーネントが正当であるかどうかを判断することが可能になります。VMware のガイダンスによると、「vSphere における Trusted Platform Module (TPM) 2.0 の Secure Boot サポートは、ESXi の Secure Boot をベースに、vCenter Server が Secure Boot からのデータおよびシステム構成情報を検証して環境の状態を証明（バリデーション）できるようにしたものです」。vSphere 7 で導入された vSphere Trust Authority は、vSAN および VM Encryption で使用される暗号化キーへのアクセスを、ホストの継続的な認証にさらに関連付けるものです。vSphere Trust Authority の下で認証に失敗したホストは、機密情報へのアクセスが拒否されます。

Timestomping（タイムストンピング）

Mandiant は、-force フラグが設定された VIB インストールに関するログが2013 年 10 月 9 日の時点で記録されており、攻撃のタイムラインと一致しないことを確認しました。ログファイル /var/log/vmkwarning.log は、システム時刻が操作されたことを示すさらなる証拠となりました。図3は、攻撃者のアクションが発生する直前と直後にシステムクロックが変更されたことを記録した2つのイベントを含んでいます。この挙動は、攻撃者がマシンに VIB を最初にインストールした真の時刻を隠蔽するために、タイムストンプが実行されたことを示唆しています。

シスログの作成

VIRTUALPITAサンプルrhttpproxy-io（2c28ec2d541f555b2838099ca849f965）を分析したところ、このサンプルはVMCIポート番号18098上でリスニングを行っていることが分かりました。リスナーがセットアップされると、マルウェアはIOCTLリクエストコード1977を発行して、システムのCID（コンテキストID）を取得します。バックドアのPID、CID、リスニングポートは、図4に見られるように、[<date/timestamp>]<<PID>>:<CID>:<port></p>という形式で/var/log/sysclogにロギングされています。

ゲストマシンとのインタラクション

ハイパーバイザーとそれぞれのゲストマシン間のさらなる相互作用は、vmware.log という名前の複数のログの中で発見されました。これらのログは、次のパス /vmfs/volumes/.../<virtual machine hostname>/vmware.log にあり、エンドポイントに記録されなかったホストとハイパーバイザーの間の基本操作が記録されています。このログに記録される操作には、ゲストマシンのログイン、ファイル/ディレクトリの作成と削除、コマンドの実行、およびゲストマシンとハイパーバイザー間のファイル転送が含まれます。vmware.log内のハイパーバイザーとそのゲストマシン間の相互作用に焦点を当てるには、GuestOpsを含む行をフィルターします。

VIBの検証

前回のブログでは、esxcli software vib signature verify コマンドを使用して、ESXi ハイパーバイザーの署名検証チェッ クを通過しない VIB を特定することについて触れました。署名検証チェックを回避できる別の VIB 構成が存在します。Mandiant は、VIB が CommunitySupported としてインストールされた場合、インストール後にペイロードが改 ざんされてなければ、Signature Verification フィールドは Succeeded とラベル付けされることを確認しました。つまり、VMWare社やそのパートナーからの検証を受けずにVIBを作成しても、検証済みと表示される可能性があるということです。

VMware は、CommunitySupported VIB に適切に署名された VIB と、悪意のある活動を示す可能性のあるその他の異常な構成を考慮し、環境を監査するプロセスを自動化する検出スクリプトを、緩和ガイドの「Threat Hunting」セクションで公開しています。

さらに、環境内のすべての VIB を、既知の正常な VIB のリストと比較することができます。VMware Front Experience が作成したマトリックスでは、各 ESXi ビルドにデフォルトで存在すると予想される各 VIB の名前とビルドが分類されています。ESXi ビルド間で VIB が変更されるたびに、マトリックスは、その VIB の追加、変更、または削除を示す VMware の公式パッチリリースノートにリンクします。このマトリックスのサンプルを図5に示します。

ESXI 検出方法

ESXi は Linux と多くの類似点（コマンド、ディレクトリ構造など）を持っていますが、VMkernel として知られる独自のオペレーティングシステムであるため、ファイルシステムのスキャンやプロセスメモリのダンプといった一般的な方法は機能しません。Mandiantは、今後のインシデントにおいて、ESXiハイパーバイザーの可視性を向上させるため、代替の検出方法を策定しています。

SSHFSを用いたリモートESXi YARAスキャニング

LinuxとESXi環境におけるVIRTUALPITAとVIRTUALPIEの検出のために複数のYARAルールが生成され、このブログ記事の最初の部分に掲載されています。これらの検出には、マルウェアの保存と実行に基づく2つの注意事項があります。攻撃者がESXi上のVIBからいずれかのマルウェアファミリーを起動している場合、VIB内のサンプルは.vgz形式で圧縮されているため、検出されません。次に、バイナリがメモリ上で実行されているがディスクから削除されている場合、YARAのファイルシステムスキャンではバイナリが検出されない。

YARA は ESXi ホスト上で直接動作しないため、Mandiant は ESXi ハイパーバイザーのリモート YARA スキャンを行うために sshfs を利用しました。

前提条件

ESXi マシンをスキャンする前に、いくつかの前提条件を満たしておく必要があります。メモリダンプされるESXiマシンには、次の両方が必要です。

• マシンへのルートアクセス
• ESXi サーバ上でのSSH有効化

ESXiマシンが正しく設定されたら、ESXiマシンとSSHで通信できるようにLinuxマシンをセットアップする必要があります。また、このLinuxマシンは、インストールする必要があります。

• sshfs
• yara

YARAスキャンの実行

ESXi のプロセスメモリのダンプ

ESXi ハイパーバイザーのプロセスメモリを Linux マシンのようにダンプしようとすると、/proc/ ディレクトリが空であるか、メモリダンプに使用したコマンドの PID が 1 つしかないことがすぐに判明します。ESXi からプロセスメモリを復元するには、ネイティブツールの gdbserver と github の core2ELF64 というツールを組み合わせて使用します。

前提条件

プロセスメモリをダンプする前に、いくつかの前提条件を満たしている必要があります。ESXi マシンの場合、次の両方が必要です。

• マシンへのルートアクセス
• ESXiサーバー上でのSSH有効化

ESXiマシンが正しく設定されたら、ESXiマシンとSSHで通信できるようにLinuxマシンをセットアップする必要があります。また、このLinuxマシンは、インストールする必要があります。

• gdb
• core2ELF64

メモリのダンプ

ESXi のプロセスメモリをダンプするために、gdbserver を利用し、PID で指定した現在動作中のプロセスにフックし、任意のポートでリッスンします。

リスニングが完了すると、Linux マシンは ESXi サーバ上のリスニングポートに SSH トンネル (Port Forward) を作成し、そこで gdb を使用して指定されたプロセスのコアダンプを作成します。

プロセスの抽出

コアファイルを作成すると、Githubプロジェクトのcore2ELF64を利用して、プログラムを再構築することができるようになります。

ソース

• Hooking into ESXi processes with gdbserver

ESXiのハードニング

ネットワークの分離

ESXi ホストでネットワークを構成する場合、分離された管理ネットワークでは VMkernel ネットワーク アダプタのみを有効にしてください。VMkernel ネットワーク アダプタは、ESXi ホストにネットワーク接続を提供し、vSphere vMotion、vSAN、vSphere レプリケーションなどの機能で必要なシステム トラフィックを処理します。仮想化インフラストラクチャで使用する vSAN やバックアップ システムなど、依存するテクノロジはすべて、この分離されたネットワークで使用できるようにします。可能であれば、この隔離されたネットワークに専用に接続された専用の管理システムを使用して、仮想化インフラストラクチャのすべての管理タスクを実行します。

アイデンティティとアクセス管理

ESXi と vCenter Server を Active Directory から切り離し、vCenter Single Sign-On を使用することを検討します。ESXi と vCenter を Active Directory から切り離すことで、漏洩した Active Directory アカウントが仮想化インフラストラクチャへの直接認証に使用されるのを防ぐことができます。管理者は、仮想化インフラストラクチャの管理とアクセスに、個別の専用アカウントを使用するようにします。vCenter Server インスタンスへのすべての管理アクセスに多要素認証 （MFA） を適用し、すべての管理者資格を特権アクセス管理 （PAM） システムに保存します。

サービスの管理

ESXi ホストのサービスおよび管理をさらに制限するには、ロックダウン モードを実装します。これにより、ESXi ホストは vCenter Server を介してのみアクセスできるようになり、一部のサービスが無効化され、一部のサービスが特定の定義されたユーザに制限されます。内蔵の ESXi ホスト ファイアウォールを設定して、分離されたネットワーク上の管理システムに関連する特定の IP アドレスまたはサブネットからの管理アクセスのみを制限します。vSphere Installable Bundles （VIB）に対する適切なリスク許容レベルを決定し、ESXi ホストのセキュリティ プロファイルで許容レベルを適用します。これにより、ホストの整合性が保護され、署名されていない VIB をインストールできないようにします。

ログ管理

ESXi 環境のログを一元管理することは、潜在的な悪意のある動作をプロアクティブに検出し、実際のインシデントを調査するために重要です。ESXi ホストと vCenter Server のすべてのログが、組織の SIEM ソリューションに転送されることを確認します。これにより、通常の管理作業以外のセキュリティ イベントを可視化することができます。

謝 辞

Brad Slaybaugh、Joshua Kim、Zachary Smith、Jeremy Koppen、Charles Carmakalには、本ブログで取り上げたマルウェア群の調査、技術検討、検出・調査手法の確立にご協力いただきました。また、VMware社には、この調査への協力に感謝します。

※本ブログは、2022年9月29日に公開されたブログ「Bad VIB(E)s Part Two: Detection and Hardening within ESXi Hypervisors」の日本語抄訳版です。