ESXiの不審なアクティビティを検出してランサムウェア攻撃を防ぐ

世界中のサイバーセキュリティチームが、ESXiインフラを狙ったランサムウェア攻撃と長年にわたって戦い続けています。ESXiは、VMwareが開発した軽量のベアメタルハイパーバイザーで、複数の仮想マシンを1つの物理サーバー上で実行できます。エンタープライズ環境で広く利用されているESXiは、多くの場合、組織全体の重要なサービスを支える仮想マシンをホストしています。ESXiにアクセスできるようになると、攻撃者はファイルシステムの暗号化、ホストされている仮想マシンの停止、機密データの抽出、さらには攻撃のピボッティングを行うことが可能になります。

ESXiは、その特性上、リソースが集まる場所となるため、攻撃者にとって非常に魅力的な標的になっています。そのため、ひとたび侵害されると、環境全体に深刻な影響が及ぶ可能性があります。また、ESXiは十分に監視されていないことが多いため、システム上のアクティビティに関するインサイトが極めて乏しい点も懸念すべき問題です。2023年には、攻撃者がMGM Resorts社のESXiインフラストラクチャへ侵入し、わずか数日で100台以上のハイパーバイザーを暗号化しました。この攻撃により、同社は1億ドルもの損失を被りました。

このブログでは、ESXiログをSplunkに取り込む方法、注意すべき主なアクティビティ、そして包括的な検出戦略について解説します。

ESXiへの攻撃をSplunkで監視

データの取り込み

ESXiのログ設定では、syslogデータを外部のlogHostに送信するように構成できます。ここでは、送信先をSplunkとして話を進めます。Splunkでは、Splunk Connect for Syslogを利用したり、syslog-ngなどの専用syslogサーバーを利用したりするなど、さまざまな方法でsyslogデータを取り込むことができます。また、Splunk Universal Forwarder経由で直接データを取り込むことも可能です。

Splunk Connect for Syslog

このオープンソースのソリューションは、事前設定済みのフレームワークを備えたコンテナ化されたsyslog-ngサーバーを提供することで、Splunkへのsyslogの取り込みを簡素化します。また、デプロイの不整合、専門知識の不足、データの偏った分散といったよくある課題に対処します。このソリューションは、Docker、Podman、またはKubernetesを使ってデプロイできます。このソリューションが推奨されるのは、特に大規模な環境において、syslogデータの取り込みを簡素化したい場合です。

Syslog ServerとUniversal Forwarder

syslogサーバー(syslog-ngやrsyslogなど)を、syslogメッセージを受信してファイルに書き込めるように設定します。次に、そのファイルをSplunk Universal Forwarderで監視し、データをSplunkインデクサーに送信します。この方法により、内容に基づいたデータのフィルタリングやルーティングの柔軟性が向上します。ただし、使用するファイル用に以下のようなinputs.confを作成する必要があります。

