195TB训练数据被拖走前，攻击者已在中科热备备份域潜伏47天

这篇文章写给安全响应团队和运维工程师。你们可能正在查生产环境的 Webshell、内存马、异常进程，但有一个地方多数人根本没想到要查——备份域。我最近复盘了一个真实案例：某AI公司195TB训练数据被外部拖走，攻击者在备份域潜伏了47天。生产环境查了三轮没找到入口，最后发现是备份系统里的一个旧账号被利用，备份集本身被污染，恢复的时候把后门一起带了回来。

为什么备份域是应急响应的盲区

先给个定义。备份域不只是备份服务器，它包含了备份管理节点、介质服务器、存储阵列、备份代理、以及所有能访问备份集的账号和网络通道。应急响应的时候，团队习惯性把注意力放在生产网段，查Web日志、查主机进程、查出口流量。备份域通常被当成“干净的地方”，因为平时没人动它。

实际上不是。我在一次金融客户的项目里做过统计，他们的备份域有23个账号能登录，其中7个账号超过180天没改过密码。生产环境的账号治理做得再严，备份域的账号经常被漏掉。Gartner在2024年的一份报告里提到，到2028年会有75%的企业把备份系统作为恢复流程中的独立信任域来管理，但2025年的现状是，大多数备份域连基本的访问审计都没开。

那个AI公司的案例里，攻击者拿到的是一个备份代理服务器的本地管理员权限。这台机器既不属于生产网段，也不在核心资产清单里，但它能直接读取训练数据的备份流。攻击者没急着动手，先用这个权限在备份管理节点上创建了一个计划任务，每天把当天新增的备份集做一次复制，传到外部一台服务器。47天后，累计传走了195TB。

下面这套流程是我在三个真实应急响应项目里反复调整过的，每一步都有具体命令。你不需要一次全做完，但如果有备份域被入侵的怀疑，按这个顺序来。

先断掉所有非必要的备份域账号，包括备份管理控制台、备份代理、存储阵列的管理口。只保留一个应急专用的本地账号，并且这个账号只能在带外管理网络登录。

Linux备份服务器上可以这样操作：

# 锁定除root外的所有可登录账号

for user in $(awk -F: '$3>=1000 && $7!="/sbin/nologin" {print $1}' /etc/passwd); do

踢掉异常会话，TTY换成实际的终端号

Windows备份管理节点上，用PowerShell禁用账号：

# 列出最近7天有登录行为的账号

Get-LocalUser | Where-Object {$_.LastLogon -gt (Get-Date).AddDays(-7)} | Select-Object Name, LastLogon

冻结这一步有个避坑点：不要直接关机备份服务器。攻击者如果已经植入驻留程序，关机可能会触发数据擦除或加密逻辑。先把网络访问切断，再处理账号。

步骤二：对备份集做散列校验比对

备份集是否被篡改，不能只看文件时间戳。攻击者会故意把时间改回去。要拿备份软件自己记录的校验值和重新计算的散列做比对。

如果用的是Veritas NetBackup，每个备份镜像有独立的catalog记录。先把catalog导出来，再对备份集文件重新计算SHA256：

bpimagelist -d 01/01/2026 -e 01/31/2026 -l > /tmp/image_list.txt

find /backup/pool -type f -name "*.img" -mtime -30 -exec sha256sum {} \; > /tmp/recalc_hashes.txt

diff <(sort /tmp/image_list.txt) <(sort /tmp/recalc_hashes.txt)

没有catalog记录可查的话，至少保留一份离线散列清单。我们之前做过一个项目，客户每周把备份集的SHA256清单写到一台不联网的机器上，应急的时候直接比对，省了至少6个小时。

步骤三：在隔离沙箱中恢复最近7天备份点

不要在生产环境直接恢复。先准备一台物理隔离的沙箱主机，配置和原始数据环境尽量接近，但网卡只连一个独立的交换机，不接任何生产网段。

恢复命令取决于你的备份软件。用Veeam举例：

# 在沙箱主机上安装Veeam Backup & Replication Console

用恢复向导选择备份点，目标选沙箱主机

