很多情况下能提取，但能提取多少，取决于真正装数据的那个文件——xxx-flat.vmdk（或快照卷）——被覆盖加密了多大比例，而不是取决于虚拟机现在能不能开机。虚拟机起不来、ESXi 里一眼看过去全是带陌生后缀的 .vmdk，并不等于里面的业务数据都变成了密文。
因为虚拟磁盘动辄几十 GB 到几 TB，针对虚拟化平台的勒索变种为了抢时间，普遍不做全盘加密：有的只加密文件头部几 MB，把分区表、VMFS 元数据或引导扇区打坏；有的按固定间隔做间歇加密，隔一段密一小段；还有的只处理了那个一两 KB 的文本描述符和配置文件，巨大的平坦卷根本没动。只要底层数据块还有大量明文残留，虚拟机开不了机也不影响把数据库和账套文件捞出来。
先按三种情况对号
一、只有描述符和配置文件被加密。 xxx.vmdk（约 1KB 的文本文件）、.vmx、.nvram、.log 被改名或加密，而 xxx-flat.vmdk 文件名没变、大小没变。针对 ESXi 的某些脚本化攻击就出现过这种情况。这类场景可以按厂商的标准方法重建描述符文件，让磁盘重新被识别和挂载，CISA 当年也针对这类事件发布过自动化重建恢复脚本。这是最理想的一种，但也最容易被误操作毁掉。
二、平坦卷头部被加密，或被间歇加密。 虚拟机无法启动、磁盘挂上去提示未初始化。这种情况下内部的 NTFS / EXT4 文件系统结构虽然残缺，但深层数据块（MDF/NDF、账套数据文件、邮件库、文档）往往还有很大比例是明文，可以通过只读解析和数据页提取拿回大部分关键数据。
三、平坦卷被从头到尾连续完整加密。 在没有攻击者私钥、该家族算法也没有被公开破解的前提下，想从这个文件里提取数据在密码学上不成立。此时要把精力转到别的副本上：遗留快照卷、未挂载的旧分区、复制出去的导出盘、异地冷备份。
现在立刻停手的几件事
这几类操作造成的损失，经常比病毒本身更难挽回：
- 不要开机“试试能不能进系统”。 虚拟机一启动就会重放文件系统日志、写页面文件、触发系统自我修复，这些写入会覆盖掉残留的明文碎片。
- 不要在原存储上跑修复命令，包括 VMFS 修复、重建分区表、重新初始化数据存储、让 ESXi “重新签名”卷。
- 不要格式化，也不要为了“先把平台弄好”去重装 ESXi 再把存储挂回来。
- 不要在唯一一份文件上反复试解密器或数据恢复软件。 很多工具默认就地写入。
- 克隆件和恢复出来的数据不要写回同一个数据存储，空间被占满或被覆盖就没有第二次机会。
该做的是：切断受影响主机与外界的通路（管理口、vCenter、iSCSI/NFS 存储网、备份网段），从一台干净设备上更改 ESXi、vCenter、备份系统和域管账号的口令，留好勒索信、加密样本、宿主机与备份系统日志，然后对涉及的卷做扇区级只读克隆，后续全部分析都在副本上进行。
至于是否关机：如果加密进程可能还在运行、或者攻击者仍有通道进来，优先切断网络和访问路径；具体是关虚拟机、关主机还是保持运行，要结合能否有效隔离、加密是否还在继续、是否需要保留内存与会话证据来定，没有一刀切的答案。
怎么判断自己属于哪种情况
看文件清单和大小。 列出虚拟机目录，对比描述符与平坦卷。小文件被改名、大文件名字和字节数都没变，优先按第一种情况处理。
做只读的十六进制抽样。 在克隆副本上，取头部 1–10MB、磁盘中段、尾部以及若干随机点位查看。能辨认出 MFT 记录标志、分区表签名、EXT4 超级块、数据库页头、账套文件里的可读字符串，说明那一段是明文；整片看不出任何结构、熵值均匀的，是密文。多点采样能大致估出加密比例和间隔步长，这个比例直接决定后面值不值得做提取。
找残留副本。 -delta.vmdk、-sesparse.vmdk 这类快照卷、未挂载的历史卷、以前导出的 OVA、备份服务器上的旧版本，都要先盘点再做结论。精简置备和厚置备的磁盘，残留数据的分布规律也不一样。
别只凭一个后缀或一个杀软报毒名就认定家族。 同一个后缀可能对应多个变种，加密深度和可解性差别很大；是否存在可用解密工具、适用于哪些版本，要按实际样本和密钥结构去判断，不能照搬别人案例的结论。这一步可以参考家族识别与可恢复性判断的思路。
可用的提取路径
- 重建描述符后正常挂载。 适用于第一种情况，按原磁盘的几何参数与类型重建文本描述符，再以只读方式挂载提取。
- 绕过虚拟机，直接只读解析镜像。 用底层分析工具（如 DMDE、UFS Explorer 这类支持虚拟磁盘与文件系统重组的工具）识别分区边界、重组目录树，把需要的文件导出到另一块盘上。头部被打坏但内部结构仍在时，这条路通常最有效。
- 按特征码做数据页提取。 文件系统已经无法重组时，对 SQL Server、Oracle、MySQL 的页结构或账套文件特征做扫描与雕刻，再重组为可附加的数据库。这条路出来的结果需要逐表验证。
无论走哪条路，验收标准不能是“文件导出来了、大小正常”。数据库要实际附加、跑完整性检查，账套要在业务系统里打开核对期末数和凭证连续性。部分解开又部分损坏的文件，表现上和没解开很像，这中间的区别值得单独分清，可以看解密后文件打不开该怎么判断。
什么时候需要外部介入
如果属于第一种情况，而且手上有未受影响的管理通道，自己按厂商方法重建描述符是可行的；记得先克隆再动手。
下面几种情形建议尽早让有虚拟化和数据库恢复经验的人接手，而不是继续在原环境上试：平坦卷部分加密且里面是生产数据库，需要保证业务数据的完整性和一致性；没有可用快照、备份也被一起加密；多台虚拟机、多个数据存储同时出事，或者加密还在继续扩散。前两种情况可以从备份与数据库恢复路径的评估入手，后一种属于还在进行中的事件，适合走正在扩散时的应急处置。相关判断顺序，在ESXi 虚拟机被加密又没有快照和备份文件也被加密后怎么盘点剩余副本里写得更细。
一点提醒：任何人在看过平坦卷的实际加密比例之前，就报出恢复成功率或固定工期的，都不可信。先把文件清单、抽样结果、后缀与勒索信信息整理清楚，再去谈评估，沟通成本会低很多——需要准备哪些材料，这篇清单可以直接照着列。确实需要就事件本身做评估时，再走联系与资料提交说明，不要把生产数据库、口令或可执行样本发到公开渠道。
评论(0)