作者 ：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 映射的路径与大小： $ 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 五层架构 层 检测内容 数据源 告警前缀 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 空 空 空 execInstall

  • 情报分类：服务器与云资源
  • 分类依据：内容涉及服务器、云资源或网络线路
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/10/10 14:00:02