[monitor:///var/log/.../syslog.log]
disabled = false
index = vmware-esxilog
sourcetype = vmw-syslog

Splunkへの直接取り込み

syslogデータをSplunkに直接(別途syslogサーバーを使用せずに)取り込むことは可能ですが、一般的には推奨されません。特に大規模な環境や高可用性が必要な状況では、Splunkが停止すると、データが失われる可能性があるからです。ただしテスト目的であれば、この方法によって、SplunkでのESXiログの取り込みを低コストで試すことができます。

Splunk TA

SplunkでESXiデータを実際に扱うには、以下の2つのテクノロジーアドオンが必要です。

• Splunk Add-on for VMware ESXi Logs：このアドオンには、コメントアウトされた入力設定が用意されているほか、Splunk環境でVMware ESXiログの収集、解析、取り込みを行うために検索時とインデックス作成時にログを抽出できる機能が搭載されています。
• Splunk Add-on for VMware Indexes：このアドオンに含まれているパッケージ(「SA-VMWIndex」)は、Splunk Add-on for VMware、Splunk Add-on for vCenter Logs、およびSplunk Add-on for VMware ESXi Logsで使用されるインデックスの定義を提供します。

ESXiの設定

Splunkソリューションの選定と設定が完了したら、ESXiからsyslogデータを転送するための設定を行う必要があります。幸いにも、この作業はとても簡単です。ESXiのGUIで、[Manage] > [System] > [Advanced Settings]に移動してlogHostを検索すると、ログ設定を変更できます。ログの送信先を「proto://ホスト名:ポート番号」の形式で設定してください。

図1：ESXiのGUIでの設定

ESXiログの分類

ESXiにはさまざまなログが数多く存在し、すべての設定が完了するとSplunkに取り込まれます。目的のアクティビティを検出するには、各ログにどのようなデータが含まれているかを把握することが重要です。以下のリストはすべてを網羅しているわけではありませんが、最初に学習するのに適したログをまとめています。

Shellログ

このログには、ESXiシステム自体で実行されたコマンドが記録されます。たとえば、catのような通常のシェルコマンドや、ESXiコンポーネントとのやり取りに使用されるesxcliコマンドなどです。

Jul  1 15:59:59 192.168.8.233 2025-07-01T15:58:48.124Z localhost.localdomain shell[1627100]: [root]: esxcli system account add -i svcuser -p h@ckAway! -c h@ckAway!

このログの先頭には、タイムスタンプと、ログが作成されたESXiホストの情報が記録されます。その後に、shell[pid]情報、[ユーザー]コンテキスト、および最後に実行されたコマンドが続きます。

Hostdログ

このログには、ホスト管理サービスからのアクティビティが記録されます。たとえば、仮想マシンのライフサイクルイベント、ユーザー認証、vSphereクライアントまたはAPI経由で行われた変更などです。つまり、ESXiホスト自体に影響を与える変更が記録されます。

May 12 19:41:28 192.168.8.233 2025-05-12T19:39:40.901Z localhost.lan Hostd[263214]: [Originator@6876 sub=Vimsvc.ha-eventmgr] Event 3240 : Administrator access to the host has been enabled.

Shellログに似ていますが、ログを生成したhostdのサブシステムが含まれている点が大きく異なります。

VMK警告ログ

Vmkwarningは、vmkernelログのうち、警告レベルのイベントを中心に抽出して示します。冗長なカーネルログを解析することなく、設定ミスや、ハードウェア変更の初期兆候をすばやく把握するのに便利です。

May 15 16:08:00 192.168.8.233 2025-05-15T16:07:04.134Z localhost.localdomain vmkwarning: cpu1:263203 opID=1cc2a6d6)WARNING: NTPClock: 1449: system clock stepped to 1736960820.000000000, but delta 10364403 > 172800 seconds

このログも、先頭にタイムスタンプとホスト情報が記録されます。そして、vmkwarningの後に、イベントを処理したCPUコアとカーネルスレッドが記録されます。opIDは、同じ操作チェーン内で発生したイベントを相関付ける際に役立ちます。さらに、警告を発したコンポーネント(ここではNTPClock)と実際の警告メッセージがその後に続きます。

ESXi更新ログ

このログには、パッチの適用とVIB (vSphere Installation Bundle)のインストールが記録されます。このログを監視することで、バックドアや永続化メカニズム、悪質なドライバーのインストールに使用される可能性のある不正なVIBを検出することができます。

May  7 18:07:11 192.168.8.233 2025-05-07T18:07:09Z localhost.localdomain esxupdate[264778]: runcommand called with: args = ['/usr/lib/vmware/vob/bin/addvob', 'vob.user.esximage.install.securityalert', '(Updated) ESXi-8.0U3e-24677879-standard', 'acceptance level checking disabled'], outfile = None, returnoutput = True, timeout = 0.0.
May  7 18:07:11 192.168.8.233 2025-05-07T18:07:09Z localhost.localdomain esxupdate[264778]: Attempting to install an image profile bypassing signing and acceptance level verification. This may pose a large security risk.

ESXi更新ログでは、メッセージ領域にさまざまな内容が含まれますが、すべてのログに、タイムスタンプ、ホスト情報、およびコンポーネント(esxupdate)がこの順番で記録されます。

ESXiへの攻撃の検出

Splunk脅威調査チームによる分析ストーリー

セキュリティチームが破壊的な攻撃を阻止できるよう支援するため、私たちはSplunkで使用できる包括的な検出ルールを開発しました。開発にあたっては、ESXiへの攻撃に固有のパターンや挙動を特定できるようにすることに注力しました。また、組織がこのルールを迅速にデプロイできるように、分析ストーリーも用意しました。以下に、悪質なESXiアクティビティに焦点を当てた検出の例をいくつかご紹介します。

ESXiに対する偵察

攻撃者が最初によく行うアクティビティの1つは、次のターゲットを見つけ出すことを目的としたシステムの偵察です。攻撃者は、システム情報、仮想マシン情報、アカウント情報を収集するだけでなく、機密ファイルを徹底的に調べて利用できるデータを探します。

