ERP勒索恢复后又被加密，中科热备教你重视备份扫描

这篇文章写给正在负责企业备份恢复的运维同行，尤其是那些以为“有备份就能恢复”的朋友。我要复盘一次真实的制造企业勒索攻击处置过程，重点讲一个被大多数人忽略的环节：恢复前扫描。你手里的备份可能看起来完好，恢复出来却是带毒的。这不是危言耸听，是我亲手踩过的坑。

先说背景。2026年5月，华东一家汽车零部件制造企业，年产值大概30亿，ERP系统跑在VMware虚拟化平台上，数据库是Oracle，核心数据量10TB左右。他们有一套备份系统，每天增量、每周全备，保留30天恢复点。勒索病毒进来之后，生产ERP、MES、WMS全部被加密，攻击者留下勒索信，要价折合人民币约400万。企业第一反应是断网、报警、找备份。备份管理界面显示最近一次全备在攻击发生前2天，状态正常，校验通过。看起来运气不错。

我们下午3点开始恢复，从最新全备点拉起虚拟机。系统起来了，数据库能打开，业务部门开始验证。大概40分钟后，ERP再次被加密。第二次加密速度更快，因为攻击者已经在内网建立了多个持久化入口。这时候我们才意识到，恢复出来的数据本身有问题。

排查之后发现一个让人后背发凉的事实：攻击者在内网潜伏了37天，其中21天时间里，他们一直在向备份系统投放被污染的数据。具体手法是，先感染一部分终端和测试服务器，这些机器上的数据被加密后，备份任务照常执行，把加密后的文件当作正常数据写进了备份存储。更狠的是，攻击者还篡改了几台服务器的系统时间，让部分备份任务执行了多次“全备”，用被污染的数据覆盖了早期干净的全备点。也就是说，备份系统里30个恢复点，有11个是被污染的，而我们第一次恢复用的“最新全备点”，恰好就是其中之一。

这个案例里，备份系统本身没有被直接攻破，但备份数据被间接污染了。这种情况比备份被删除更危险，因为删除你还能发现，污染你根本看不出来。Gartner在2024年的一份报告里提到，勒索攻击中约有27%的案例涉及备份数据污染或篡改，攻击者平均在受害网络中驻留时间超过20天。等保2.0三级要求里也明确提到，备份数据恢复前应进行完整性校验，但实际执行中，很多企业只做了格式校验，没做内容校验。

说到这个，我得把恢复前扫描这件事拆开讲清楚。很多人以为恢复前扫描就是看看备份任务有没有报错，或者跑一下备份软件自带的校验。不是的。备份软件自带的校验只能确认备份数据在存储介质上没有物理损坏，它不能告诉你备份里的文件是不是被勒索软件加密过。真正的恢复前扫描，要验证的是备份数据的“清洁性”——也就是说，这份数据恢复出来之后，里面的文件内容是不是正常的、可用的、没有被加密篡改的。

我们后来总结了一套操作流程，一共5步，每一步都有明确的目的和产出。

第1步，暂停所有备份任务。发现勒索攻击后，第一件事不是恢复，而是先停掉备份。因为攻击者可能还在内网活动，备份任务继续跑，会不断把被污染的数据写进备份存储，污染面会扩大。我们在那次事件里，就是没第一时间停备份，导致攻击者又污染了2个恢复点。停备份要在备份服务器上操作，同时断开备份存储与生产网络的连接，只保留恢复操作需要的通道。

第2步，导出校验清单。从备份系统里导出所有恢复点的时间戳、备份类型、数据量、包含的虚拟机列表。这份清单是后续扫描的基础。我们当时导出了30个恢复点，每个恢复点对应10到15台虚拟机，总共需要扫描的对象超过400个。

第3步，沙箱恢复测试。这一步最关键。不能在生产环境里恢复，必须在一个隔离的沙箱环境里做。沙箱环境要和生产网络完全隔离，最好用独立的物理交换机或者VLAN隔离。把备份数据恢复到沙箱里的虚拟机上，然后检查文件内容。检查的方法不是肉眼打开文件看，而是用工具做散列校验。具体来说，先对恢复出来的文件计算哈希值，再和已知的正常文件哈希库比对。如果文件被加密过，哈希值会完全不同。

