关键词：工件地图、时间线、系统信息、卷影副本、回收站、取证工作站
难度：入门
前置知识：磁盘镜像与仿真、NTFS 基本概念
一、概述
拿到一台 Windows 主机镜像，第一个问题永远是：证据在哪里？
Windows 不给你一个集中的审计日志。「谁在什么时候做了什么」散落在几十个互不相干的位置——注册表 hive、.evtx 文件、目录里的二进制缓存、SQLite 数据库、隐藏的 NTFS 数据流。这些工件分属不同子系统，各有自己的生命周期、保留策略和清除方式。有的重启就重建，有的删掉就再也回不来。
两个最常见的处置错误都源于此：
- 查获了一台运行中的机器，直接拔电关机。结果丢失当前会话的内存态工件（ShimCache 未落盘条目、浏览器会话、剪贴板、网络连接），且改变了系统状态。
- 只提取了「看得见」的文件（
Users\ 下的文档），漏掉了 C:\Windows 下的系统工件——而执行痕迹、登录记录、持久化证据几乎全在后者里。
要回答的问题只有一个：每类工件在哪里、值多少、活多久、怎么被清掉。分类的依据是「谁记录的」——因为清除难度决定了攻击者会先清哪里、因此哪里残留得最可信。
这张地图卡在「拿到设备」到「逐工件分析」之间，是采集阶段的决策依据。上游是镜像制作与接入，它不产出证据，它决定了你能不能拿到证据。地图本身要产出三样：Windows 版本判定（决定用哪个解析器）、工件存在性清点、接入未污染证据的验证。下游支撑所有具体篇目——有了地图，才知道哪个方向有料、哪个方向是空的，而「空的」往往也是结论。
工件全景按证据类型组织如下：
| 类别 |
记录者 |
典型工件 |
清除难度 |
| 显式审计 |
Windows 安全/审计子系统 |
Security.evtx、System.evtx、Sysmon |
★★★★ 可被 wevtutil cl 清除 |
| 性能优化副产品 |
内核为加速启动而缓存 |
Prefetch、ShimCache、Amcache |
★★★ 需清缓存/删文件，重启后重建 |
| Shell 便利功能 |
资源管理器为 UX 记录 |
LNK、JumpList、RecentDocs、UserAssist |
★★ 用户可在设置里一键关闭 |
| 应用自身数据 |
各应用自己的数据库 |
浏览器、邮件、聊天软件、Office |
★ 用户可自删历史 |
| 文件系统元数据 |
NTFS 驱动 |
$MFT、$LogFile、$UsnJrnl |
★★★★ 需占用空闲区，极难 |
| 一个容易被忽略的层级 |
卷影副本（VSS） |
每个快照是某时刻的完整文件系统视图 |
取证入口 mklink /d X: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN\，每个快照对应唯一卷 |
同一份工件，XP 和 Win11 上可能根本不叫同一个名字、也不在同一个位置。选错解析器，读出来的是垃圾。
| 差异点 |
XP/2003 |
Vista/7 |
8/8.1 |
10/11 |
| 事件日志格式 |
.evt（16KB 定长） |
.evtx |
.evtx |
.evtx |
| Prefetch |
v17，1 个时间戳 |
v23，1 个时间戳 |
v26，8 个时间戳 |
v30/v31，MAM 压缩 |
| Prefetch 条目上限 |
128 |
128 |
128 |
1024 |
| ShimCache 容量 |
96 |
512 |
512 |
1024 |
| Amcache |
RecentFileCache.bcf |
RecentFileCache.bcf |
Amcache.hve |
Amcache.hve |
| Jump List / SRUM |
无 / 无 |
有限 / 无 |
有 / 有 |
有 / 有 |
| Sysmon |
不支持 |
不支持 |
支持 |
支持 |
| ShimCache 路径 |
Session Manager\AppCompatCache（无内层子键） |
Session Manager\AppCompatCache\AppCompatCache |
同 |
同 |
读法：拿到镜像先确定版本，再决定用哪个解析器。
据此能判断的是：这台机器的 Windows 版本、哪些工件实际存在、每个工件的位置与取证价值、以及各类工件的清除难度与被清理的可能性。
判断不了的有六条：
- 按「清除难度」分类的价值在于反推。 攻击者的反取证会从易到难清——先清浏览器历史，再清事件日志，再删 Prefetch。
$UsnJrnl 与 $LogFile 因为清理需要占用空闲区并可能被占用空间保护，通常被放弃。因此「事件日志缺失」本身就是值得记录的发现，不能直接读成「没有活动」。
- 任何具体行为。 地图只标注位置与价值，不解释任何单个工件的语义。
- 存在性之外的可用性。 工件存在不代表数据完整——是否被覆盖、是否超出保留期、是否被清理，要在具体篇目里判断。
- VSS 里的内容。 快照存在与否要靠
vssadmin list shadows 揭示，默认保留空间有限，快照可能很少或很小。
- 跨主机的关联。 单台主机的地图回答不了「它连着谁」。
- 已删除数据。 地图基于现存文件，已删除内容需要卷层面的恢复能力。
往下读之前先确认你已经完成镜像制作与完整性校验，并且理解「为什么先验证哈希再分析」；具备 Windows 的基础结构认知——注册表 hive、事件日志、%SystemRoot% 与用户配置文件的位置；了解 NTFS 的基本概念（MFT、备用数据流），见NTFS 结构与 MFT 解析；熟悉只读挂载与仿真环境，VSS 与挂载都是在仿真环境里做的，见虚拟机仿真。同时清楚绝不可逆的操作清单：VSS 枚举是只读的，但绝不要用 vssadmin delete shadows 清空间——那是直接销毁证据。
二、核心原理
2.1 工件按"谁记录的"分为五类
每类痕迹由哪个子系统写入、在什么时候写入，直接决定了它的可信度和清除难度。
| 类别 |
记录者 |
典型工件 |
清除难度 |
| 显式审计 |
Windows 安全/审计子系统 |
Security.evtx、System.evtx、Sysmon |
★★★★ 可被 wevtutil cl 清除 |
| 性能优化副产品 |
内核为加速启动而缓存 |
Prefetch、ShimCache、Amcache |
★★★ 需清缓存/删文件，重启后重建 |
| Shell 便利功能 |
资源管理器为 UX 记录 |
LNK、JumpList、RecentDocs、UserAssist |
★★ 用户可在设置里一键关闭 |
| 应用自身数据 |
各应用自己的数据库 |
浏览器、邮件、聊天软件、Office |
★ 用户可自删历史 |
| 文件系统元数据 |
NTFS 驱动 |
$MFT、$LogFile、$UsnJrnl |
★★★★ 需占用空闲区，极难 |
实战推论：攻击者的反取证会从易到难清——先清浏览器历史（用户可删），再清事件日志，再删 Prefetch。$UsnJrnl 和 $LogFile 因为清理需要占用空闲区并可能被占用空间保护，通常被放弃。因此"事件日志缺失"本身就是值得记录的发现，不能直接读成"没有活动"。
2.2 工件目录结构总览
下表是 Windows 取证的核心索引。路径以 Windows 10/11 为基准，其他版本差异见 2.4。
系统级（C:\Windows\）
| 路径 |
工件 |
价值 |
参见 |
System32\config\SYSTEM |
硬件/服务/控制集/ShimCache |
★★★★★ |
02、06 |
System32\config\SOFTWARE |
已安装软件、SRUM 配置、卸载残留 |
★★★★★ |
02、09 |
System32\config\SAM / SECURITY |
本地账户与密码哈希 / LSA 秘密 |
★★★★★ |
02 |
System32\sru\SRUDB.dat |
SRUM 资源使用数据库 |
★★★★★ |
09 |
System32\winevt\Logs\*.evtx |
事件日志（含 Sysmon） |
★★★★★ |
03、04 |
Prefetch\*.pf |
程序执行证据 |
★★★★★ |
05 |
AppCompat\Programs\Amcache.hve |
程序哈希/编译时间 |
★★★★ |
06 |
System32\Tasks\ / inf\setupapi.dev.log |
计划任务 / 设备安装历史 |
★★★★ |
— |
用户级（C:\Users\<用户名>\）
| 路径 |
工件 |
价值 |
参见 |
NTUSER.DAT |
用户注册表：RecentDocs、UserAssist、RunMRU、TypedPaths |
★★★★★ |
10 |
AppData\Roaming\Microsoft\Windows\Recent\*.lnk |
快捷方式（含 TrackerDataBlock） |
★★★★★ |
07 |
...\Recent\AutomaticDestinations\*.automaticDestinations-ms |
Jump List |
★★★★★ |
07 |
AppData\Local\Google\Chrome\User Data\Default\ |
Chrome 密码/历史/Cookie |
★★★★★ |
08 |
AppData\Local\Microsoft\Edge\User Data\ |
Edge 同上 |
★★★★★ |
08 |
AppData\Roaming\Mozilla\Firefox\Profiles\ |
Firefox logins.json/key4.db |
★★★★★ |
08 |
AppData\Local\Microsoft\Recall\ 或 AppData\Local\CoreAIPlatform.00\ |
Recall 相关 |
★★★★★ |
12 |
AppData\Local\Microsoft\Windows\INetCache\ |
IE/Edge Legacy 缓存 |
★★★ |
08 |
系统元数据（NTFS 层，不在目录树中正常显示）
| 对象 |
位置 |
价值 |
$UsnJrnl:$J |
$Extend 目录 |
★★★★★ |
$MFT |
见 fsstat 输出 |
★★★★★ |
$LogFile |
NTFS 根 |
★★★★ |
$Recycle.Bin\<SID>\$I* |
回收站元数据 |
★★★★ |
卷影副本 System Volume Information\ |
历史版本文件 |
★★★★★ |
hiberfil.sys / pagefile.sys |
休眠镜像 / 可搜字符串 |
★★★★ |
$UsnJrnl 与 $MFT 的解析参见本板块第 11 篇与《文件系统分析》板块。
回收站（$Recycle.Bin）
$I 文件是 8 字节版本头 + 8 字节文件大小 + 8 字节删除时间（FILETIME）+ 路径长度 + UTF-16 路径；$R 是被删内容原件。
删除时间来自 $I 文件，而非 $R 的 MFT 时间戳。 两条时间线冲突时，这是关键区分点。
2.3 一个容易被忽略的层级：卷影副本（VSS）
卷影副本是"时间机器"，但只有知道快照存在才能用。
- 每个快照是某时刻的卷快照，包含当时的完整文件系统视图。
- 快照数量与大小由
vssadmin list shadows 揭示；默认保留空间有限，快照可能很少或很小。
- 取证入口：
mklink /d X: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN\，每个快照对应唯一卷，需与 vssadmin 输出的 Original Volume 对应。
vssadmin list shadows # 列出所有卷影副本（管理员权限）
vssadmin list shadowstorage # 查看影子副本存储占用
⚠️ VSS 枚举是只读操作，对运行中的机器相对安全。但绝不要用 vssadmin delete shadows 清空间——那是直接销毁证据。
2.4 Windows 版本差异对取证的实际影响
选错解析器会得到错误结论，而不只是"报个错"。用 v17 解析器读 v31 的 Prefetch，或用 16K .evt 解析器读 .evtx，出来的是垃圾或「文件损坏」。
| 差异点 |
XP/2003 |
Vista/7 |
8/8.1 |
10/11 |
| 事件日志格式 |
.evt（16KB 定长） |
.evtx |
.evtx |
.evtx |
| Prefetch |
v17，1 个时间戳 |
v23，1 个时间戳 |
v26，8 个时间戳 |
v30/v31，MAM 压缩 |
| Prefetch 条目上限 |
128 |
128 |
128 |
1024 |
| ShimCache 容量 |
96 |
512 |
512 |
1024 |
| Amcache |
RecentFileCache.bcf |
RecentFileCache.bcf |
Amcache.hve |
Amcache.hve |
| Jump List / SRUM |
无 / 无 |
有限 / 无 |
有 / 有 |
有 / 有 |
| Sysmon |
不支持 |
不支持 |
支持 |
支持 |
| ShimCache 路径 |
Session Manager\AppCompatCache（无内层子键） |
Session Manager\AppCompatCache\AppCompatCache |
同 |
同 |
读法：拿到镜像先确定版本，再决定用哪个解析器。
2.5 取证工作站配置
分析环境本身也是证据链的一环——分析工具的行为可能改变你读到的数据。
| 要求 |
理由 |
| 只读挂载，永不写回 |
挂载点设为只读；写保护器最保险 |
| 关闭 AutoPlay |
挂载可能触发自动运行、缩略图生成、journal 回放 |
| 不改系统时区/时钟 |
事件日志时间是本地时间，时区错误会导致全盘时间线错位 |
| 记录工具版本与哈希 |
同名工具不同版本解析结果可能不同，报告需可复现 |
最重要一条：任何"我打开看了一下"的操作，如果是在原始镜像上做的，都可能因 atime 更新、journal 回放、预览生成缩略图而改变证据。先复制，后分析。
三、操作步骤
3.1 第 1 步：镜像结构确认与工件存在性清点
mmls DigiForensics.dd # 分区布局
fsstat -o 2048 /work/DigiForensics.dd | grep -iE 'cluster|mft|serial|volume name'
fls -o 2048 -r -p /work/DigiForensics.dd > /evidence/fls-all.txt
工件存在性（"缺失"本身是发现）
grep -ic 'prefetch' /evidence/fls-all.txt # Prefetch 文件数
grep -ic 'amcache' /evidence/fls-all.txt # Amcache 是否存在
grep -icE '.evtx$' /evidence/fls-all.txt # 事件日志数量
grep -i 'usnjrnl' /evidence/fls-all.txt # UsnJrnl 位置
3.2 第 2 步：判断版本与 Prefetch 格式
先看 .pf 头部 4 字节——这一步决定后续所有解析器选择：
icat -o 2048 /work/DigiForensics.dd <pf-inode> > /evidence/sample.pf
xxd -l 16 /evidence/sample.pf
| 输出开头 |
含义 |
应对 |
4D 41 4D 04（MAM\x04） |
Win10/11 MAM 压缩 |
必须先用 PECmd 等工具解压 |
1F 00 00 00 / 1E 00 00 00 |
v31 / v30 |
高版本解析器 |
1A 00 00 00 / 17 00 00 00 / 11 00 00 00 |
v26 / v23 / v17 |
对应版本解析器 |
偏移 4 处 53 43 43 41（SCCA） |
未压缩，签名在固定位置 |
常规解析 |
3.3 第 3 步：提取注册表 hive、事件日志与元数据
mkdir -p /evidence/hives
hive 路径以实际系统为准，常见 /Windows/System32/config
for h in SYSTEM SOFTWARE SAM SECURITY DEFAULT; do
ino=$(fls -o 2048 -r -p /work/DigiForensics.dd | grep -E "config/$h$" | head -1 | cut -d' ' -f2)
icat -o 2048 /work/DigiForensics.dd "$ino" > "/evidence/hives/$h"
done
for h in /evidence/hives/*; do echo -n "$h: "; xxd -l 4 -p "$h"; done # 期望 72656766
用户 hive / 事件日志：先用 fls 定位 inode，再逐个 icat
fls -o 2048 -r -p /wor
