パート 1では、攻撃者が悪意のあるvSphere インストール バンドル(「VIB」) を使用して、ESXi ハイパーバイザー全体に複数のバックドアをインストールする方法を取り上げ、VIB ペイロード内に存在するマルウェアに焦点を当てました。この記事では、タイムスタンプなどの他の攻撃者のアクションについてさらに詳しく説明し、プロセス メモリをダンプして YARA スキャンを実行する ESXi 検出方法について説明し、ハイパーバイザーをさらに強化して ESXi ホストの攻撃面を最小限に抑える方法について説明します。詳細については、 VMware がvSphere の保護に関する追加情報をリリースしています。
ESXi ロギング
VIRTUALPITA と VIRTUALPIE はどちらも、起動時にvmsyslogd
プロセスがアクティビティを記録するのを停止しますが、ハイパーバイザー全体に複数のログ プロセスが存在し、攻撃者のアクティビティを追跡するために引き続き使用できます。
悪意のある VIB のインストール
許容レベルが記述子 XML で変更された場合でも、ESXi システムでは最小許容レベルを下回る偽造 VIB ファイルが許可されないことがパート 1で以前に確認されました。これを回避するために、攻撃者は--force
フラグを悪用して、悪意のあるCommunitySupported
VIB をインストールしました。このフラグは、 ホストが要求するよりも低い許容レベルを持つ VIB またはイメージ プロファイルを追加します。
VIB をインストールするための--force
フラグの使用の証拠は、ESXi ハイパーバイザーの複数の場所で見つかりました。 ESXi プロファイル XML ファイルは、システムにインストールされたすべての VIB を記録し、各 VIB のインストールに使用される日付、時刻、およびフラグを指定します。このファイルは、パス/var/db/esximg/profile
の下にあります。図1 プロファイル XML ファイルに記録された攻撃者の--force
フラグの使用例が含まれています。
/var/log/
ファイルesxupdate.log
にも、VIB のインストール時に--force
フラグの使用が記録されました。図 2 には、悪意のある VIB が強制的にインストールされていることを記録したイベントが含まれています。
さらに、 VMware では、セキュア ブートの有効化を推奨しています。これにより、ESXi は最初のシステム ブート時に暗号化方式を使用してソフトウェア、ドライバー、およびその他のコンポーネントを検証し、それらのコンポーネントが正当であるかどうかを判断できます。 VMware のガイダンスによると、「vSphere でのトラステッド プラットフォーム モジュール (TPM) 2.0 のセキュア ブート サポートは、システム構成だけでなく、セキュア ブートからのデータを調べることで、vCenter Server が環境の状態を証明または検証できるようにすることで、ESXi セキュア ブート上に構築されます。情報。 vSphere 7 で導入された vSphere Trust Authority は、vSAN および VM 暗号化に使用される暗号化キーへのアクセスを継続的なホスト認証に結び付けます。 vSphere 信頼機関での構成証明に失敗したホストは、シークレットへのアクセスを拒否されます。
タイムスタンプ
Mandiant は、早くも 2013 年 10 月 9 日に--force
フラグが設定された VIB インストールに関するログが記録されていることを確認しましたが、これは攻撃のタイムラインと一致していませんでした。ログ ファイル/var/log/vmkwarning.log
は、システム時間が操作されていることのさらなる証拠を提供しました。図 3には、攻撃者のアクションが発生する直前と直後にシステム クロックが変更されたことを記録した 2 つのイベントが含まれています。この動作は、攻撃者がマシンに VIB を最初にインストールした実際の時間を隠蔽するために、タイムスタンプが実行されたことを示唆しています。
sysclogの作成
VIRTUALPITA サンプルrhttpproxy-io
(2c28ec2d541f555b2838099ca849f965) を分析すると、サンプルが VMCI ポート番号18098でリッスンしていることがわかりました。リスナーが設定されると、マルウェアは IOCTL 要求コード 1977 を発行して、システムの CID (コンテキスト ID) をフェッチします。バックドアの PID、CID、およびリッスン ポートは、次の形式で/var/log/sysclog
に記録されます[<date/timestamp>]nr[!]<<PID>>:<CID>:<port>nn
(図 4 参照)。
ゲスト マシンの相互作用
ハイパーバイザーとそれぞれのゲスト マシン間のさらなる相互作用は、 vmware.log
という名前の複数のログで発見されました。これらのログは、パス/vmfs/volumes/…/<virtual machine hostname>/vmware.log
にあり、エンドポイントに記録されていないホストとハイパーバイザー間の基本的な操作を記録します。このログに記録されるアクションには、ゲスト マシンのログイン、ファイル/ディレクトリの作成と削除、コマンドの実行、およびゲスト マシンとハイパーバイザー間のファイル転送が含まれます。 vmware.log でハイパーバイザーとそのゲスト マシン間のやり取りに注目するには、GuestOps vmware.log
含む行をフィルター処理します。
大規模な VIB 検証
以前のブログ投稿では、コマンドesxcli software vib signature verify
を使用して、ESXi ハイパーバイザーによって行われた署名検証チェックに合格しない VIB を特定することに触れました。署名検証チェックを回避できる代替 VIB 構成が存在します。 Mandiant は、VIB がCommunitySupported
としてインストールされている場合、インストール後にペイロードが改ざんされていない場合、 Signature Verification
フィールドはそれをSucceeded
とラベル付けすることを確認しました。これは、VMWare またはそのパートナーからの検証なしで VIB を作成しても、検証済みとしてラベル付けされる可能性があることを意味します。
適切に署名されたCommunitySupported
VIB および悪意のあるアクティビティを示す可能性のあるその他の異常な構成を説明するために、 VMware は、軽減ガイドの「脅威ハンティング」セクションで、環境の監査プロセスを自動化する検出スクリプトを利用できるようにしました。
さらに、環境内のすべての 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 からいずれかのマルウェア ファミリを起動している場合、.vgz 形式で圧縮されているため、VIB 内のサンプルは検出されません。第 2 に、バイナリがメモリ内で実行されているがディスクから削除されている場合、そのバイナリは YARA のファイル システム スキャンによって検出されません。
YARA は ESXi ホスト上で直接実行されないため、Mandiant はsshfs
を利用して ESXi ハイパーバイザーのリモート YARA スキャンを実行しました。
前提条件
注:ESXi のすべての動作とメモリをダンプする方法論は、ESXi 6.7 で確認されています。現時点では、他のバージョンはテストされていません。 |
ESXi マシンをスキャンする前に、いくつかの前提条件を満たす必要があります。メモリがダンプされている ESXi マシンの場合、次の両方が必要です。
- マシンへのルートアクセス
- ESXi サーバーでSSH が有効になっている
ESXi マシンが正しく構成されたら、SSH 経由で ESXi マシンと通信できるように Linux マシンをセットアップする必要があります。この Linux マシンには、以下もインストールする必要があります。
- sshfs
- 子供
YARA スキャンの実行
注: YARA は自然にディレクトリを再帰的にスキャンし、sshfs はアクセス時にファイルをプルバックするため、ネットワーク帯域幅によっては、ESXi ファイル システム全体のスキャンに時間がかかる場合があります。このスキャン方法は、強力で安定したネットワーク接続が存在する場合にのみ推奨されます。 |
説明 |
コマンド |
ESXi マシンをマウントするディレクトリを作成する |
> mkdir /mnt/yara |
sshfs を使用して、ESXi ルート ディレクトリを Linux マシンのマウント ポイントにマウントします。 |
|
ESXi システムが接続されているマウント ポイントをスキャンします。 |
|
ESXi プロセス メモリのダンプ
Linux マシンのように ESXi ハイパーバイザーからプロセス メモリをダンプしようとすると、/proc/ ディレクトリが空であるか、メモリのダンプを試みるために使用されるコマンドの単一の PID が含まれていることがすぐに明らかになります。 ESXi からプロセス メモリ (および場合によっては完全なバイナリ自体) を回復するには、ネイティブ ツールgdbserverとcore2ELF64と呼ばれる github ツールを組み合わせて使用できます。
前提条件
注:ESXi のすべての動作とメモリをダンプする方法論は、ESXi 6.7 で確認されています。現時点では、他のバージョンはテストされていません。 |
プロセス メモリをダンプする前に、いくつかの前提条件を満たす必要があります。 ESXi マシンの場合、次の両方が必要です。
- マシンへのルートアクセス
- ESXi サーバーでSSH が有効になっている
ESXi マシンが正しく構成されたら、SSH 経由で ESXi マシンと通信できるように Linux マシンをセットアップする必要があります。この Linux マシンには、以下もインストールする必要があります。
- gdb
- core2ELF64
メモリのダンプ
注: リッスンするポートと転送するポートは任意です (経験則: よく使用されるポートを避けるため、1024 ~ 25565 の間で維持します)。このチュートリアルでは、リッスン ポートは 6000 で、転送ポートは 7000 です。 |
ESXi プロセス メモリをダンプするには、gdbserver を使用して、PID で指定された現在実行中のプロセスにフックし、任意のポートでリッスンします。
説明 |
コマンド |
次のコマンドで収集する PID が意図したものであることを確認するために使用されるプリエンプティブ チェック。このステートメントの出力が、メモリをダンプする予定のプロセスのみを示していることを確認してください。 |
|
list processes コマンドで指定された PID に gdbserver を接続し、ポート 6000 で gdb の接続先をリッスンします。 |
|
リッスンすると、Linux マシンは ESXi サーバーのリッスン ポートへの SSH トンネル (ポート転送) を作成します。ここで、指定されたプロセスのコア ダンプを作成するために gdb が使用されます。
説明 |
コマンド |
Linux マシンから ESXi Server gdbserver プロセスのリッスン ポートへの SSH トンネルを設定します。 |
|
gdb を起動 |
|
gdb シェル内で、gdbserver インスタンスに接続します。このコマンドを正常に実行して gdb シェルを終了した場合は、ESXi で gdbserver プロセスを終了して再起動し、再接続する必要があります。 |
|
作業ディレクトリにアタッチ プロセスのメモリのコア ダンプ ファイルを作成します。出力ファイルは、次の構文「core.[0-9]{7}」である必要があります。 |
|
プロセス抽出
コア ファイルが作成されると、Github プロジェクト core2ELF64 を使用してプログラムを再構築できます。
説明 |
コマンド |
Linux マシンから ESXi Server gdbserver プロセスのリッスン ポートへの SSH トンネルを設定します。 プログラムが最初のセグメントを復元できない場合は、次に利用可能なセグメント (最小数) を選択します。 |
|
ソース
ESXi の強化
ネットワークの分離
ESXi ホストでネットワークを構成する場合は、分離された管理ネットワークで VMkernel ネットワーク アダプタのみを有効にします。 VMkernel ネットワーク アダプタは、ESXi ホストにネットワーク接続を提供し、vSphere vMotion、vSAN、vSphere レプリケーションなどの機能に必要なシステム トラフィックを処理します。仮想化インフラストラクチャが使用する vSAN やバックアップ システムなどのすべての依存テクノロジが、この分離されたネットワークで利用できることを確認します。可能であれば、この分離されたネットワークに排他的に接続された専用の管理システムを使用して、仮想化インフラストラクチャのすべての管理タスクを実行します。
ID とアクセス管理
ESXi および vCenter Server を Active Directory から分離し、vCenter Single Sign-On を使用することを検討してください。 Active Directory から ESXi と vCenter を削除すると、侵害された Active Directory アカウントを使用して仮想化インフラストラクチャを直接認証することができなくなります。管理者が仮想化インフラストラクチャの管理とアクセスに個別の専用アカウントを使用していることを確認してください。 vCenter Server インスタンスへのすべての管理アクセスに多要素認証 (MFA) を適用し、すべての管理資格情報を Privileged Access Management (PAM) システムに保存します。
サービス管理
ESXi ホストのサービスと管理をさらに制限するには、ロックダウン モードを実装します。これにより、vCenter Server を介してのみ ESXi ホストにアクセスできるようになり、一部のサービスが無効になり、一部のサービスが特定の定義済みユーザーに制限されます。組み込みの ESXi ホスト ファイアウォールを構成して、隔離されたネットワーク上の管理システムに関連する特定の IP アドレスまたはサブネットからのみ管理アクセスを制限します。 vSphere Installable Bundle (VIB) の適切なリスク許容レベルを決定し、ESXi ホストのセキュリティ プロファイルで許容レベルを適用します。これにより、ホストの整合性が保護され、署名されていない VIB をインストールできないようになります。
ログ管理
潜在的な悪意のある動作をプロアクティブに検出し、実際のインシデントを調査するには、ESXi 環境の集中ログが重要です。すべての ESXi ホストと vCenter Server のログが組織の SIEM ソリューションに転送されていることを確認します。これにより、通常の管理アクティビティ以外のセキュリティ イベントを可視化できます。
謝辞
Brad Slaybaugh、Joshua Kim、Zachary Smith、Jeremy Koppen、Charles Carmakal の各氏には、このブログ投稿で説明したマルウェア ファミリの調査、技術レビュー、および検出/調査手法の作成を支援していただき、特に感謝しています。さらに、この調査に協力してくれた VMware にも感謝します。
参照: https://www.mandiant.com/resources/blog/esxi-hypervisors-detection-hardening
Comments