先给结论：有相当一部分 mdf 是能恢复出可用业务数据的，但恢复的不一定是“原库直接挂起来”，而可能是“把表里的记录提取出来重建成新库”。 决定能恢复多少的，主要是三件事——加密实际覆盖了文件的多大范围、还有没有其他副本、以及发现之后有没有被二次破坏。第三条是唯一完全掌握在你手里的变量，所以它排在最前面。
现在最优先做的三件事
1. 先让文件停止被继续改写。 如果加密进程还在跑，任何“先研究一下”的时间都在损失数据。把这台服务器从网络断开（拔网线或在虚拟化层断开网卡），确认加密是否仍在推进。加密确实还在继续、又无法定位并终止进程时，强制断电的代价通常小于让它把剩余文件写完；但如果加密已经结束、机器上还需要保留内存取证线索或有其他在跑的业务，就不要急着重启。
2. 把原始文件做一份冷副本，之后所有操作都在副本上做。 目标文件包括：被加密的 .mdf、.ndf、.ldf（事务日志经常被忽略，但它是时点恢复和数据补全的重要来源）、目录里残留的 .bak/.trn，以及勒索信本身。复制前先停掉 SQL Server 服务，否则文件被句柄独占，复制出来的可能是不完整快照。副本落到一块干净的外部盘上，最好整卷做一份镜像。做不到镜像，至少保证原盘从此只读、不再挂载运行。
3. 不要在原件上尝试修复。 下面这几类操作已经毁掉过很多本来可提取的库：反复启动 SQL 服务让它自动尝试恢复、强行附加置疑库、执行 DBCC CHECKDB (..., REPAIR_ALLOW_DATA_LOSS)、在原盘上运行来路不明的“一键解密工具”、对原盘做碎片整理或杀软全盘清理。它们的共同后果是覆盖掉未加密的数据页、清空日志，把“还能提取七成”变成“什么都没有了”。
为什么大数据库反而更有机会
mdf 动辄几十 GB 到几 TB。很多勒索家族出于速度和规避检测的考虑，对超大文件不做完整加密，而是采用部分加密或间隙加密：只覆盖文件头部若干 MB，或者按固定间隔加密一段、跳过一段。结果就是文件打不开、带上了陌生后缀，但文件主体里仍然残留大量明文数据页。
这一点之所以能被利用，是因为 SQL Server 的物理存储结构很规整：以 8KB 的数据页为基本单位，64KB 的盘区为分配单位，每页都有固定格式的页头和记录槽位数组。即使第 0 页的文件头和系统元数据表被打坏、数据库无法正常附加，只要中后段的数据页没被强算法覆盖，专业工具和工程师就可以直接解析字节流，按页头校验和槽位偏移把各业务表的记录雕刻出来、重建列结构，生成一个新库。
还有一个常被忽略的变量：加密时 SQL Server 服务是否还在运行。 成熟的勒索程序会先尝试 net stop 或 taskkill 释放文件锁，但这一步并不总是成功。服务没停干净、加密被中途打断的情况下，往往会留下未被覆盖的脏页、临时文件和事务日志碎片，提取成功率明显更高。
怎么初步判断属于哪种情况
这一步只做只读观察，在副本上进行，不要写回任何内容：
- 看文件大小。 加密后体积与原来基本一致（或只多出几百字节的尾部标记），说明大概率是原地覆盖式加密，属于可以进一步分析的情况；体积明显变小或只剩几 KB，通常意味着原文件已被销毁或只剩占位。
- 用十六进制工具看头部和中后段。 头部一片高熵随机数据、但往每隔几百 MB 的位置抽查时能看到规律的页头结构、能读到可辨认的表名和中文字段内容，就是典型的间隙加密或仅头部破坏。反过来，从头到尾抽查都是均匀随机数据，基本可以判断是端到端的完整强加密。
- 看 ldf 的状态。 日志文件有时因为体积小反而被完整加密，有时又因为在服务占用中被跳过。ldf 若有残留，会直接影响能否做尾日志恢复、能补回多少最后时段的交易。
如果你不熟悉十六进制查看，不必勉强。把“文件大小是否一致、后缀名、勒索信文本、有没有 bak”这几项信息记录下来就够用了，判断家族和加密方式可以交给做家族识别与可恢复性评估的人来看，避免自己在副本之外的地方误操作。
四条恢复路径，按顺序排
第一条：备份还原。 优先级最高，也最容易被低估。很多人说“备份也被加密了”，但值得逐项确认的还有：异地或离线的 bak、磁带、云端对象存储的版本历史、其他服务器上的同步副本、开发测试库、以及财务/业务系统自己导出的月结存档。哪怕只有一个几天前的完整备份，配上残留未加密的 ldf 做尾日志恢复，结果也可能远好于从加密文件里提取。关于备份全丢时还能盘点什么，可以参考服务器被加密又没有备份时的止损与路径判断。
第二条：匹配解密器。 只有当勒索家族确实存在公开解密工具、或其加解密实现存在已知缺陷时才成立。不要用后缀名或杀软报出的名字单独下结论——同一个后缀被多个家族和变种使用过，名字对上不代表密钥对得上。判断方法在只有勒索信时怎么判断文件能不能解密里讲得更细。解密器无论来源多正规，也一定在副本上先拿一个小文件试，不要整库直接跑。
第三条：数据页级提取与重构。 就是前面说的，绕开损坏的文件头和元数据，从未加密的 8KB 页里把业务表记录雕刻出来重建。这条路径的产出不是“原库恢复如初”，而是“主要业务表的数据回来了”：索引、存储过程、触发器、部分自增连续性可能需要重建，个别表因为恰好落在加密区间而缺失。能提取多少，在没有实际分析文件之前谁都给不出准确比例，任何上来就承诺百分比的说法都不必采信。
第四条：磁盘未分配空间里的历史页。 数据库自动增长、索引重建、快照删除都会在磁盘上遗留孤立的历史数据页。它们不成体系，但在主体文件被完整加密时，有时能捞回部分关键表的旧版本记录。前提是这块盘此后没有被大量写入——这也是为什么原盘必须尽快停用。
什么时候要接受“恢复不了”： 如果 mdf 从头到尾都是完整的强对称加密（AES/ChaCha20 一类），私钥不在手里，又没有任何备份和磁盘碎片，那么在数学上就没有绕过去的办法。这种情况下继续投入时间尝试“破解”没有意义，重心应该转到重建数据（从上游单据、对账单、下游系统反查）和防止再次发生。
别忘了这台机器是怎么被打进来的
数据恢复和入侵处置是两件事。数据库被加密，说明攻击者此前已经拿到了服务器权限——常见入口是暴露在公网的 1433 端口加弱口令、远程桌面被爆破、或者从一台被远控的办公电脑横向移动过来。恢复出来的库如果放回一台没有清理干净的服务器，很可能几天后被加密第二次。 在恢复之前或同时，至少要处理：改掉所有 sa 及业务账号口令（从一台确认干净的设备上操作）、关闭不必要的公网映射、检查计划任务与自启动项、排查同网段其他机器有没有被同时加密。
如果办公电脑那边还伴随着账号异常登录、聊天工具被冒用、财务付款流程被插队等情况，那多半还有远控木马这条独立的线，处置逻辑和文件加密完全不同，不能靠一次杀毒就认定干净。
恢复完不等于可以上线
从加密文件里提取重建出来的库，必须核对过才能交给业务用。至少要跑一遍完整性检查、对关键表做行数与主键连续性比对、抽查最后一个营业日的单据、再让财务用期初期末余额和对账单核一遍。核对顺序可以参照SQL Server 恢复后的五层核对方法，不要在没对过账的情况下直接开放录入，否则新旧数据混在一起，后面更难分清。
需要外部介入时，带上这些信息
如果加密范围判断不清、没有可用备份、或者业务停摆压力很大，把判断交给能做实际文件分析的人会更稳妥。沟通时准备好：勒索信全文与联系方式、被加密文件的完整后缀名、mdf/ldf 的原始大小与当前大小、数据库版本、最近一次可用备份的时间和位置、以及事发前后服务器上的异常现象。这些信息足以做初步可恢复性判断，不需要、也不应该把数据库文件、客户资料或生产口令上传到任何公开平台或不明网盘。
判断偏向“靠残留数据页提取”时，走数据库与备份恢复路径的评估；如果同一网段里还有多台机器在被加密、或者不确定攻击者是否还在内网，那优先级要放在应急处置上，先把扩散停住，再谈恢复。具体事件可以通过联系页面说明情况，评估范围和处置顺序会在给出方案时一并说明。
评论(0)