システム情報の探索

以下は、構成情報を取得するESXCLIのシステムレベルのコマンドが使用されたことを検出するルールです。これらのコマンドは正当な管理目的で使用されることもありますが、攻撃者がこれらのコマンドを利用して偵察活動を行い、ESXiホストの機能やビルド情報、システムロールなどを特定して、さらなる侵害の準備を整えている可能性もあります。

`esxi_syslog` Message="*system*" AND Message="*esxcli*" AND Message IN ("*get*","*list*")
  AND Message="*user=*" NOT Message="*filesystem*"
  | rex field=_raw "user=(?\w+)\]\s+Dispatch\s+(?[^\s]+)"
  | rex field=_raw "Z (?[\w\.]+)\s"
  | stats min(_time) as firstTime max(_time) as lastTime count by dest user command
  | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`

図2：システム情報の探索

ESXiでの不審なアカウントアクティビティ

ESXi環境では、攻撃者が制御を獲得したり検出を回避したりするために特権アクセスを標的とする傾向があるため、アカウント侵害の兆候を監視することが極めて重要です。ESXiのUIにroot権限で直接アクセスすれば、ロールベースアクセス制御や監査機能を回避できるため、窃取または共有された認証情報を持つ攻撃者によって、いつの間にかシステム構成を変更される可能性があります。同様に、ユーザーに管理者ロールが予期せず割り当てられると、権限を昇格できるバックドアが攻撃者に開かれることになります。

外部からのroot権限によるログイン

以下は、委任された管理者ユーザー以外の人が、rootアカウントを使ってESXiのUIにアクセスしたことを検出するルールです。root権限でUIに直接アクセスすると、ロールベースアクセス制御や監査機能を回避できます。そのため、このような挙動が検出されると、危険な動作、設定ミス、または侵害された認証情報を使った攻撃者による不正なアクティビティが行われている可能性があります。

`esxi_syslog` Message="*root*" AND Message="*logged in*"
  | rex field=_raw "root@(?\d{1,3}(?:\.\d{1,3}){3})"
  | rex field=_raw "Z (?[\w\.]+)\s" | search SrcIpAddr != "127.0.0.1" AND SrcIpAddr != 192.168.0.0/16 AND SrcIpAddr != 172.16.0.0/12 AND SrcIpAddr != 10.0.0.0/8 | stats min(_time) as firstTime max(_time) as lastTime count by dest SrcIpAddr | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`

図3：外部からのroot権限によるログイン

ユーザーへの管理者ロールの付与

以下は、ESXiホスト上でユーザーに管理者ロールが付与されたことを検出するルールです。昇格された権限の付与は重大な操作であり、予期せず行われると、攻撃者によって制限なしで不正な操作が行われるリスクが高まります。

`esxi_syslog` Message="*esxcli system permission set*" AND Message="*role Admin*"
  | rex field=_raw "\]: \[(?\w+)\]:(?.+)"
  | rex field=_raw "--id (?\w+)"
  | rex field=_raw "Z (?[\w\.]+)\s" | stats min(_time) as firstTime max(_time) as lastTime count by dest user command target_user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`

図4：ユーザーへの管理者ロールの付与

ESXiでのソフトウェアインストールの試み

攻撃者は、システムを侵害したり潜伏を続けたりする目的でソフトウェアインストールの仕組みを頻繁に悪用します。そのため、ESXiホスト上でソフトウェアインストールに関連する不審なアクティビティを監視することが極めて重要です。VIBの受け入れレベルが変更されるとシステムの整合性ポリシーの適用が弱まり、署名のないソフトウェアや未検証のソフトウェアがインストールされる可能性があります。また、攻撃者はVIBのインストール時に--forceフラグを使用して、署名や互換性のチェックを回避することがよくあります。これにより、バックドアが含まれていたり、互換性がなかったりといった、悪質なカーネルモジュールやツールが展開されるリスクが高まります。さらに、ファイルのダウンロードの失敗は、コンポーネントのインストールや更新を目的とした不正な操作や悪質な試みを示していることがあります。こうしたアクティビティは、攻撃者がシステムの侵害後に永続的なアクセスを確立したり、ハイパーバイザー上での制御を拡大したりする兆候であることが少なくありません。

VIB受け入れレベルの改ざん

ESXiホストにおけるVIBの受け入れレベルの変更は、非常に重要な検出対象です。受け入れレベルがCommunitySupportedなどに変更されると、システムの整合性ポリシーの適用が弱まり、署名のないソフトウェアや未検証のソフトウェアがインストールされる可能性があります。

`esxi_syslog` Message="*esxcli software acceptance set*" Message="*shell*"
  | rex field=_raw "\]: \[(?\w+)\]:(?.+)"
  | rex field=_raw "Z (?[\w\.]+)\s" | stats min(_time) as firstTime max(_time) as lastTime count by dest user command | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`

