把 $UsnJrnl 与 $MFT 配对，做出真正的时间线

$MFT 告诉你文件系统现在的样子。它不告诉你产生这种状态的操作顺序。为了这件事，NTFS 还保留了第二个工件：Update Sequence Number Journal，即 $UsnJrnl。把两者配对，一张静态快照就变成了一部电影。journal 本身的深入解读请阅读专门的 USN 解析器站点；本文聚焦于为什么要与 MFT 一起读，以及两者组合能展示哪些任一单独都展示不了的东西。

`$UsnJrnl` 记录什么

每当文件被创建、修改、重命名或删除，NTFS 都会向 journal 追加一条描述该事件的固定大小记录。USN 记录的字段：

USN：单调递增的 64 位计数器。journal 中的位置。
被改动文件的 MFT 记录号。
改动时该记录的 序列号。
父目录的 MFT 记录号（及其序列号）。
Reason mask：触发此条目的各种操作的按位 OR。完整列表见 Microsoft 的 USN reason codes。最常读到的：
- FILE_CREATE (0x00000100)
- FILE_DELETE (0x00000200)
- DATA_OVERWRITE (0x00000001)
- DATA_EXTEND (0x00000002)
- DATA_TRUNCATION (0x00000004)
- RENAME_OLD_NAME (0x00001000)
- RENAME_NEW_NAME (0x00002000)
- OBJECT_ID_CHANGE (0x00080000)
- REPARSE_POINT_CHANGE (0x00100000)
- STREAM_CHANGE (0x00200000)
- CLOSE (0x80000000)
Source info：指示特殊来源（数据管理、索引、复制）的位掩码。通常为零。
Security ID。
改动时的 文件名。
改动的 时间戳。

CLOSE 是你应该知道的位。多数 USN 条目都置位了它，表示事件被记录时文件句柄已关闭。没有 CLOSE 的条目对应仍处于打开状态的句柄、其改动被刷盘了；之后你可能看到对同一条记录的后续条目带有最终的 CLOSE。这个模式对勒索软件分析很重要：对 .locked 文件的 FILE_CREATE | DATA_EXTEND | CLOSE，与对原件的 FILE_DELETE | CLOSE 配对，就是一次加密在一段 journal 序列中的形态。

它在哪儿

$UsnJrnl 是一份普通的 NTFS 文件，其数据在命名数据流 $J 中。它对应的 MFT 记录在 $Extend 目录下（MFT 记录 11 是 $Extend）。从卷根开始的路径是 \$Extend\$UsnJrnl:$J。还有一个小的 $Max 流，保存 journal 的配置（最大大小、分配增量、第一条有效记录的 USN）。

采集方式与采集 $MFT 的工具一样：

KAPE 的 MFT target 默认包含 $UsnJrnl:$J。
FTK Imager 可通过 [NTFS volume]/$Extend/$UsnJrnl:$J 导出。该文件是稀疏的；不必因"大小"很大而实际内容小得多而吃惊。
在磁盘镜像上，Sleuth Kit：icat -o <分区偏移> image.dd <inode>，inode 是 $UsnJrnl 的 MFT 记录号。fls -p 可以找到该 inode。
mft_dump 与 MFTECmd 都有 $J 解析模式。

它如何补充 `$MFT`

MFT 给你看的是当前状态。USN journal 给你看产生该状态的动词。把两者配对，就能浮现出任一单独都看不到的模式：

磁盘上已不存在但出现在 $UsnJrnl 里的文件。 在两次快照之间被创建并删除，但 journal 保留了记录。MFT 槽位可能已被复用过；USN 条目仍然写着该文件名并指向原始的记录/序列。
一次勒索软件运行中重命名的精确顺序。 OPEN、DATA_OVERWRITE、RENAME_OLD_NAME、RENAME_NEW_NAME、CLOSE。两份快照之间的 MFT diff 告诉你文件移动了；journal 告诉你它移动的顺序。
一份"被修改"的文件是真的被重写，还是只是被触碰过。 DATA_OVERWRITE 表示内容发生了变化。纯元数据变化（ACL 更新、属性设置）显示不同的 reason 标志，并且没有数据相关的标志。
哪一组进程写了哪一份文件。 journal 并不直接记录进程，但与 Sysmon Event ID 11（文件创建）以及 Event ID 23（文件删除）时间戳结合，几乎总能把 journal 条目归属到具体进程。

