ESXi / Hyper-V 虚拟化平台被勒索病毒加密

虚拟化层是勒索攻击的最高价值目标：一台 ESXi 主机上往往跑着域控、ERP 应用、数据库、文件服务器和备份代理，攻破一个管理面就等于拿下整个数据中心。这也是近年主流 RaaS 组织普遍开发 Linux / ESXi 版加密器的原因。据公开报道，Akira 的 Linux 加密器项目名为 Esxi_Build_Esxi6，后续版本会用 esxcli 与 vim-cmd 先优雅关闭虚拟机再加密磁盘；Qilin 的 Linux 版本明确针对 ESXi 与 FreeBSD，重点加密虚拟机并删除快照，甚至提供 --no-snap-rm、--no-vm-kill 之类的命令行开关来控制这些行为。

为什么加密器要先关机？因为运行中的虚拟机会锁定 vmdk 文件，关机是为了解锁文件以便完整加密。这个行为对我们有两个含义：一是关机时间点往往能精确标定攻击时刻；二是被强制关机的虚拟机内部可能存在未落盘的数据库事务，恢复后需要做一致性检查。

风险与误操作：

• 业务全停 + 备份同时失效。 备份服务器常常也是虚拟机，或者备份仓库以 NFS / iSCSI 挂载在被加密的数据存储上，一并沦陷。
• 重装 ESXi 或重新初始化数据存储。 这是本场景里最致命的错误，等于主动格式化。哪怕界面显示数据存储「不可用」，底层数据也可能完好。
• 在原数据存储上创建新虚拟机、新建数据存储、或做 VMFS 重新签名尝试。 有覆盖元数据的风险。
• 反复重启 ESXi 主机。 可能触发自动修复与写入，也会丢掉内存中的痕迹。
• 直接从被加密的备份恢复并覆盖原卷。
• 运行攻击者提供的 ESXi 解密器脚本。 在超管权限下运行未知脚本，风险不言自明。

我们不建议支付赎金，也不提供代谈判服务。

• 管理面与公网彻底隔离。 ESXi、vCenter、Hyper-V 管理端口、iDRAC / iLO 一律不做端口映射，放入独立管理 VLAN，只允许堡垒机访问。
• 保持受支持版本并及时打补丁。 历史上有大规模 ESXi 勒索事件正是利用长期未修补的老版本服务漏洞（如 OpenSLP 相关漏洞）批量入侵；关闭不需要的 SLP、CIM 等服务。
• 启用锁定模式，默认关闭 SSH 与 ESXi Shell。 需要时临时开启并留审计；定期检查 authorized_keys 与本地账号。
• 虚拟化账号与 Windows 域解耦。 vCenter 不与生产域共用管理员凭据，虚拟化管理员使用独立强口令与多因素认证，避免域控沦陷直接带走虚拟化平台。
• 备份仓库不能和被保护数据同命运。 备份服务器独立于被保护域与被保护存储，启用不可变备份 / 对象锁，保留离线副本，备份网络与生产网络分离。
• 保护备份软件自身。 Veeam 等备份平台要及时打补丁并限制管理端口访问；公开报告显示其凭据泄露类漏洞曾被勒索组织用于横向移动。
• 快照不能当备份，但要有。 存储阵列快照 / 复制放在虚拟化层之外，攻击者从 ESXi 侧难以删除，是有效的第二道防线。
• 监控虚拟化层异常行为。 对批量虚拟机关机、esxcli 异常调用、快照批量删除、ESXi shell 登录设置告警——这些是加密动作的前置信号，往往还有十几分钟的处置窗口。