ESXi 勒索软件运行时取证与防御体系构建：基于三起真实事件的实战分析

作者：tzhtdx（应急响应工程师）

适用：安全研究员 / IR 工程师 / 虚拟化安全运维

ESXi 版本：6.7.0 (15160138) / 7.0.3 (18644231) / 8.0.3 (24677879) 三版本实机验证

关键词：ESXi 勒索 / 运行时取证 / vsish / ExecInstalledOnly / lsof / 版本差异

---

摘要

• 三起 ESXi 勒索事件攻击链高度一致：Horizon 漏洞 → 域横向 → vpxuser SSH → 投递加密器 → 破坏虚拟化存储


• ESXi 无 Linux 式 /proc，传统进程取证方法全部失效


• 通过 lsof -p <cartel> 可获取已删除二进制的内存映射路径与大小（VMkernel 级取证）


• ExecInstalledOnly 在 8.x 上默认拦投递 ELF（Operation not permitted），在 6.7/7.0.3 上默认放行


• 构建了五层监控守护，在三个版本上端到端验证通过（含加密行为检测与进程内存取证）


• 附完整版本兼容性矩阵、防御自查清单与 IOC 列表

---

1. 背景

2025 年以来，针对 VMware ESXi 的勒索软件攻击持续升级。ESXiArgs、Cheerscrypt、Black Basta 等组织均以 ESXi 为主要目标。近期我们处置的三起事件（制造/科技/汽车行业）呈现高度一致的攻击链——攻击者通过未修复的 VMware Horizon 漏洞获取内部网络初始访问，随后利用被盗的 vpxuser 凭据通过SSH 批量登录 ESXi，投递 ELF 加密器对虚拟化存储进行加密。

与 Linux 服务器不同，ESXi 的取证面临独特挑战：

┌───────────────────────────┬─────────────────────────────────────────────┐

│ Linux Server              │ ESXi (VMkernel)                             │

├───────────────────────────┼─────────────────────────────────────────────┤

│ /proc/<pid>/exe           │ [X] no /proc (directory is empty)           │

│ /proc/<pid>/maps          │ [X] none                                    │

│ /proc/<pid>/mem           │ [X] none                                    │

│ ptrace(PTRACE_ATTACH)     │ [X] disabled at kernel level                │

│ gcore <pid>               │ [X] command not available                   │

│ lsof                      │ [!] present, but format/paths differ        │

│ strace                    │ [!] present, but unusable (ptrace disabled) │

│ busybox                   │ [OK] /usr/lib/vmware/busybox/bin/           │

└───────────────────────────┴─────────────────────────────────────────────┘

ESXi 的 VMkernel 是闭源微内核，不是 Linux。 上述差异意味着传统 Linux IR 方法论在 ESXi 上全部失效，需要重新构建取证方法论。

---

2. 攻击链取证分析

2.1 完整攻击链

Phase 0: 初始访问

  利用未修复的 VMware Horizon 漏洞获取内部网络访问

  （Horizon 连接服务器 / UAG / Workspace ONE，未更新至最新版本）

       │

Phase 1: 域内横向

  vdiadmin → WinRM/PowerShell → 3,716 条 4648 事件 → 1,184 个目标

  PowerShell + C# 注入禁用 ETW (ntdll!EtwEventWrite)

  落地 kvcore.sys (BYOVD, 江民驱动) → kill AV/EDR

       │

Phase 2: 清痕

  Security 1102 + System 104 → 双清日志

       │

Phase 3: ESXi 批量登录

  vpxuser 凭据 → SSH → 多台 ESXi

  部分案件：govmomi/0.47.0 经 hostd API 启动 SSH

       │

Phase 4: 载荷投递与执行

  scp -t /var/log/ → e_esxi(ELF) + exec.sh(sh)

  chmod 777 → rm e_esxi(自删) → nohup exec.sh &

  esxcli ... ExecInstalledOnly → 0 (8.x 前置)

       │

Phase 5: 加密 + 勒索

  遍历 .vmdk/.vmx/.nvram/.vswp/.vmsn → 加密 → 改随机后缀

  落勒索信 → vSAN 对象删除 → VM 批量关机

2.2 载荷技术分析（静态逆向摘要）

以 e_esxi 样本为例（ELF 64-bit LSB，静态链接，~78KB）：

无第三方解密途径——除非攻击者私钥泄露或被执法查获。

2.3 攻击者对 ESXi 版本的选择逻辑

三案中攻击者统一执行：

esxcli system settings advanced set -o /User/execInstalledOnly -i 0

但该命令的实际效果因版本而异（实测确认）：

结论：8.x 上 ExecInstalledOnly 默认=1，是阻止投递 ELF 执行的关键防线。

攻击者必须先关闭它——而这一操作可通过 shell.log 检测。

---

3. ESXi 运行时取证：能力与限制

3.1 进程信息获取

ESXi 无 Linux 式 /proc，进程信息获取路径完全不同：

3.2 lsof 取证——文件删除后仍可见

ESXi 自带的 lsof 读取 vmkernel 内部数据，即使可执行文件已被 rm，

仍能看到 MMAP 映射的路径与大小：

$ lsof -p <cartel_id>

Cartel  | World name | Type | fd | Description

--------+------------+------+----+-------------

2105626 | sleep      | MMAP | -1 | /var/log/sleep (prot:R-/len:604124)

2105626 | sleep      | MMAP | -1 | /var/log/sleep (prot:-W/len:8844)

取证价值：确认可疑进程执行了哪个文件（即使文件已删除），

以及该文件的映射大小（可推断原始二进制大小）。

