没有快照、没有可用备份，ESXi 上的虚拟机已经起不来了——这种情况下最关键的一步不是去找解密工具，而是立刻停止对那块数据存储（Datastore）的所有写入。没有快照不等于数据一定没了，但只要在原卷上继续新建虚拟机、重装、格式化或反复跑修复工具，残留下来的那部分就会被真正覆盖掉。
眼下按这个顺序做三件事：隔离受影响的宿主机和存储；确认加密是否还在进行，再决定开不开机；在动任何恢复操作之前，先把原卷复制一份出来。
先隔离，再决定开不开机
隔离的范围不只是那几台虚拟机：
- 断开宿主机的业务网与管理网（交换机端口禁用或直接拔线），停掉对外暴露的管理访问和 SSH；
- 如果有 vCenter，一并检查并隔离，它常常也在失陷范围内；
- 断开与该主机相连的存储链路（iSCSI/FC 的映射先摘掉，而不是在存储上删卷）；
- 同网段的备份服务器、NAS、其他宿主机都要先确认状态，攻击者拿到管理权限后一般不会只打一台。
关于是否断电，分两种情况判断。如果加密还在进行（文件后缀还在增加、宿主机 CPU 持续满载、勒索信在不断生成），优先切断网络和存储链路来限制破坏范围，是否终止进程或断电由有经验的人现场判断，不要一边让它跑一边在控制台试操作。如果加密已经结束、文件不再变化，那就不要反复重启宿主机或反复尝试启动虚拟机：每次开机都会写入交换文件、日志和配置，而 ESXi 的部分日志默认并不持久保存，重启会连带丢掉可用于判断入口和时间线的线索。
「一律不能关机」和「赶紧重启看看」都不成立，取决于加密是否还在继续、以及你是否已经能把它隔离住。
下一步只做一件事：把原卷复制出来
在没有快照和备份的前提下，原始数据存储就是唯一一份原件，后续所有判断都应该在副本上做：
- 存储阵列支持的话，先在存储侧对该 LUN 做只读快照或克隆；
- 不具备这个条件，就把承载 VMFS 的物理磁盘/LUN 做扇区级完整克隆到容量不小于原盘的新介质；
- 克隆完成后，原件收起来不再挂载、不再写入。
这一步看着费时间，但它决定了后面能不能试错。VMFS 卷里未分配空间和块位图中的残留，往往是没有备份时最后的恢复素材，一次错误的写入就可能把它抹掉。
判断被加密的是「配置」还是「数据本体」
这是决定能恢复多少的核心判断。进入虚拟机所在目录看一下文件清单和大小：
虚拟机名.vmx——配置文件，几 KB；虚拟机名.vmdk——磁盘描述文件，只是几百字节的文本，记录容量、控制器类型和指向关系；虚拟机名-flat.vmdk（或-00000x-delta.vmdk）——真正的数据，几十到几百 GB；.vmsd、.nvram、.vmsn、.log——快照元数据、BIOS 设置与日志。
很多针对 ESXi 环境的勒索（ESXiArgs、LockBit 的 Linux 版本、Akira、Babuk 以及近年出现的新变种）为了在被发现前完成破坏，会优先摧毁这些小文件，而对体积巨大的 -flat.vmdk 只加密头部若干 MB，或者按固定百分比做间歇性加密。也就是说，虚拟机打不开，不等于盘里的数据被加密完了。
具体怎么看（在副本上做）：-flat.vmdk 的大小是否还等于原磁盘容量、是否被追加了后缀、用十六进制工具看头部和中后段是否还能识别出结构——NTFS 的卷标记、ext4 超级块、SQL Server 数据页的页头，这些都是未被覆写的信号。
两种情况，两条不同的路
情况一：数据盘基本完好，只是描述文件被毁
如果 -flat.vmdk 看起来完整，被加密的主要是 .vmx 和那个几百字节的 .vmdk 描述文件，那么可以按 VMware 官方知识库给出的标准做法：依据 flat 文件的实际大小和原来的控制器类型重新生成磁盘描述文本，再把虚拟机重新注册到清单。CISA 在 ESXiArgs 事件的恢复指引里走的也是这个思路——用未受损的 flat 文件重建配置，让虚拟机重新可用。
需要留意的条件：重建描述符解决的是「指向关系丢了」，不解决「数据被覆写了」。如果加密恰好覆盖了分区表或文件系统元数据区域，重建后虚拟机能注册、却依然起不来，这时就要转到第二条路，而不是继续在原件上试。另外，如果原来有快照链（delta 盘），描述文件缺失时的重建要考虑整条链的关系，比单盘复杂，不要随手把 delta 盘删掉「图个干净」。
情况二：头部被毁或间歇加密，就不要再追求原样开机
这种情况下目标要换：不是把虚拟机恢复成能开机的状态，而是把里面的数据拿出来。做法是在 VMFS 卷的镜像上定位该虚拟磁盘的起止偏移，导出裸磁盘镜像，再按文件系统解析，或者直接按数据库结构去抓。
数据库文件在这种场景下反而相对有利：SQL Server 的 mdf/ldf、Oracle 的 dbf、MySQL 的 ibd 体积大，间歇加密下通常还剩大量完整数据页，可以做页级提取和重组。但结果要有合理预期——常见产出是「部分表可用」「恢复到某个不完整的状态」，需要业务侧逐项验收，比如账套能不能打开、关键期间的凭证和余额对不对得上。这条路的产出没法在动手前给出准确比例，所以先评估再决定投入，而不是先付钱再看结果。
不要只看后缀就认定家族，但也别跳过识别
文件后缀、勒索信名字、杀软报出的名称都可能撞车，而不同家族的底层破坏逻辑差距很大：有的只是脚本式地毁掉配置，有的会对数据块做强加密并大面积覆写。少数变种因为实现缺陷或历史密钥泄露存在公开或专用的解密方案，但适用范围严格限定在特定版本，拿错版本的工具去跑，反而会把还能用的文件写坏。
识别需要留的材料：勒索信原文、文件后缀与改名规则、两三个体积较小的加密样本（不要动唯一原件）、ESXi 的日志与账号登录痕迹、大致的时间点。这些东西凑齐了，家族与可恢复性的判断才有依据，而不是靠猜。可恢复性怎么判断、要看哪些条件，可以参考家族识别与可恢复性判断的说明。
没有快照，不等于没有副本
在上手复杂的底层提取之前，先把所有可能的副本盘一遍，这经常比解密更快拿到可用数据：
- 备份软件的任务历史：即使最近的任务失败，更早的完整备份点可能还在，去看备份服务器本身而不只是任务状态；
- 数据库的从库、日志备份、定期导出的
.bak或账套备份文件； - 应用层导出的报表、对账单、凭证打印件，以及员工本机和邮件附件里的留存；
- NAS、共享盘上的手工拷贝（注意这些同样可能被加密，要确认后再用）；
- 其他宿主机上的旧克隆、测试环境、离职交接盘、云盘。
找到的候选副本先只读校验再使用，不要直接挂回还没清理干净的原环境。备份、数据库和其他恢复路径分别适用什么条件，可以看备份与数据库恢复路径的整理。
这些操作会把剩下的机会一起抹掉
- 在原数据存储上新建虚拟机、扩容、重建 VMFS 或格式化；
- 把 ESXi 重装回原来的磁盘；
- 在唯一原件上反复运行第三方修复或解密工具；
- 删掉「看起来没用」的
.vmsd、.nvram、日志和加密后的小文件； - 把勒索信和加密样本清掉——它们是识别家族的主要依据。
已经动过手也别慌，先停下来记清楚做了什么、写过哪块盘，这直接影响后面的判断。关于重装和误操作之后还剩多少余地，这篇讲重装系统后的恢复条件和没有免费解密工具时还剩哪些路可以对照看。
恢复之前，先把入口关掉
ESXi 被打通常不是虚拟机里中毒，而是管理口暴露在公网、SSH 开着、口令被撞或复用、补丁长期没打、备份服务器和宿主机用同一套凭据。这些不处理就直接恢复，恢复出来的虚拟机大概率会被再加密一次。所以恢复和加固要并行安排：改口令要从一台干净设备上做，管理网收回内网，备份凭据与生产凭据分开。
什么时候需要外部介入，要准备什么
出现下面任一情况，建议先做专业评估再动手：多台宿主机或 vCenter 一起失陷；存储侧没有做只读克隆的能力；-flat.vmdk 需要做偏移定位和页级提取；业务对恢复时间有硬性要求。
联系时准备这些：虚拟机目录的文件列表与大小截图、勒索信、少量小体积加密样本、存储架构说明（VMFS 版本、是本地盘还是 iSCSI/FC/vSAN/NFS）、已经做过的操作清单。注意不要把生产口令、数据库原件、客户资料上传到公开论坛或任意文件分享站。
舍末无勒做的是事件应急、家族识别、可恢复性评估与恢复，先评估能恢复的范围再给处置方案和报价，不支付赎金、不代为谈判——需要提交具体事件信息时走这个资料提交入口。在把事情交出去之前，怎么判断对方的方案靠不靠谱也值得先看一眼：能把条件和不确定性讲清楚的方案，比承诺「百分百恢复」的更可信。
评论(0)