ShimCache 时间戳到底意味着什么（以及不意味着什么）

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

ShimCache 分析中最常见的错误，就是把时间戳列读成「这是它运行的时间」。并不是。这种误读已经把错误的时间写进了真实的事件报告。本文精确说明该值究竟是什么，以及如何使用它而不得出错误结论。

时间戳的真实身份

每个 ShimCache 条目存储的是 Windows 记录该条目时、NTFS 卷上可执行文件的最后修改时间（$STANDARD_INFORMATION 的 mtime）。它是文件系统属性的直接拷贝，对进程创建、模块加载或关机一概不说明。

由此立刻产生三个后果：

去年编译、今天运行的二进制文件显示的是去年的日期。
用保留时间戳的工具复制的文件保留其原始 mtime，而非复制时间。
运行同一个已签名二进制的两台主机会显示相同的时间戳——因为这是文件的属性，不是机器的属性。

为什么它不是执行时间

Windows 在出于应用兼容性原因检查文件时添加 ShimCache 条目——这往往（但并非总是）与执行同时发生。即便同时发生，缓存存储的也是文件的 mtime，而非检查的那一刻。因此时间戳回答的是「这个文件最后一次被修改是什么时候？」，而绝不是「它什么时候运行的？」。执行与存在的区别在ShimCache 能否证明程序被执行过？中有深入讨论。

时间戳何时仍然有价值

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

篡改检测。 如果像 svchost.exe 这样的系统二进制显示的 mtime 与主机补丁级别不符，那么该文件被替换过。
构建关联。 在一次行动中编译的恶意软件常常在受害者之间共享一个 mtime 簇——便于归组。
排序，需谨慎。 在同一台主机内，条目按大致的插入顺序存储。对活动排序而言，顺序比绝对时间戳更可靠。

攻击者如何滥用它

由于它只是文件系统属性，伪造极其容易。时间戳篡改（例如把 mtime 设为 kernel32.dll 的经典日期 2009-07-14）能让投放器混入 Windows 系统文件。ShimCache 会忠实记录被篡改的值——所以 C:\Users\Public\ 下某路径上一个「干净的」2009 年时间戳本身就是危险信号。反取证手法已在攻击者能清除 ShimCache 吗？中归类整理。

在时间线中正确使用

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

想自己查看原始值，把 SYSTEM 蜂巢拖进 Shimcache Parser——它在你的浏览器中显示每个条目精确存储的 mtime，不上传任何内容。