已删除文件恢复结果与覆盖程度分析

已删除文件恢复结果与覆盖程度分析

0x02电子取证 里的 3文件恢复 解决的是“能不能把删掉的东西捞出来”。到了 0x03取证分析，重点就不再是工具按钮怎么点，而是要回答：

• 恢复结果到底说明了什么
• 是真的“删了但没覆盖”，还是只剩碎片
• 是普通误删，还是攻击者在清痕
• 恢复到的只是内容，还是还能定位路径、时间、用户和攻击阶段

应急现场里，最容易出现两种误判：

• 恢复出一个文件，就当成“完整证据已经拿到”
• 没恢复出文件，就当成“没有删除行为”

这两种都不对。恢复分析的关键，是把恢复程度、元数据残留、存储介质类型、时间线位置一起看。

0x01 这篇对应 0x02 里的什么内容

这篇文章主要承接 0x02电子取证/3文件恢复 下的工具与方法，包括：

• DiskGenius
• R-Studio
• UFS Explorer
• WinHex

以及延伸到镜像分析里常见的：

• The Sleuth Kit / Autopsy
• 未分配空间 carving
• MFT / inode / journal / slack 残留分析

因此本文默认你已经完成了恢复动作，手里已经有以下某一类结果：

• 恢复出的完整文件
• 只能恢复的部分文件
• 只恢复到文件名、路径、时间戳等元数据
• 只能在未分配空间或 slack 中看到碎片

分析的任务，是把这些结果翻译成可交付的结论。

0x02 先给恢复结果分级，不要一上来就写“恢复成功”

1. 完整恢复

表现通常是：

• 文件可打开
• 哈希稳定
• 内容连续
• 结构完整

这类结果可以支持你直接判断：

• 本地曾经真实存在过这个文件
• 删除后在覆盖前被成功恢复
• 文件内容可直接进入事件分析

2. 部分恢复

表现通常是：

• 文件能识别类型但无法完整打开
• 头尾有一部分，正文缺失
• 视频、压缩包、数据库导出文件损坏

这类结果更适合的结论是：

• 文件曾经存在的证据很强
• 但当前恢复到的是“残体”，不能把缺失内容当成不存在
• 需要借助同目录残留、缩略图、日志、元数据补足上下文

3. 元数据恢复

表现通常是：

• 只看到文件名、路径、大小、创建/修改/删除时间
• 能看到 MFT/inode 记录，但正文拿不到

这类结果非常常见，也非常容易被低估。它通常足以说明：

• 文件确实存在过
• 文件大致放在哪儿
• 它是什么类型、可能属于什么用途
• 删除发生在什么时间窗内

4. 碎片恢复

表现通常是：

• 只能从未分配空间 carve 出片段
• 只能看到关键字符串、头部签名、局部内容

这类结果不能支撑“完整文件已恢复”，但非常适合支撑：

• 存在过某类文件
• 某些关键内容曾落盘
• 攻击者可能试图删除或覆盖相关证据

0x03 命令结果如何解释成恢复结论

这里最重要的，不是会不会跑命令，而是看懂结果以后怎么定性。

1. fls/Autopsy 里标记为 deleted，不等于内容一定还能取回

如果你在 Sleuth Kit 或 Autopsy 里看到：

r/r 128-128-1: invoice.zip
+ Deleted

更合理的分析结论是：

• 文件系统层面已经把它标记为删除对象
• 这说明删除动作成立
• 但不能仅凭 Deleted 标签就写“文件内容可恢复”

真正还要继续确认的是：

• 数据块是否仍在
• 文件是否已部分覆盖
• 是否只剩目录项或元数据

很多初学者会把“列出来的 deleted file”误解为“文件必定可导出”，这是错误的。

2. istat 能看到 inode/MFT 元数据，但拿不到正文，说明“存在过”比“可恢复”更确定

如果结果类似：

Allocated File
Name: db_export.sql
Size: 104857600
Created: 2026-06-15 00:41:20
Modified: 2026-06-15 00:44:03
Deleted: Yes

但导出时发现内容损坏或为空，更适合的判定是：

• db_export.sql 曾经在该主机上真实存在
• 它的大小和时间戳足以支持“导出行为发生过”的推断
• 当前不能证明导出内容完整保留
• 但足以把“导出 -> 删除/覆盖”串入时间线

