备份文件、压缩包与数据打包外传取证分析

在很多事件里，真正造成业务损失的不是主机被控本身，而是攻击者把数据带走了。这个过程在主机侧通常不会直接表现为“删除数据库”或“明显复制文件”，而更常见的是一条相对隐蔽的整理链：先找高价值数据，再打包、压缩、切片，最后通过 HTTP、SCP、RSync、网盘、对象存储或代理通道带出现场。

在 0x02电子取证 里，重点文件检查 已经覆盖了临时目录、最近访问文件、文件时间、浏览器下载目录等基础证据入口。到了 0x03取证分析，真正要回答的问题是：这些文件和压缩包究竟是正常备份，还是攻击者为外传而特意准备的中间产物。

0x01 数据外传分析要回答什么

建议优先回答以下四个问题：

攻击者整理了哪些数据？ 是数据库转储、文档、源码、日志、配置、证书还是客户资料。
数据是如何被打包的？ 是压缩、归档、切片、重命名，还是伪装成备份文件。
打包文件后来去了哪里？ 留在本地、移动到共享目录、经隧道转发，还是直接出网。
这次打包是否和攻击链闭环？ 是否紧接在数据库访问、凭据窃取、横向移动之后发生。

只有把“数据来源 -> 打包动作 -> 传输动作 -> 最终去向”串起来，才能从“可疑压缩包”升级为“已形成外传链”。

0x02 攻击者最爱打包的几类对象

1. 数据库与业务导出

常见形式：

.sql
.dump
.csv
.txt
表级分片导出

这类通常和数据库痕迹与凭据泄露分析.md 强相关。

2. 文档与办公资料

常见目标：

合同
客户资料
财务报表
项目文档
运维手册

这类外传常发生在办公终端、文件服务器或共享目录。

3. 源码与配置

常见目标：

Git 仓库副本
发布包
配置文件
密钥与证书
构建脚本

这类数据一旦外传，后续风险常常不是“当前事件结束”，而是供应链或二次入侵风险开始。

4. 凭据与身份材料

常见目标：

SSH 私钥
浏览器 Cookie 数据库
口令本
RDP 配置
API Key / Token 文件

这类体积不大，但价值极高。

0x03 数据打包通常会留下哪些主机痕迹

1. 压缩与归档工具执行痕迹

重点关注：

tar
zip
rar
7z
gzip
bzip2
compress-archive
makecab

如果命令历史或进程日志中出现：

tar czf backup.tar.gz /var/www /home/app
zip -r data.zip /data/customer
rar a secret.rar /tmp/export
7z a -p123456 docs.7z /home/docs

这已经非常接近外传准备阶段。

2. 临时目录中的中间产物

重点路径包括：

/tmp
/var/tmp
/dev/shm
%TEMP%
%ProgramData%
用户桌面与下载目录
共享目录 / 备份目录

攻击者喜欢在这些位置短暂存放：

压缩包
切片文件
导出结果
临时清单

这些文件可能很快就会被删掉，因此时间线很关键。

3. 文件名伪装

常见伪装方式：

backup_20240615.tar.gz
log.zip
update.rar
temp.7z
image.iso

真正危险的地方在于，这些名字看起来都“像正常运维”。

0x04 如何区分正常备份与恶意打包

这是分析中最容易误判的地方。

1. 时间维度

正常备份通常：

发生在固定窗口
周期稳定
命名规则一致

恶意打包则更常见于：

异常登录之后
数据库访问之后
夜间临时执行
非固定周期

2. 路径维度

正常备份多落在：

固定备份目录
备份服务器挂载点
规定存储路径

恶意打包更常落在：

临时目录
用户目录隐藏路径
桌面 / 下载目录
不属于备份流程的共享路径

3. 内容维度

正常备份更偏：

全量或固定对象
有命名规则
有留存周期

恶意打包更偏：

高价值数据的选择性打包
多目录混打
凭据、配置、文档混装

4. 后续动作维度

这最关键。

如果打包后紧接着出现：

scp, rsync, curl -T
浏览器上传
网盘 / 对象存储访问
代理隧道中的大流量传输

那就基本不再是普通备份，而是外传链。

0x05 三种常见外传链

