BeijingCrypt 勒索病毒解密与数据恢复

立即取消受影响服务器的公网端口映射（3389、1433、3306 等），断开其与内网其他主机的 SMB 互访，禁用被爆破的账号与所有可疑的新建管理员账号。BeijingCrypt 攻击者常在爆破成功后留下后门账号，不清理会导致恢复期间被二次加密。

取证固定内容：Windows 安全日志中的 4625/4624 记录（确认爆破来源 IP、成功时间与账号）、SQL Server 错误日志与登录审计、账号与组成员变更记录、计划任务与服务清单、安全软件被卸载的记录、勒索信 !RECOVER.txt / !HELP!.txt 原件、若干不同类型与大小的加密样本、以及尽量找到的同名未加密原件。

不要重装系统、不要格式化、不要在原盘上运行来路不明的「解密工具」。

因为 BeijingCrypt 后缀变化频繁，且与 Phobos、Makop、Crysis/Dharma 在国内常被混称，准确判定是关键的一步。

判定依据：勒索信文件名（!RECOVER.txt / !HELP!.txt 是 BeijingCrypt 的特征，明显区别于 Phobos 的 info.txt + info.hta 与 Makop 的 readme-warning.txt）、文件名改写格式、加密文件头尾标记结构、载荷样本特征、以及后缀是否属于该家族已知序列（.beijing、.360、.520、.halo、.bixi 等）。

随后做加密特征分析：抽取数据库文件、大型压缩包与普通文档，分析是否为部分加密、加密块步长与被破坏结构的位置。这一步直接决定第三步能不能给出数据库修复方案。同时核查是否存在遗留的后门账号与持久化。

先明确告知没有公开解密工具，再按路径分桶：

• 备份可用：核实独立备份机、离线介质、NAS 快照、云端版本历史、虚拟化快照的时间点与完整性，确认未被加密、未携带后门；
• 需修复：对 .mdf/.ldf/.bak/.dbf/.ibd 抽样评估，若确认为部分加密则给出表级覆盖率预估，若为全量加密则如实说明不可行；
• 旁路重建：与业务、财务部门一起清点报表导出、报送数据、上下游对账单、纸质凭证，评估可重建的时间范围；
• 未受影响主机：逐台确认可作为基线的服务器与终端；
• 确定不可恢复：明确列出。

由于这类受害者多为 IT 力量有限的中小企业，方案还应给出「先恢复哪些系统能让业务先转起来」的优先级建议。

全程在只读镜像与副本上操作，原盘保持不动，并在已清理后门的干净环境中进行。

• 备份恢复：优先恢复核心业务库与业务必需目录，恢复前先在隔离环境校验备份完整性与是否携带载荷；
• 数据库修复：若确认为部分加密，对 SQL Server 做页级损坏定位、修复系统表与分配结构后按表抽取；Oracle 侧结合数据文件头修复与归档日志应用；MySQL 侧逐个处理 .ibd 并重建字典；
• 增量补齐：用未受影响的事务日志、归档日志与上游业务流水重放；
• 文件与 NAS：按部门优先级分批恢复；
• 旁路数据回灌：把重建出的报表与单据按业务期间导回系统。

每批交付附带校验记录：记录数对账、关键单据抽样核对、应用功能验证。恢复环境确认干净后再接入生产网络。

溯源结论要写清楚：爆破来源 IP 与时间线、成功登录的账号与端口（RDP 还是数据库）、攻击者新建的账号与持久化、手工投毒覆盖了哪些主机、备份为何一起被加密。

加固清单（可验证）：

• 取消所有服务器的 3389、1433、3306 等公网映射，远程访问统一走 VPN 或零信任网关并强制多因素认证；
• 清理后门账号，administrator/sa/root 改强口令并限制来源 IP，开启账号锁定策略；
• 服务器分段，限制内网 RDP 与 SMB 的横向可达范围；
• 备份改为离线/异地 + 不可变存储，备份介质与业务服务器物理分离，定期真实演练恢复；
• 数据库不与业务系统共用主机，关闭 xp_cmdshell 等危险扩展；
• 部署 EDR 并对登录失败、账号创建、安全软件被卸载建立告警闭环。

最后出具事件报告与加固验收清单。