図5：VIB受け入れレベルの改ざん

ESXiのアクセス権限の変更

攻撃者は、セキュリティ制御を弱体化させて永続的なアクセス権を取得するために、よくESXiホストの設定を操作します。たとえば、SSHやESXiシェルなどのリモートアクセスサービスを有効にして、最初の侵害後に足場を確保したり、制御を維持したりする場合があります。また、ロックダウンモードやホストのファイアウォールなどの重要なセキュリティ機能を無効化することで、アクセス範囲を拡大したり、ネットワーク制限を回避したりすることもよくあります。これにより、データの窃取、ラテラルムーブメント、有害なソフトウェアのインストールなど、さらに悪質なアクティビティの実行が容易になります。

SSHの有効化

以下は、ESXiホストでSSHが有効にされていることを検出するルールです。このような挙動は、悪質なアクティビティの早期の兆候である可能性があります。攻撃者は、認証情報の侵害や脆弱性の悪用を行った後、永続的なリモートアクセスを確立する目的でよくSSHを利用します。

`esxi_syslog` Message="*SSH access has been enabled"
  | rex field=_raw "Z (?[\w\.]+)\s"
  | stats min(_time) as firstTime max(_time) as lastTime count by dest Message
  | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`

図6：SSHの有効化

ESXiの仮想マシンに対するアクティビティ

攻撃者は、運用を妨害して機密データを流出させるためにESXiホストを頻繁に狙います。たとえば、ハイパーバイザーの防御を弱体化してホストへのアクセスを容易にするために、セキュアブートや実行可能ファイルの検証に関連する重要なセキュリティポリシーの適用設定を無効化しようとすることがあります。攻撃者は、さらに破壊的な攻撃として、ホスト上のすべての仮想マシンを突然停止させることがあります。これは、意図的なサービス拒否攻撃や重要なワークロードの破壊を試みている可能性を示しています。また、攻撃者が正規のリモートツールやプロトコルを悪用して、データストアから仮想マシンのディスクファイル全体をダウンロードし、大量の機密データを窃取することも少なくありません。

暗号化設定の変更

以下は、ESXiホストで、セキュアブートや実行可能ファイルの検証要件などに関連する重要な暗号化ポリシーの適用設定が無効化されたことを検出するルールです。このような挙動が検出されると、ハイパーバイザーの整合性を低下させたり、不正なコードの実行を可能にしたりする試みが行われている可能性があります。

`esxi_syslog` Message="*system settings encryption set*" NOT Message="*shell.*"
  Message IN ("* -s *", "* -e *","*--require-secure-boot*", "*require-exec-installed-only*", "execInstalledOnly")
  | rex field=_raw "Z (?[\w\.]*)\s.*\]: \[(?\w+)\]:(?.+)"
  | stats min(_time) as firstTime max(_time) as lastTime count by dest user command
  | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`

図7：暗号化設定の変更

リモートツールによる仮想マシンのエクスポート

以下は、リモートツールを使ってデータストアから仮想マシンのディスクファイルをダウンロードする動作を監視するルールです。NFCプロトコルは、管理ツールがESXiホストとの間でファイルをやり取りする際に使用しますが、攻撃者や内部者によって悪用され、仮想ディスクイメージ全体が持ち出される可能性もあります。