场景一：数据库转储后打包外传

典型链条：

获取数据库凭据
执行导出
生成 .sql 或 .csv
使用 tar/zip/7z 打包
通过 HTTP、SCP 或代理通道外传

这是最经典的一类业务窃密路径。

场景二：文件服务器资料整理后切片上传

典型链条：

访问共享目录
复制高价值文档到临时目录
压缩并分卷
上传到外部存储

分卷压缩通常意味着攻击者在绕过单文件大小限制或带宽监控。

场景三：源码与配置打包带走

典型链条：

拿下发布机 / Git 节点
导出项目目录、配置、证书
压缩伪装成正常构建产物
经跳板或隧道带出

这类事件往往会和后续供应链污染、页面篡改或二次入侵联系起来。

0x06 数据外传在时间线上的关键节点

建议按以下顺序还原：

什么时候开始接触高价值数据
什么时候生成导出文件
什么时候开始压缩
什么时候发生大体量传输
什么时候清理中间产物

如果能在时间线上看到：

mysqldump
/tmp/db.sql
/tmp/db.sql.gz
对外 scp
rm -f /tmp/db.sql*

那么这条数据外传链就非常完整。

0x07 文件侧应重点关注的异常信号

1. 文件短暂出现又消失

如果通过日志、目录快照、最近文件、命令历史发现某压缩包曾存在，但当前已经消失，这通常说明：

攻击者已完成传输
攻击者主动清理中间产物

2. 压缩包与访问对象不一致

例如：

只访问了数据库，却打出了包含文档和私钥的混合包
只登录了 Web 服务器，却突然生成了源码加配置大包

说明攻击者在做主动筛选，而不是系统正常产物。

3. 高压缩率与密码保护

例如：

7z a -p...
rar a -hp...

说明攻击者有较强的隐藏和规避意识，常与外传行为强相关。

0x08 与前面专题的衔接点

这篇和前面几篇内容是强关联的：

与数据库痕迹与凭据泄露分析.md 衔接：解释导库后的下一步
与命令行历史取证与攻击者行为还原.md 衔接：打包命令往往直接出现于历史中
与远控木马落地后的代理隧道与出网链分析.md 衔接：解释打包后的数据经什么路径出去

0x09 公开案例与现场命令

1. 案例一：Exchange WebShell 事件中的 cabinet 打包与 HTTP 外传

Unit 42 在 2021 年披露的 Exchange 事件，不仅包含凭据抓取，也非常适合作为“数据打包外传”专题案例：

攻击者通过 WebShell 执行 PowerShell 收集主机信息
继续尝试抓取凭据
把信息收集和凭据抓取结果压缩成 cabinet 文件
将文件存放到 IIS 可直接访问目录
然后通过浏览器或脚本直接访问 URL 把 cabinet 文件取走

这个案例特别适合蓝队，因为它清楚展示了“先收集 -> 再压缩 -> 再通过 Web 路径外传”这条链。

公开来源：

Unit 42: Actor Exploits Microsoft Exchange Server Vulnerabilities, Cortex XDR Blocks Harvesting of Credentials

2. 案例二：ClickFix / ClearFake 链路中的 ZIP 落地与二次载荷释放

Proofpoint 在 2024 年披露的 ClickFix / ClearFake 案例中，攻击者通过 PowerShell 下载 data.zip，解压后寻找 .exe 执行。

虽然这类 ZIP 主要用于载荷投递而不是直接外传数据，但它能非常直观地说明一个现场判断原则：

只要看到了 PowerShell -> ZIP -> 解压 -> 执行
就必须继续追查这是不是后续“打包数据 -> 再上传/外传”的前置准备

公开来源：

Proofpoint: From Clipboard to Compromise: A PowerShell Self-Pwn

3. Linux 现场排查命令模板

下面这组命令适合在 Linux 主机上快速排查“最近是否有人打包、切片、传输或清理压缩文件”：

# 查最近 3 天内新增/修改的压缩包、备份包、导出文件
find /tmp /var/tmp /dev/shm /home /root /opt /data -type f \
  \( -name "*.zip" -o -name "*.rar" -o -name "*.7z" -o -name "*.tar" -o -name "*.tar.gz" -o -name "*.cab" -o -name "*.sql" -o -name "*.csv" \) \
  -mtime -3 -ls 2>/dev/null

