Blog

悪意のあるVIB(E) Part-2: ESXiハイパーバイザー内の検知とハードニング

Alexander Marvi, Greg Blaum
Sep 29, 2022
2 min read
|   Last updated: Oct 31, 2022
Detection

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

ESXIロギング

VIRTUALPITAVIRTUALPIEは、起動時に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 フラグの使用例を示しています。

ESXI Profile XML file with the presence of a --force installation
図1: -forceインストールがある場合のESXIプロファイルXMLファイル

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

VIB Installation with force flag in esxupdate.log
図2:esxupdate.log に force フラグを設定した 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 を最初にインストールした真の時刻を隠蔽するために、タイムストンプが実行されたことを示唆しています。

vmkwarning.log recording system time modification
図3:システム時間の変更を記録したvmkwarning.log

シスログの作成

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

Sample of sysclog
図4: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に示します。

Sample of Known Good VIB Matrix
図5: Known Good VIB Matrix のサンプル

ESXI 検出方法

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

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

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

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

前提条件

注:ESXiのすべての動作とメモリダンプの方法は、ESXi 6.7で確認されており、現時点では他のバージョンではテストされていません。

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

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

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

YARAスキャンの実行

注:YARAは当然ディレクトリを再帰的にスキャンし、sshfsはアクセスされたファイルを引き戻すので、ネットワークの帯域幅によってはESXiファイルシステム全体のスキャンに長い時間がかかる場合があります。このスキャン方法は、強力で安定したネットワーク接続が存在する場合にのみ推奨されます。

Linuxコマンド

Description

Commands

ESXiマシンをマウントするディレクトリの作成

> mkdir /mnt/yara

ESXiのルートディレクトリをLinuxマシンのマウントポイントにsshfsで
マウント

> sshfs -o allow_other,default_permissions [email protected]<Insert ESXi IP Address>:/ /mnt/yara

ESXi システムが接続されているマウントポイントをスキャン

> yara -r <Provided YARA Rule> <scope of scan>

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

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

前提条件

注:ESXiのすべての動作とメモリダンプの方法は、ESXi 6.7で確認されており、現時点では他のバージョンではテストされていません。

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

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

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

メモリのダンプ

注:リスニングとポートフォワードのポートは任意です(推奨:よく使われるポートを避けるため1024-25565の間にしてください)、このチュートリアルではリスニングポートは6000、フォワードポートは7000とします。

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

ESXiコマンド

Description

Commands

最初のコマンドで収集する PID が意図したものであることを確認するために使用されるプリエンプティブチェック。この文の出力が、メモリをダンプしようとするプロセスだけを示していることを確認

> ps -Tcjstv | grep -e “<Binary to Dump>”

list processesコマンドで指定されたPIDにgdbserverをアタッチし、gdbが接続できるようにポート6000でリスニング

> gdbserver –attach 127.0.0.1:6000 `ps -Tcjstv |

 grep -e “<Binary to Dump>” | awk ‘{print $1}’ | head -n 1`

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

Linux コマンド

Description

Commands

Linuxマシンから、ESXi Server gdbserverプロセスのリスニングポートにSSHトンネルを設定

> ssh -L 1336:127.0.0.1:6000 -f -N <acct on ESX>@<IP of ESX>

gdbの起動

> gdb

gdbシェル内で、gdbserverインスタンスに接続。このコマンドの実行に成功した時点でgdbシェルから抜けた場合、ESXi上のgdbserverプロセスを終了し、再接続する必要がある

(gdb) > target remote localhost:1336

アタッチプロセスのメモリのコアダンプファイルを作業ディレクトリに作成。出力ファイルは、次の構文 "core.[0-9]{7}"

?? () > gcore

プロセスの抽出

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

Linux コマンド

Description

Commands

Linux マシンから ESXi Server の gdbserver プロセスのリスニングポートに SSH トンネルをセットアップ

プログラムが最初のセグメントを回復できない場合、可能な限り次の利用可能なセグメントを選択(Smallest Number)

> core2ELF64 <core file> <Desired Output Name>

ソース

ESXiのハードニング

ネットワークの分離

ESXi ホストでネットワークを構成する場合、分離された管理ネットワークでは VMkernel ネットワーク アダプタのみを有効にしてください。VMkernel ネットワーク アダプタは、ESXi ホストにネットワーク接続を提供し、vSphere vMotionvSANvSphere レプリケーションなどの機能で必要なシステム トラフィックを処理します。仮想化インフラストラクチャで使用する 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 SlaybaughJoshua KimZachary SmithJeremy KoppenCharles Carmakalには、本ブログで取り上げたマルウェア群の調査、技術検討、検出・調査手法の確立にご協力いただきました。また、VMware社には、この調査への協力に感謝します。

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