这类情况在窃密事件里很关键，因为它说明痕迹存在过，但内容可能已被处理。

3. blkls 或 carving 能出内容片段，但没有原始文件名和路径，说明“内容存在”强于“归属定位”

如果从未分配空间抓到：

PK\x03\x04
... customers.csv ...
... admin_password ...

更好的分析表述是：

• 已在未分配空间中发现 ZIP/CSV 类文件内容片段
• 说明相关数据曾经落盘
• 但由于来自 carving，原始文件名、目录路径、时间戳未必完整可信
• 这更适合用来证明“内容存在过”，不适合单独作为“精确文件归属”的唯一证据

Sleuth Kit 的 blkls 与 carving 工作流本质上就是“从未分配空间找残留”，它强在内容发现，不强在还原完整文件语境。

4. 恢复出的文件能打开，但目录项和时间线对不上，优先怀疑重名或旧残留

如果工具恢复出一个 report.docx，但：

• 当前目录结构里找不到对应路径
• 时间戳明显早于本次事件
• 内容与现场业务完全不相关

就不能简单写成“这是本次事件删掉的文件”。更合理的结论是：

• 该文件可能是历史残留
• 也可能是同名旧文件被恢复出来
• 当前只能证明介质上存在过相关内容，尚不能直接归入本次攻击链

恢复分析里，最怕的就是把“介质残留”直接等同于“本次事件证据”。

0x04 HDD、SSD、TRIM 决定了你的恢复边界

1. HDD 上“删了但没覆盖”的概率相对更高

在机械硬盘上，常见情况是：

• 删除动作先移除索引/标记
• 数据块在被新数据复用前仍然存在

因此如果恢复结果较好，更适合解释为：

• 删除后没有发生大量覆盖
• 文件内容在一段时间内保持可恢复

2. SSD 上“恢复不到”并不稀奇，不能直接反推“没删过”

SSD 常见的限制是：

• TRIM
• Garbage Collection
• Wear Leveling

如果是 SSD 场景，恢复失败更适合的分析表述是：

• 当前未恢复到目标文件内容
• 但考虑到 SSD 的 TRIM/GC 机制，不能据此否定其曾存在或曾被删除
• 应优先转向元数据、日志、缩略图、同步目录、MFT Slack、应用痕迹等旁证

这也是为什么现代取证里，“恢复不到”越来越不是反证。

公开资料反复强调这一点：现代 SSD 删除后的可恢复性明显低于传统 HDD，恢复失败往往是介质机制导致，而不一定代表事件不存在。

0x05 什么样的恢复结果更像攻击清痕

1. 恢复对象集中在导出、压缩、脚本、中间产物

如果恢复出来或恢复到元数据的对象集中是：

• .sql
• .csv
• .zip
• .7z
• .rar
• .ps1
• .bat
• 临时上传工具

那么比恢复出普通办公文档更值得怀疑。这类文件类型和攻击链中：

• 导出
• 打包
• 投送
• 执行

的关系更直接。

2. 恢复到的时间线正好落在异常窗口

如果恢复结果显示：

• 00:41 创建导出文件
• 00:45 压缩
• 00:48 删除
• 00:50 出现大流量外联

那么就很难再解释为普通误删，而更像：

• 数据导出后本地清理
• 攻击者删除中间产物
• 试图压缩现场证据面

3. 恢复到的内容与主机角色不匹配

例如：

• Web 服务器里恢复出客户数据导出包
• 办公终端里恢复出运维脚本和批量主机清单
• 数据库服务器里恢复出压缩打包脚本和浏览器下载工具

这类“角色错位”非常有助于把恢复结果从普通删除提升为攻击证据。

0x06 三个特别容易误判的边界

1. 恢复失败，不等于没有删除行为

恢复失败可能是：

• 已被覆盖
• SSD 已执行 TRIM/GC
• 文件本身碎片化严重
• 你只恢复了单一分区或单一文件系统

所以正确写法应是：

• 未恢复到目标文件内容
• 不足以否定历史存在或删除行为
• 仍需结合日志、目录项、回收站、缩略图、索引和应用痕迹判断

2. 恢复出内容，不等于能精确归属到本次事件