合并工作流

我合并 MFT 与 USN 数据做时间线的方式：

把 $MFT 解析成扁平的"每条记录一行"的 CSV（MFTECmd、mft_dump -o csv，或浏览器解析器的导出）。
把 $UsnJrnl:$J 解析成扁平的"每个事件一行"的 CSV。
给每一行加一列 source（MFT 与 USN）。
串接并按时间戳排序。
聚焦到与案件匹配的记录（具体记录号、具体文件名、具体父目录）。
把时间线当散文来读：对每个记录号，按顺序列出事件。

单一文件的输出看起来像这样：

2026-05-15T10:23:01.123Z USN  FILE_CREATE | DATA_EXTEND | CLOSE  rec=12345 seq=3 parent=99 name=secret.docx
2026-05-15T10:23:01.123Z MFT  IN_USE=1 SI_created=10:23:01.123Z FN_created=10:23:01.123Z
2026-05-15T10:24:18.456Z USN  DATA_OVERWRITE | CLOSE             rec=12345 seq=3 name=secret.docx
2026-05-15T10:24:18.456Z MFT  SI_modified=10:24:18.456Z
2026-05-16T08:11:02.000Z USN  RENAME_OLD_NAME                    rec=12345 seq=3 name=secret.docx
2026-05-16T08:11:02.000Z USN  RENAME_NEW_NAME | CLOSE            rec=12345 seq=3 name=secret.docx.locked
2026-05-16T08:11:02.001Z USN  FILE_DELETE | CLOSE                rec=12345 seq=3 name=secret.docx.locked

这条序列就是该文件的整个生命。创建、被修改、被重命名（加上 .locked 扩展名）、被删除。五个操作、一份文件、不到 24 小时。

限制与陷阱

journal 会轮转。 多数安装上默认大小为 32 MB，Server SKU 与近期的 Windows 11 构建上可能更大。在繁忙主机上够用几天。新条目进来时旧事件从末尾掉落。事件发生一周后才到达，请预期会有空缺。

journal 可以被删除。 fsutil usn deletejournal /D C: 会整体移除。重新创建后从全新计数器开始。重建会留下痕迹（见 NTFS 反取证），但历史条目没了。

绕回看起来像正常轮转。 你在抓到的 $J 中看到的第一个 USN，只是那一刻 journal 恰好开始的位置。没有"上周这里有什么"的历史。如果想要更长的窗口，请到 VSS 快照中找更早的 $UsnJrnl 副本；每份快照都拥有它在被拍下那一刻自己的 journal 副本。

时间戳与 MFT 时间戳会差几毫秒。 不要过度依赖严格对齐。按秒排序，把 USN reason 码当成决胜。

记录号复用。 一条 USN 条目引用 rec=12345 seq=3。如果当前 MFT 把那条记录显示在序列 4 上，说明槽位之后被复用过。USN 条目仍写着原始文件名；当前 MFT 显示的是继任者。请始终把序列号交叉比对。

驱动 minifilter 可能压制条目。 一些 EDR 与备份软件会压制某些 USN reason 以减少噪声。journal 不会记录这些。如果你对本应高频的某类操作（比如文件访问）看到 USN 数据很稀疏，请查一下装了哪些 minifilter。

简单说一下 `$LogFile`

$LogFile 记录的是事务级别的操作：分配此属性、解除分配彼属性、更新这条索引项。比 USN 更细粒度，但层级更低。它对崩溃前后或元数据密集事件前后那几秒很有用。MFTECmd 能解析它；其它常用工具基本没有。如果 USN journal 被人动过手脚，$LogFile 有时是事件实际发生过程的唯一残存记录。

能立得住的流程

始终成对采集 $MFT、$UsnJrnl:$J、$LogFile，以及它们在 VSS 快照中的副本。
立刻对所有内容做哈希（SHA-256）。
三者都解析。
把 MFT 与 USN 合并成单一时间线。对任何感兴趣的事件前后那几秒，把 $LogFile 叠加上去。
与 Sysmon、安全事件日志、Prefetch、Amcache 交叉比对。
把得出的结论与排除的可能性都写下来。

MFT 加 USN 这对组合，是 NTFS 给你的最接近"完整文件系统活动日志"的东西。请这样对待它。