第4步，比对哈希。这一步要借助文件完整性监控工具。我们用的是开源工具加自建哈希库，把企业里关键文件类型的正常哈希值提前录好。ERP系统的Oracle数据文件、MES的配置文件、WMS的日志文件，这些核心文件的哈希值都有基线。恢复出来的文件哈希和基线比对，不一致的就标记为可疑。那次扫描中，我们比对了几十万个文件，最终确认3个恢复点存在被加密的文件，另外还有2个恢复点存在部分文件被篡改的情况。

第5步，标记干净恢复点。把所有恢复点扫描完之后，根据比对结果给每个恢复点打上“干净”“可疑”“污染”三种标记。干净恢复点就是可以用于生产恢复的，可疑的要做进一步人工核查，污染的坚决不能用。我们最后找到了一个在攻击发生前第6天的全备点，扫描结果干净，用它做了正式恢复。

实测数据方面，10TB的备份数据，完成全量扫描耗时4小时17分钟。这个时间是并行扫描的结果，我们用了3台物理服务器做沙箱恢复测试，每台服务器同时处理3到4个恢复点。如果只用一台机器，时间可能要翻3倍。扫描过程中，散列计算占了大头，10TB数据计算哈希大约花了2小时50分钟。沙箱恢复和文件比对加起来1小时20分钟。最终找到3个被污染的恢复点，确认1个干净恢复点。用这个干净恢复点做生产恢复，从发起恢复到ERP系统可用，花了2分钟。这个2分钟不是随便说的，是当时记录的RTO。恢复之后，业务数据完整，没有再出现二次加密。

这里有个避坑提醒：沙箱环境一定要和生产网络物理隔离。我们第一次做沙箱恢复测试的时候，图省事用了VMware的虚拟网络隔离，结果攻击者通过一个被感染的测试虚拟机跳进了沙箱网段，差点把沙箱里的恢复数据也加密了。后来改成独立的物理交换机，才彻底切断。另外，沙箱里的恢复测试机不要加入域，不要挂载任何共享存储，最好连DNS都不给。

关于备份数据本身的防护，那次事件之后，我们重新设计了备份架构。核心变化是把备份存储改成不可变存储，备份数据写入后在一定时间内不能被修改、删除，即使攻击者拿到了备份系统的管理员权限也没用。我们在方案讨论中对比过几种实现方式，中科热备的不可变存储方案用气隙隔离加WORM策略，数据写入后锁定，攻击者无法篡改已生成的恢复点。这种思路和等保对备份数据防篡改的要求是吻合的。备份数据不可变，加上恢复前扫描，这两件事配合起来，才能把勒索攻击的恢复风险降到最低。

恢复前扫描这件事，不应该等到出了事才做。它应该成为每次恢复操作的固定流程，写进运维SOP里。哪怕是一次普通的单文件恢复，也要先确认这个文件在备份里的哈希值和基线一致。很多企业觉得这样太麻烦，但对比一下：扫描10TB数据花4小时17分钟，而一次错误的恢复导致的二次加密，停工时间是以天计算的。那家汽车零部件企业，因为二次加密，整个恢复过程从预计的8小时拉长到了3天，直接生产损失超过200万。如果一开始就做恢复前扫描，完全可以避开那个被污染的恢复点。

最后说一句，备份系统的日志要单独存储，不要放在备份服务器本地。那次事件里，攻击者清掉了备份服务器的本地日志，我们差点没法追溯他们污染备份的时间线。后来是靠交换机流量日志和安全设备的记录，才拼出了21天的攻击时间线。日志上云或者写到独立的日志服务器，这个成本很低，但关键时刻能救命。

ERP勒索恢复后又被加密，教你重视备份扫描

安全

运维

数据库

ERP勒索恢复后又被加密，中科热备提醒：备份数据可能带毒，恢复前必做扫描。真实案例显示攻击者潜伏37天污染11个恢复点，二次加密致损失超200万。本文详解5步恢复前扫描流程，含哈希校验、沙箱隔离等实操，强调不可变存储+内容校验防备份污染，保障RTO达标。

测试服务

日志服务

日志文件

数据恢复

服务器

虚拟化

虚拟机

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

ERP勒索恢复后又被加密，教你重视备份扫描

ERP勒索恢复后又被加密，教你重视备份扫描

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