tzhtdx2026-10-10

6259

作者：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）：

特征 |
分析结果 |

加密方案 |
X25519 ECDH + SHA-512 KDF + 自定义 S-box 流密码 |

Nonce/Counter |
固定为 0（潜在弱点：密钥流可能重复） |

部分加密 |
前 384MB 始终加密；≥768MB 时另加密中段 384MB |

文件尾 |
追加 32 字节临时公钥（供攻击者解密） |

目录遍历 |
opendir/readdir，按扩展名过滤（13 种虚拟化文件类型） |

自毁 |
执行后立即删除自身二进制 |

C2 |
Tor 网络聊天 + prnt.sc 截图外传 |

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

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

三案中攻击者统一执行：```
esxcli system settings advanced set -o /User/execInstalledOnly -i 0
```但该命令的实际效果因版本而异（实测确认）：

ESXi 版本 |
命令结果 |
原因 |
攻击影响 |

6.7 |
“选项不存在” |
ExecInstalledOnly 为 VMKernel 设置 |
无影响，默认已允许执行 |

7.0.3 |
“选项不存在” |
同上 |
无影响 |

8.0.3 |
rc=0，成功关闭 |
高级设置 /User/ExecInstalledOnly |
关闭后投递的 ELF 才能执行 |

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

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

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

3.1 进程信息获取

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

Linux 方法 |
ESXi 等价 |
说明 |

/proc/<pid>/cmdline |
ps -c 第 4 列 |
完整命令行 |

/proc/<pid>/exe |
lsof -p <cartel> MMAP 条目 |
文件删除后仍显示路径/大小 |

/proc/<pid>/maps |
lsof -p <cartel> 或 vsish -e ls .../mem/mmaps/ |
内存映射区域 |

/proc/<pid>/fd/ |
vsish -e ls .../fd/fds/ |
打开文件列表 |

gcore <pid> |
^-^ 无 |
无法直接 gcore |

kill -ABRT → core |
^-^ 需通过 vsish 开启（详见 §4） |
可行但有条件 |

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

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

以及该文件的映射大小（可推断原始二进制大小）。
局限：无法从 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 五层架构

层 |
检测内容 |
数据源 |
告警前缀 |

L1 进程 |
ps -c 命令行匹配（含解释器/落地区/已知 IoC） |
ps -c |
SUSP_PROC |

|
lsof 取 MMAP 映射与打开文件 |
lsof -p <cartel> |
ENC_TARGET |

L2 命令 |
shell.log 增量匹配（投递/赋权/关防护/已知 IoC） |
shell.log |
SHELLLOG |

|
命中后立即扫盘抓文件（反应式抓取） |
— |
REACT_CAPTURE |

L3 落盘 |
投放物/勒索信文件匹配 + 哈希存证 |
find 目录轮询 |
FILE_DROP |

L3b 行为 |
.vmdk/.vmx 数量做差（加密风暴） |
find /vmfs/volumes |
ENC_SPIKE |

L4 加密 |
VM 文件明文标记消失（.vmx 纯文本变密文） |
文件内容检查 |
ENC_SUSPECT_TXT |

|
VM 文件熵异常（>200 distinct bytes/4KB） |
od + awk |
ENC_SUSPECT_DESC |

|
VM 文件被加未知后缀（≥6 位） |
find 文件名匹配 |
ENC_RENAMED |

主动响应 |
高置信进程取证后 kill（默认关闭） |
kill -9 |
KILLED |

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 告警级别

级别 |
告警 |
说明 |

P0 |
ENC_SUSPECT_* / ENC_RENAMED |
VM 文件正在被加密 |

P0 |
SUSP_PROC / ENC_TARGET |
可疑进程运行中 |

P0 |
ExecInstalledOnly 被置 0 |
防护被关闭 |

P0 |
vpxuser SSH 登录 |
非正常账号登录 |

P1 |
FILE_DROP / REACT_CAPTURE |
投放物落盘（已存证） |

P1 |
SHELLLOG |
可疑命令 |

5. 三版本实测评估

5.1 测试环境

主机 |
ESXi 版本 |
Build |
架构 |

esxi6.7 |
6.7.0 |
15160138 |
双网卡（vmk0=192.168.100.x, vmk1=10.21.21.x） |

esxi7 |
7.0.3 |
18644231 |
双网卡 |