局限：无法从 MMAP 条目中恢复文件内容字节。

3.3 vsish 内核调试接口

vsish（VMkernel System Information Shell）是 VMware 内核调试工具，

暴露了 VMkernel 内部状态。关键路径：

/userworld/cartel/<id>/

├── cmdline          → 进程命令行

├── fd/fds/<fd>/     → 文件描述符详情（路径/类型/标志/偏移）

├── mem/mmaps/       → 内存映射区域列表

├── signal/handlers/ → 信号处理函数

├── signal/injectsignal → 向进程注入信号

├── stats/           → syscall/IO/socket 统计

├── thread/          → 线程列表

└── debug/

    ├── coreDumpEnabled  → core dump 开关（默认 0）

    ├── dumpOnKernelPanic → panic 时 dump

    └── livecore         → live core dump 触发器

^-^ 负责任披露声明：本文仅讨论 vsish 的取证分析用途。

其内核状态修改能力（如 signal/injectsignal、killswitches）

涉及 VMkernel 安全边界，不在本文讨论范围内。

---

4. 五层监控防御体系设计

4.1 设计原则

传统检测 = 规则匹配（"这个进程名/路径像不像坏人"）→ 可被绕过

我们的检测 = 行为/内容异常（"这个文件/进程在做什么异常的事"）→ 更难绕过

4.2 五层架构

4.3 L4 加密角度检测详解

这是与规则检测的本质区别：不关心"谁在做"，只关心"VM 文件是否被加密"。

明文标记消失（方案 A）

.vmx 文件是纯文本（config.version / displayName / virtualHW.version）。

勒索软件从 offset 0 开始覆盖（样本行为），覆盖后明文标记消失。

grep -qaE 'config.version|displayName|virtualHW' "$vmx_file" || alert

熵异常检测（方案 B，覆盖"保留文件头"变种）

即使勒索软件保留文件头只加密数据段，前 4KB 的不同字节值个数也会从 <120 飙升到 >240。

distinct=$(od -An -tu1 -N4096 -v "$file" | \

    awk '{for(i=1;i<=NF;i++)a[$i]=1} END{print length(a)}')

[ "$distinct" -ge 200 ] && alert

为什么这比规则匹配更强：无论加密器叫什么名字、用什么语言写、从哪个偏移开始加密，

只要将纯文本变为密文就会被检测。这是与算法无关的行为检测。

改名检测（方案 C）

find /vmfs/volumes -type f \

    \( -name '*.vmdk.??????*' -o -name '*.vmx.??????*' \) \

    | grep -v '\.lck$' | while read -r f; do alert; done

4.4 告警级别

---

5. 三版本实测评估

5.1 测试环境

5.2 版本差异矩阵（关键差异）

5.3 端到端检测验证（良性 demo 载荷）

在每台 ESXi 上投递良性 demo 载荷（busybox 假扮 e_esxi + exec.sh 投递脚本），

验证 guard 的检测覆盖率：

三台 100% 检出，无漏报。

---

6. 讨论

6.1 已知限制

6.2 攻击者可能的绕过

6.3 未来方向

1. 进程基线差分：首次采集正常进程集合 → 之后新进程即告警（与名称/路径无关）


2. pktcap-uw 网络层检测：捕获加密器与 C2 的通信


3. VM-Internal 检测：在 VM 内部部署 agent（可检测加密 I/O 到 vmdk 的写入模式）


4. vsish 路径自动化：利用 vsish -e 脚本化实现更深层内核状态检查

---

7. 结论

本文基于三起真实 ESXi 勒索事件和三个 ESXi 版本的实机验证，提出了一个五层运行时监控防御体系，核心贡献包括：

1. 系统性梳理了 ESXi 与 Linux 在进程取证方面的差异（无 /proc、ptrace 禁用、
   
   VMFS noexec），并找到了等价替代方案（ps -c + lsof + vsish）


2. 首次公开了 lsof -p <cartel> 的取证应用——文件删除后仍可获取
   
   可执行文件的路径与大小（Linux 上需依赖 /proc/<pid>/exe）


3. 构建了五层检测架构，从规则匹配到行为/内容异常检测，在三个 ESXi 版本上
   
   实现了 100% 的良性 demo 检出率


4. 产出了完整的版本兼容性矩阵，为跨版本部署提供了实证基础

所有工具以 shell 脚本实现，零外部依赖，可在三台 ESXi 版本上直接部署使用。

---

附录 A：防御自查清单

# ===== 在 ESXi Shell (root) 执行 =====



# ── 入口 ──

grep -q enabled /etc/ssh/sshd_config && echo "⚠ SSH 开着"

esxcli system settings advanced list -o /User/ExecInstalledOnly 2>/dev/null

esxcli system settings kernel list -o execInstalledOnly 2>/dev/null



# ── 可疑进程 ──

ps -c | grep -Ei 'e_esxi|exec\.sh|/var/log/|/tmp/'



# ── 可疑命令 ──

grep -Ei 'scp -t|nohup|chmod 777|ExecInstalledOnly|e_esxi' /var/log/shell.log



# ── 异常登录 ──

grep 'vpxuser' /var/log/auth.log



# ── VM 文件异常 ──

find /vmfs/volumes -name '*.vmdk.*' -o -name '*.vmx.*' 2>/dev/null | head



# ── 日志外发 ──

esxcli system syslog config get | grep -i 'Remote Host'

附录 B：IOC 清单

---

本文基于三起真实事件取证 + 三个 ESXi 版本实机验证。

所有检测工具以 shell 脚本实现，零外部依赖。