如果你的文件刚刚被加上一串随机后缀、桌面壁纸被换掉、每个目录里都多了一个 README.txt，现在最该做的不是找解密工具，而是先把扩散停下来、把能证明身份的东西留住。LockBit 的加密本身在数学上无法逆向，但你后面几小时的操作，会直接决定还剩多少可恢复的东西。
先处理这四件事
一、隔离，而不是急着重装。 拔掉网线、禁用对应交换机端口或关闭无线，把受影响主机从网络上摘下来。域控、文件服务器、虚拟化宿主机（ESXi/Hyper-V）和 NAS、备份服务器要优先断开——LockBit 的典型打法就是拿到域内高权限后通过组策略或 SMB 批量分发，备份和共享盘往往是同一波被打掉的。
二、关机还是保持运行，看情况判断。 如果加密进程还在跑、又没有把握把这台机器彻底从网络里摘干净，断电止损是合理的；如果已经确认隔离、加密已经结束，让机器保持原状更有利于后续取证和内存中残留信息的提取。不要一边连着网一边纠结。
三、把勒索信原件留好。 勒索信里那串 Decryption ID 是后面核验能否解密的关键凭据，别删掉、别覆盖。同时留一份加密后的样本文件（几个小文件即可）、桌面壁纸截图、弹窗截图，以及大致的发现时间。
四、不要在唯一原件上折腾。 不要格式化重装、不要用系统盘工具直接“修复”、不要在原盘上反复运行来路不明的解密程序。一些仿冒解密器会二次加密或写坏文件头，而被覆写掉的扇区不会再回来。
如果文件还在持续变多、断网后仍在加密，处理顺序和这里略有不同，可以参考断网了文件还在被加密该怎么紧急停下来。
怎么确认这是 LockBit，以及是哪一代
不同版本的外在特征差别明显：
- 早期版本：文件后缀为
.abcd或.lockbit。 - LockBit 2.0：多追加
.lock/.lockbit后缀，勒索信通常叫Restore-My-Files.txt。 - LockBit 3.0（又称 LockBit Black）：后缀变成一串由数字和字母组成的随机字符（常见 9 位），勒索信命名为
[随机后缀].README.txt或README.txt，同时会替换桌面壁纸并弹出警告窗口。 - 较新的版本还扩展了对 Linux 和 VMware ESXi 的支持，宿主机被拿下后可以批量加密
.vmdk虚拟磁盘。
需要提醒的是：光凭一个后缀或一个杀软报毒名，不足以断定家族。2022 年 LockBit 3.0 的生成器被泄露后，地下社区用它重新编译出大量非官方变种，表现和正版几乎一样，但密钥体系完全不同——这直接影响后面“能不能解密”的判断。真正可靠的判断要结合勒索信格式、加密文件头结构、ID 格式和落地样本一起看。关于后缀判断的通用方法，可以先看文件变成陌生后缀怎么判断是不是勒索病毒。
它做过的几件事，决定了你的恢复方式
LockBit 在加密之外还会做一系列破坏动作，这些正是很多人“杀完毒发现什么都没剩下”的原因：
- 删除卷影副本（VSS）、清空系统事件日志，所以 Windows 的“以前的版本”和还原点通常已经没了，日志也难以直接看出入侵路径；
- 强行关闭安全软件、数据库和相关系统服务，让 SQL Server、金蝶/用友账套这类被占用的文件也能被加密；
- 用 Mimikatz 一类工具抓取凭据，再通过域控组策略、SMB 或 PowerShell 在内网横向铺开——这意味着只处理一台机器几乎肯定不够；
- 多线程快速加密，结合 ChaCha20/AES 与 RSA-2048，加密速度极快，发现时往往已经跑完；
- 双重勒索：加密前先外带数据，再以公开数据施压。所以哪怕你有备份能完整恢复，数据外泄这条线仍要单独评估和处置。
能不能解密：说清楚真实的可能性
靠暴力破解密钥，不可行。 这一点没有回旋余地，任何声称能“破解算法”的说法都不要信。
但存在一条有条件的通道。 2024 年 2 月的国际联合执法行动（Operation Cronos）打掉了 LockBit 的部分基础设施，并缴获了一批解密密钥。欧洲刑警组织与 No More Ransom 据此发布了针对 LockBit 3.0 的解密检测工具（Decryption Checker，包含 check_decryption_id 组件），受害者可以用勒索信里的 Decryption ID 去比对，看是否命中已缴获的密钥。
关键在于它的适用范围：官方明确说明该工具只对命中已缴获密钥库的那部分受害者有效，并不能解决所有 LockBit 3.0 变种。如果你中的是泄露生成器重编译出来的仿冒版本，密钥根本不在这个库里。所以合理的预期是：值得去核验，但不要把恢复计划全押在这上面。
核验时还有两个操作前提：在与生产网络隔离的干净环境里做，用文件副本而不是唯一原件测试；先在一小批不重要的文件上验证输出是否正常可读，再考虑批量处理。如果你不确定版本判断和核验流程，可以先做家族版本识别与可恢复性判断，避免在原盘上试错。
没命中密钥，还剩哪些路径
这是大多数案例的真实处境。此时要做的是系统盘点，而不是继续找工具：
1. 备份链的实际状态。 不只看备份软件的任务记录，要确认备份介质当时是否在线、是否被同一波加密、最近一次可用的完整点在什么时候。离线磁带、拔下来的移动硬盘、异地复制、云端带版本保留的桶，都属于要单独确认的对象。
2. 未被覆盖的残留。 加密过程并不总是完整覆写，数据库文件、事务日志、临时文件、导出的报表和历史归档中，常有可提取的部分。这类提取必须在磁盘镜像上做，不能在原盘上边试边改。
3. 虚拟化平台的特殊性。 ESXi/Hyper-V 宿主机被加密后，虚拟磁盘的实际覆写比例差别很大，有的只破坏了文件头和前段数据。是否具备重组条件，要通过实际镜像取证才能判断，不能从后缀反推。
4. 业务系统的替代来源。 金蝶、用友一类账套，除了数据库本身，还可能有历史备份文件、从其他终端导出的报表、上下游往来的对账单据，可以把损失范围压缩下来。
5. 办公终端的边角副本。 邮件附件、企业网盘/同步盘的历史版本、同事本地留存的副本、打印过的电子件，零散但常常救急。
这几条路径的可行性差别很大，判断依据是磁盘覆写情况和备份状态，需要先做取证再决定投入方向。数据库、虚拟机镜像和备份提取属于不同的恢复方法，可以参考备份与数据库等恢复路径的评估方式，按自己的实际情况对号入座。
关于支付赎金
支付不是一个技术方案：你无法验证对方是否真的持有你的密钥、解密器是否能跑完、数据是否已经被转卖。舍末无勒不代付赎金、不代为谈判，处置顺序始终是先评估还能恢复什么，再决定投入方向。
需要外部介入时，把这些准备好
出现下面任一情况，靠内部 IT 单独扛通常会拖长损失：加密仍在多台机器上蔓延、域控或虚拟化宿主机被打、备份服务器同时失效、核心数据库无可用备份、怀疑数据已被外带。
联系处置方之前，先整理好这些信息，能显著缩短判断时间：
- 勒索信原文（含 Decryption ID）与几个加密样本文件；
- 受影响的主机数量、操作系统与角色（域控、数据库、虚拟化宿主、办公终端）；
- 发现时间、最后一次正常访问时间；
- 备份的类型、位置和当时是否在线；
- 已经做过的操作（是否重装、是否跑过工具、是否重启）。
注意不要把数据库文件、客户资料、生产口令或恶意样本上传到公开论坛或任意文件分享站。
正在扩散、多台机器受影响时，应急处置与横向阻断提供 7×24 小时远程与现场响应；只想先弄清楚能恢复多少、按什么顺序交付，可以看恢复评估与交付流程，先评估范围再给方案和报价。具体事件要提交材料时，走联系与资料提交页面的要求即可。
恢复之后，把入口补上
数据回来不等于事情结束。LockBit 类攻击的常见入口是暴露在公网的远程桌面、VPN 与虚拟化管理口、弱口令与复用口令、未打补丁的边界设备。恢复前后要做的是：重置所有域账号与服务账号口令（从可信设备操作）、关闭或收敛公网暴露面、给管理入口加多因素认证、把备份改成离线或不可变存储并验证可还原性，同时排查是否还有残留的持久化和外连。否则同一条路径过几周还会再来一次。
评论(0)