内容可能来自：

• 更早的历史删除
• 其他用户会话
• 旧版本文件
• 同名文件的旧副本

因此任何恢复内容都必须和：

• 目录结构
• 时间戳
• 用户上下文
• 攻击时间窗

做交叉验证。

3. 只恢复到文件头，不等于文件完整可用

比如只看到：

MZ
PK\x03\x04
SQLite format 3

这只能说明：

• 某类文件或载荷曾经存在

不能直接写成：

• 已完整恢复恶意程序
• 已完整恢复数据库
• 已完整恢复压缩包

0x07 哪些“只剩元数据”的结果反而很有价值

很多现场过于强调“恢复正文”，反而忽略了这些极强线索：

• NTFS MFT 记录
• MFT Slack 中残留元数据
• USN Journal
• $LogFile
• ext4 journal / inode 残留
• 缩略图、预览、索引

比如 Sygnia 在 2025 年关于 MFT Slack 的研究就指出，即使现代 Windows 10/11 上文件内容不再容易残留，已删除甚至被安全擦除文件的元数据仍可能在 MFT Slack 中保留下来。这类结果对 IR 特别有价值，因为它们能帮助你回答：

• 文件叫什么
• 大小大概多少
• 何时存在过
• 是否属于本次事件时间窗

这对于“证明攻击者生成过某个中间文件”往往已经够用了。

0x08 如何把恢复结果串进攻击链

恢复分析真正的价值，不是“多找几个被删文件”，而是把它们塞回攻击链。

场景一：导出后删除

链路通常是：

1. 恢复到 db_export.sql 或其元数据
2. 时间上紧跟数据库访问
3. 随后出现压缩包
4. 之后本地删除
5. 最后出现外联

这个链条比单纯“恢复出一个 SQL 文件”更有交付价值。

场景二：工具投放后删除

链路通常是：

1. 恢复到 mimikatz.exe、procdump.exe、anydesk.exe、fscan.exe 或脚本残留
2. 结合浏览器下载或命令历史
3. 随后文件被删除

这时恢复结果的价值在于证明：工具曾经落地并被清理过。

场景三：勒索前清理中间文件

链路通常是：

1. 恢复出批处理脚本、内网主机清单、压缩配置、临时日志
2. 大量文件在短时间内被删除
3. 随后出现横向、加密或大量服务/任务创建

这类恢复结果虽然未必“敏感”，但对还原攻击者准备阶段非常重要。

0x09 和其他分析篇怎样联动

这篇文章最适合和以下内容串起来：

• 回收站残留与删除意图分析.md：判断“删到回收站”还是“直接删除”
• 备份文件、压缩包与数据打包外传取证分析.md：判断恢复出的对象是不是中间打包产物
• 命令行历史取证与攻击者行为还原.md：确认删除前是否有导出、压缩、投送命令
• 日志清理与反取证痕迹识别.md：判断恢复不出内容是否属于更强的反取证

0x0A 公开资料与分析借鉴

下面这些公开资料适合继续深挖：

• Sygnia: The Forensic Value of MFT Slack Space in Modern Windows Systems
• Sleuth Kit: sleuthkit/sleuthkit
• Elite Digital Forensics: Deleted Data Recovery in Computer Forensics
• Hackers-Arise: Digital Forensics, Part 03: Recovering Deleted Files

这些材料最值得借鉴的共同点是：

• 删除不等于消失
• 但恢复也不是魔法
• 正文、元数据、未分配空间、slack 残留的分析价值并不相同
• 现代 SSD 场景必须降低“必定能恢复”的预期

0x0B 建议的交付结构

恢复结果建议整理为如下表格：

0x0C 总结

文件恢复分析的关键，不是简单回答“恢复出来没有”，而是要回答：

• 恢复出来的是正文、碎片，还是元数据
• 当前结果说明“存在过”还是“完整可读”
• 恢复失败是因为不存在，还是因为覆盖/TRIM/碎片化
• 这些恢复结果在攻击链里属于导出、投送、清痕还是外传前的中间步骤

当你把恢复程度、介质特性、元数据残留和时间线放在一起看时，0x02 里的“文件恢复”才真正升级成 0x03 的“删除行为重建与证据强度评估”。