理解 Windows ShimCache（AppCompatCache）

大多数分析师都是以同样的方式接触到 ShimCache 的：团队中有人说"把 AppCompatCache 拉出来，看看那个二进制是否在里面"，而且这招经常奏效，于是这个工件就获得了它并不完全配得上的声誉。我花在案件评审里争论 ShimCache 行的时间已经足够多了，知道这个工件确实有其价值，但前提是你把它当作它实际所是的东西来对待。它不是执行日志。不是进程审计。它是 Windows 为判断是否需要触发兼容性 shim 而仔细查看过的可执行文件清单。

这就是定位。其余都是机制问题。

缓存实际记录的内容

Application Compatibility Cache（几乎总是简写为 ShimCache 或 AppCompatCache）位于 SYSTEM hive 中，在现代 Windows 上最多保存约 1,024 条条目。每条条目包含可执行文件的完整路径、该文件的 $STANDARD_INFORMATION 最后修改时间，以及（在较旧版本中）一个表明该二进制是否真的被执行过的 flag。在 Windows 10 和 11 上这个 flag 已经被移除。就当它从未存在过。

Windows 在每次启动时都会在内存中重建该缓存，并且仅在 clean shutdown 时才将其写入磁盘。BSOD、硬重置或在虚拟机管理程序级别强制结束 VM，会吞噬掉当时还驻留在易失内存中的所有条目。仅此一点就能解释一半"我在生产环境里见过那个二进制"的故事为何会演变为"但磁盘上的 hive 里什么都没有"的工单。

存放位置

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache

末尾的 AppCompatCache 是一个 value，而不是子键。其内容是一个单独的二进制 blob，其布局在每个主要的 Windows 版本中都发生过变化：XP、7、8、8.1 以及 10/11 系列都使用不同的 schema。离线解析意味着取出 SYSTEM hive（连同它的 SYSTEM.LOG1 和 SYSTEM.LOG2 事务日志），并按正确的版本解码该 blob。本工具在你的浏览器中解析这一个 SYSTEM hive 文件，不上传任何内容。它不会重放日志；如果 hive 是 dirty 的，请先用 Eric Zimmerman 的 rla.exe 把日志重放进去。

调查人员为何会用它

ShimCache 的价值在于它能存活下来。攻击者可以投放一个二进制、运行它、删除它、清空 Prefetch 文件夹，而 ShimCache 仍然保留着完整路径。这让它成为强有力的存在性证据，适用于：

已经从磁盘抹除的恶意软件。
被重命名后用作 living-off-the-land 载荷的系统二进制。
从网络共享上预置、从未真正拉到本地的工具。

将路径数据与 AmCache 的哈希归属结合起来，即使文件早已消失，你仍能转向威胁情报继续追查。

三个常把人绊倒的点

时间戳是文件的 mtime，不是程序运行的时刻。timestomping 会改变缓存所记录的内容。
一条条目并不是执行证据。Win10/11 的缓存根本没有执行 flag。
缓存只在 clean shutdown 时刷新。硬重启会悄无声息地销毁最近的条目。

把每一行都当作一个假设。在报告里写下任何确定性的结论之前，先用 Prefetch、AmCache、EVTX / Sysmon 或 registry hive 来加以佐证。

接下来去哪里

博客的其余部分被组织成两个集合。