恢复前先禁用沙箱主机的所有虚拟网卡

Get-NetAdapter | Disable-NetAdapter -Confirm:$false

这里我多说一句。恢复的时候一定要选“恢复到新位置”，不要选“原地恢复”。原地恢复会覆盖现有数据，万一恢复出来的数据有问题，你连原始状态都丢了。

步骤四：扫描恢复数据中的异常文件和进程

数据恢复出来之后，先别急着启动服务。先做静态扫描，再做动态行为观察。

静态扫描用两个东西配合。一个是ClamAV，速度够快，适合先过一遍大文件。另一个是YARA规则，针对你已知的威胁特征做匹配：

clamscan -r --bell --max-filesize=2000M /restore_mount/

yara -r /rules/apt_backdoor.yar /restore_mount/

动态观察更关键。启动恢复出来的服务之前，先用strace或Process Monitor看启动过程加载了哪些文件、访问了哪些网络地址。如果发现某个服务启动时尝试连接外部IP，基本可以判定备份集被污染了。

# Linux下跟踪服务启动的文件和网络行为

strace -f -e trace=open,connect -o /tmp/service_trace.log systemctl start restored_service

grep "connect" /tmp/service_trace.log | grep -v "127.0.0.1"

步骤五：确认干净恢复点并重新建立备份基线

把最近7天的备份点都走一遍步骤三和步骤四，找到最早一个没有异常行为和异常文件的恢复点。这个点就是你的干净基线。

确认干净之后，做三件事。第一，把干净的恢复数据重新做一次全量备份，生成新的备份集。第二，把旧的、可能被污染的备份集全部隔离，不要删除，保留作为取证样本。第三，重置所有备份域的账号密码，包括服务账号，并且开启备份管理节点的操作审计日志。

auditctl -w /backup/pool/ -p rwxa -k backup_access

很多人觉得恢复备份是最稳妥的操作，数据丢了就恢复，天经地义。但你想一下，如果备份集已经被污染，恢复这个动作等于把攻击者的后门重新部署了一遍。

我在一个制造业客户那边见过这种情况。他们中了勒索软件，生产数据库被加密，IT团队很果断，直接用当天凌晨的备份做了恢复。恢复完两个小时，数据库又被加密了。后来查出来，攻击者在备份代理上留了一个计划任务，每次有新备份生成，就自动注入一段恶意存储过程。恢复的时候，这段存储过程跟着数据一起回来了。

备份域的信任模型要改。以前我们默认备份是“最后一道防线”，现在得换个角度：备份域也是攻击面，而且是一个一旦失守就很难被发现的地方。那个AI公司案例里，攻击者在备份域待了47天，期间生产环境风平浪静，没有任何异常告警。如果不是一次偶然的出口流量审计发现了异常外传，他们可能到现在都不知道数据已经没了。

在备份方案设计上，我们测过一些产品，对比下来发现不可变存储加气隙隔离的架构在防篡改上确实有效。比如中科热备的不可变存储方案，备份数据写入后在一定周期内不允许任何修改或删除，配合气隙隔离把备份域和生产网络物理断开，攻击者即使拿到备份服务器权限，也改不了已经写进去的备份集。这种设计至少把“备份被污染”这个风险从流程上卡住了。

回到响应本身。五步SOP里第一步冻结访问权限是最容易被跳过的，团队往往急着恢复数据，直接跳到第三步。没有冻结权限就恢复，等于给攻击者留了继续操作的口子。先把门关上，再清理房间，顺序不能反。

195TB训练数据被拖走前，攻击者已在备份域潜伏47天

安全

备份域潜伏47天拖走195TB数据：应急响应五步排查SOP（冻结权限→散列校验→沙箱恢复→恶意扫描→重建基线），防止被污染备份集二次入侵。备份域已成攻击面，不可变存储+气隙隔离可防篡改。

数据恢复

数据库

服务器

Windows

Linux

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

195TB训练数据被拖走前，攻击者已在备份域潜伏47天

195TB训练数据被拖走前，攻击者已在备份域潜伏47天

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