# 查大体积文件
find /tmp /var/tmp /home /root /opt /data -type f -size +50M -ls 2>/dev/null | sort -k7,7 -k8,8

# 查命令历史中的打包与外传命令
grep -RInE 'mysqldump|pg_dump|tar czf|zip -r|rar a|7z a|scp |rsync |curl -T|wget .*\.zip|split -b' /root/.bash_history /home/*/.bash_history 2>/dev/null

# 查近期被删除但可能仍可从日志/审计侧印证的中间路径
grep -RInE 'rm -f .*\.zip|rm -f .*\.7z|rm -f .*\.sql|shred ' /root/.bash_history /home/*/.bash_history 2>/dev/null

如果你已经知道一个疑似外传时间窗，例如 2026-06-15 01:00 到 02:00，可以继续这样缩：

find /tmp /var/tmp /data -type f -newermt '2026-06-15 01:00:00' ! -newermt '2026-06-15 02:00:00' -ls 2>/dev/null

4. Windows 现场排查命令模板

# 查近期压缩包、导出文件、cab 文件
Get-ChildItem C:\ -Recurse -Force -ErrorAction SilentlyContinue |
  Where-Object {
    $_.Name -match '\.(zip|rar|7z|cab|sql|csv|dump|bak)$'
  } |
  Sort-Object LastWriteTime -Descending |
  Select-Object -First 200 FullName,Length,CreationTime,LastWriteTime

# 查大文件
Get-ChildItem C:\ -Recurse -Force -ErrorAction SilentlyContinue |
  Where-Object {!$_.PSIsContainer -and $_.Length -gt 50MB} |
  Sort-Object Length -Descending |
  Select-Object -First 100 FullName,Length,LastWriteTime

# 查近期压缩相关进程命令
$start=(Get-Date).AddDays(-3)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688; StartTime=$start} |
  Where-Object {
    $_.Message -match 'rar\.exe|7z\.exe|powershell\.exe|makecab|tar\.exe|compress-archive|curl\.exe|scp\.exe'
  } |
  Select-Object TimeCreated, Message

5. 面向外传链的实战排查步骤

如果你怀疑某台主机已经发生过数据打包与外传，建议直接按以下顺序落地：

先找时间窗内的 .sql/.csv/.zip/.7z/.cab/.tar.gz
再找同一时间窗内的 mysqldump / tar / 7z / makecab / scp / curl -T
再看大文件外联、共享目录复制或 Web 路径下载
最后看是否存在 rm/shred/del 对中间产物的清理

这样才能把“一个可疑压缩包”真正提升成“已发生窃密”的结论。

0x0A 三个常见误区

1. 看到备份文件名就当作正常文件

攻击者最喜欢的伪装就是“像备份”。

2. 只看压缩包，不看前序数据来源

如果不往前追导出、复制、访问对象，就无法说明这个包为什么出现。

3. 只看本地文件，不看出站动作

打包不一定等于外传，但打包后接着外联、上传、代理传输，才是窃密链真正成立的关键。

0x0B 建议的交付结构

数据打包外传事件适合整理为如下表格：

时间	证据源	事件	关联对象	结论
01:12:03	命令历史	执行导出命令	`mysqldump`	开始整理数据
01:14:18	文件时间	生成中间文件	`/tmp/db.sql`	数据已落地
01:16:41	进程 / 命令	执行压缩	`tar czf db.tar.gz /tmp/db.sql`	打包完成
01:18:05	网络日志	向外传输大文件	`scp -> x.x.x.x`	数据外传发生
01:19:22	文件操作	删除中间产物	`/tmp/db.sql*`	存在清痕

0x0C 总结

数据外传分析的关键，不是简单证明“这里有个压缩包”，而是要完整说明：

这个包里装了什么
为什么会在这个时间点出现
它和前面的导出、访问、复制动作是否闭环
它最终是否被带离现场

当你把高价值数据接触、导出、打包、传输、删除这五个阶段连成一条时间线时，0x02 里的重点文件检查就真正升级成了 0x03 的窃密事件分析能力。