esxi8 |
8.0.3 |
24677879 |
单网卡 |

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

差异项 |
6.7 |
7.0.3 |
8.0.3 |

/proc |
^-^ 空 |
^-^ 空 |
^-^ 空 |

execInstalledOnly 位置 |
VMKernel |
VMKernel |
高级设置（默认=1） |

ExecInstalledOnly 对投递 ELF |
允许执行 |
允许执行 |
拦截（Operation not permitted） |

审计命名空间 |
auditrecords |
auditrecords |
auditrecords |

审计 local set |
可用 |
静默失败 |
可用 |

审计 livecore |
未验证 |
静默失败 |
可用 |

kill -ABRT → core dump |
|
|
|

vmkdump_extract 可用 |
有 |
有 |
有 |

viewAudit / auditLogReader |
auditLogReader |
viewAudit |
viewAudit |

tr 命令 |
|
|
|

shell.log |
有 |
初装可能无 |
有 |

python |
3.5 |
3.8 |
3.11 |

lsof |
|
|
|

VMFS noexec |
|
|
|

local.sh 尾部 exit 0 |
是 |
是 |
是 |

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

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

验证 guard 的检测覆盖率：

检测层 |
esxi6.7 |
esxi7 |
esxi8 |

L1 SUSP_PROC（exec.sh 进程） |
|
|
|

L1 SUSP_PROC（e_esxi 进程） |
|
|
|

L1 ENC_TARGET（打开 .vmdk） |
|
|
|

L2 SHELLLOG（可疑命令） |
|
|
|

L3 FILE_DROP（载荷落盘存证） |
|
|
|

证据 ELF core（vmkdump_extract） |
^-^ 16.8MB |
^-^ 16.8MB |
^-^ 9.2MB |

三台 100% 检出，无漏报。

6. 讨论

6.1 已知限制

限制 |
说明 |
缓解措施 |

无法实时读进程内存 |
ESXi 无 /proc，ptrace 禁用 |
轮询间隔最小化 + 文件在盘时立即抓取 |

轮询盲区 |
进程存活 < INTERVAL 则可能漏检 |
降频有 CPU 代价，需平衡 |

加密算法无关性不完美 |
极慢速、保留结构的变体可能滞后 |
L4 熵/标记检测已覆盖大多数场景 |

7.0.3 livecore 静默失败 |
VMware 内部行为 |
用 kill -ABRT 替代 |

6.2 攻击者可能的绕过

绕过手段 |
我们的对策 |

Python 脚本替代 ELF（绕 ExecInstalledOnly） |
L1 仍能检测 python + /tmp/ 组合 |

自定义加密不覆盖文件头 |
L4 熵检测覆盖 |

减慢加密速度（低频、小批量） |
增加 INTERVAL 灵敏度 + 收集端阈值告警 |

使用 ExecInstalledOnly=0 后再执行 |
L2 命令层 P0 告警此操作 |

禁用 syslog 外发 |
心跳看护：主机静默即告警 |

6.3 未来方向

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

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

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

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

7. 结论

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

- 系统性梳理了 ESXi 与 Linux 在进程取证方面的差异（无 /proc、ptrace 禁用、

VMFS noexec），并找到了等价替代方案（ps -c + lsof + vsish）

- 首次公开了 lsof -p <cartel> 的取证应用——文件删除后仍可获取

可执行文件的路径与大小（Linux 上需依赖 /proc/<pid>/exe）

- 构建了五层检测架构，从规则匹配到行为/内容异常检测，在三个 ESXi 版本上

实现了 100% 的良性 demo 检出率

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

所有工具以 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 清单

类型 |
IoC |
备注 |

文件 |
e_esxi, exec.sh, enc_wip* |
三案通用载荷命名 |

文件 |
*.Q1ZVE0rRT, *.vLwoQ0baL, .__NoNoNoYYY |
加密后缀 |

文件 |
How To Restore Your Files.txt, !!!!!_INSTRUCTION_!!!!!.txt |
勒索信 |

命令 |
esxcli ... ExecInstalledOnly ... -i 0 |
关闭执行限制 |

命令 |
scp -t /var/log/ |
投递路径 |

进程 |
cmdline 含 /var/log/e_esxi -u |
运行中的加密器 |

网络 |
govmomi/0.47.0 (User-Agent) |
入口工具 |

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

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

主楼

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