ShimCache 时间戳实际意味着什么（以及不意味着什么）

TL;DR. ShimCache 时间戳是从文件系统中复制下来的可执行文件 $STANDARD_INFORMATION 最后修改时间。不是它被执行的时间。也不是它被缓存的时间。把它当作文件的一个属性来对待，绝不要当作时间线上的一个事件。

ShimCache 分析中最常见的错误，是把时间戳列读成"它运行的时间"。它不是。我亲眼看到分析师把这种解释呈现给客户和监管者，又亲眼看到任何具备 NTFS 实用知识的人在评审中把那份报告撕得粉碎。不要做那个分析师。

时间戳实际是什么

每条条目存储的是文件的 $STANDARD_INFORMATION 最后修改时间（SI mtime），即 Windows 记录该条目时它在 NTFS 卷上的值。就是一份文件系统属性的直接拷贝。对进程创建、模块加载或关机什么也没说。

三个直接后果：

一个去年构建、今天运行的二进制会显示去年的日期。
一个用保留时间戳的工具复制过的文件保留其原始 mtime，而不是复制时间。
在两台运行同一份签名二进制的主机上会显示相同的时间戳，因为它是文件的属性，而不是哪一台机器的属性。

为什么它不是执行时间

Windows 出于应用兼容性原因检查一个文件时，会向缓存添加一个条目。这经常但并非总是与执行同时发生。即便同时发生，缓存里保存的是文件的 mtime，而不是检查的时刻。因此该时间戳回答的是"该文件最后一次被修改是什么时候？"，永远不回答"它什么时候运行的？"。执行与存在的区别在 ShimCache 是否证明程序被执行过中有深入讨论。

如果你需要真实的执行时间，那你需要 Prefetch 的运行时间、AmCache 的首次运行、Security 4688 或 Sysmon Event ID 1。该缓存给不了你这个。

时间戳仍有价值的时候

作为事件时间它很弱，但作为身份锚点它很强：

篡改检测。 如果像 svchost.exe 这样的系统二进制显示的 mtime 与该主机的补丁级别不匹配，那个文件被替换过。请与更难被 stomp 的 MFT $FILE_NAME 属性交叉验证。
构建关联。 一次行动中编译的恶意软件常常在受害者之间共享相同的 mtime 簇。这有助于把不同事件归属到同一个攻击者。
谨慎用于排序。 在同一台主机内，条目大致按插入顺序保存。在为活动排序时，插入顺序比绝对时间戳更可靠。但顺序不是时间，并且插入序列在重启时重置。

攻击者如何滥用它

由于它只是个文件系统属性，所以伪造起来微不足道。Timestomping（把 mtime 设为 2009-07-14，即经典的 kernel32.dll 日期）会让 dropper 与 Windows 系统文件混在一起。缓存会忠实记录被 stomp 的值，因此 C:\Users\Public\ 中某条路径上一个干净的 2009 年时间戳本身就是危险信号。反取证模式在攻击者能清除 ShimCache 吗中有整理。

MFT 的 $FILE_NAME 属性通常即便在 $STANDARD_INFORMATION 被 stomp 之后也保留真实的创建时间。MFT parser 会带你完成对比。USN journal 在大多数情况下也能捕获原始的创建事件。

在时间线中正确使用它

把 ShimCache 的 mtime 放在与事件时间不同的列里。绝不要把它当成一个动作合并到主时间线中。用确实带有事件时间的工件来佐证排序：Prefetch 的运行时间、AmCache 的安装 / 首次运行、Security 4688、Sysmon Event ID 1。完整的交叉参照见 Prefetch、AmCache、ShimCache：快速参考。

要亲自查看原始值，把一份 SYSTEM hive 拖入 Shimcache Parser。它会在浏览器中显示每条条目的精确存储 mtime，不上传任何东西。