`esxi_syslog` Message="*File download from path*" Message="*was initiated from*"
  | rex field=_raw "from path ''\[(?[^\]]+)\](?[^'']+)''"
  | rex field=_raw "initiated from ''(?[^/]+)/(?[^@]+)@(?\d{1,3}(?:\.\d{1,3}){3})''"
  | rex field=_raw "Z (?[\w\.]+)\s"
  | stats min(_time) as firstTime max(_time) as lastTime count by Datastore VMPath InitiatorTool ToolVersion InitiatorIP dest
  | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`

図8：仮想マシンのエクスポート

ESXi内の痕跡の除去

root権限を持つ攻撃者はたいてい、システムへのアクセスを確保すると、すぐに自身の痕跡を隠そうとします。ESXiでは、痕跡を隠すために、auditrecordsコマンドを使った監査機能の無効化、syslog設定の変更、時間に基づく検出を回避するためのシステムクロックの改ざんなどが行われる可能性があります。

監査ログの改ざん

以下は、esxcli system auditrecordsコマンドの使用を監視するルールです。このコマンドは、ESXiホスト上のログの改ざんに使われる可能性があります。この操作が検出された場合、攻撃者が検出を回避したりフォレンジック分析を妨害したりする目的で、システムレベルの監査イベントの記録を阻止しようとした可能性があります。

`esxi_syslog` Message="*esxcli system auditrecords*" Message IN ("*remote*","*local*") NOT Message = "*[shell*"
  | rex field=_raw "Z (?[\w\.]+)\s"
  | rex field=_raw "[\w+]\]: (?.*)"
  | rex field=full_command "\[(?.*)]:\s(?.*)"
  | stats min(_time) as firstTime max(_time) as lastTime count by dest user command
  | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`

図9：監査ログの改ざん

Syslog設定の変更

以下は、esxcliを使ってESXiホスト上でsyslog設定が変更されたことを検出するルールです。このような挙動が検出されると、ログ収集を妨害して検出を回避しようとする試みが行われている可能性があります。

`esxi_syslog` Message="*syslog config set*" AND Message="*esxcli*"
  | rex field=_raw "\].*\[\s*(?P[^\]]+)\]:\s(?P.+)"
  | rex field=_raw "Z (?[\w\.]+)\s"
  | stats min(_time) as firstTime max(_time) as lastTime count by dest user command
  | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`

図10：Syslog設定の変更

また、loghostキーやlogdirキーも直接監視できます。以下は、ESXiホスト上でこれらの設定が変更されたことを検出するルールです。このような挙動が検出されると、ログの転送を妨害したり検出を回避したりしようとする試みが行われている可能性があります。

`esxi_syslog` Message="*Set called with key*" AND Message IN ("*Syslog.global.logHost*","*Syslog.global.logdir*")
  | rex field=_raw "key ''(?[^'']+)'', value ''\"(?[^\"]+)\"''"
  | rex field=_raw "Z (?[\w\.]+)\s"
  | stats min(_time) as firstTime max(_time) as lastTime count by dest key value
  | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`

図11：loghostキーの監視

システムクロックの操作

以下は、ESXiホスト上でシステムクロックが大幅に変更されたことを検出するルールです。このような挙動が検出されると、タイムスタンプを操作して検出やフォレンジック分析を回避しようとする試みが行われている可能性があります。

`esxi_syslog` Message="*NTPClock*" AND Message="*system clock stepped*"
  | rex field=_raw "stepped to (?\d+\.\d+),.+delta\s(?\d+)\s"
  | rex field=_raw "Z (?[\w\.]+)\s"
  | eval epoch_time=tonumber(epoch_time)
  | eval delta=tonumber(delta)
  | eval event_time=round(_time, 0)
  | eval direction=if(epoch_time < event_time, "backward", "forward")
  | eval original_time=if(direction=="backward", epoch_time + delta, epoch_time - delta)
  | eval stepped_to_str=strftime(epoch_time, "%Y-%m-%d %H:%M:%S")
  | eval original_time_str=strftime(original_time, "%Y-%m-%d %H:%M:%S")
  | stats min(_time) as firstTime max(_time) as lastTime count by dest direction original_time_str stepped_to_str epoch_time delta
  | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`

図12：システムクロックの操作

詳細情報

セキュリティ分析ストーリーの最新コンテンツは、research.splunk.comとSplunk ES Content Update Appでご覧いただけます。

また、Splunk脅威調査チームの分析ストーリーや、ESXiの侵害後の対応に関するブログ記事では、さまざまなアクティビティや攻撃パターンに対する検出ルールを包括的に紹介しています。

フィードバック

ご意見やご要望がございましたら、GitHubから遠慮なくお寄せください。Slackチャネル「#security-research」にご参加いただくこともできます。SlackのSplunkユーザーグループへの招待が必要な場合は、こちらの手順に従ってください。

寄稿者

このブログ記事を執筆したRaven Taitと、検出内容と分析にご協力いただいたSplunk脅威調査チームのメンバー(Lou Stella、Bhavin Patel、Rod Soto、Eric McGinnis、Michael Haag、Nasreddine Bencherchali、Teoderick Contreras、Patrick Bareiss)に感謝を申し上げます。

このブログはこちらの英語ブログの翻訳、森本 寛之によるレビューです。