TL;DR. ShimCache 驻留在内存中。磁盘上的 SYSTEM hive 仅包含上一次 clean shutdown 时被刷新的条目。要从仍在运行或已崩溃的主机上恢复当前会话的条目，请对一份 RAM dump 运行 Volatility 3 的 windows.shimcachemem，或者用 Velociraptor 的 Windows.Registry.AppCompatCache 工件实时拉取。

Windows 运行期间，缓存驻留在易失内存中。仅在 clean shutdown 时才被写入 SYSTEM hive。这意味着内存映像往往是查找当前会话 ShimCache 条目的唯一地方，而这些条目正是对一个活动事件最可能至关重要的条目。存储时机文章解释了原因。

内存副本比磁盘更重要的时刻

在以下情况你会想要内存中的缓存：

自事件以来主机未进行过 clean shutdown。大多数硬重启、BSOD 和强制断电都会让磁盘上的 ShimCache 过时。
你怀疑有反取证。一个编辑了磁盘 hive 的攻击者可能没有动过内存副本，它每个会话都会被重建。见反取证检测。
你需要在上一次 flush 时已被磁盘 hive 驱逐的条目。1,024 条上限会让旧条目轮换出局，但在特定条件下它们仍可能在内存中。

用 Volatility 2

经典插件是 shimcachemem。针对 XP 到 Win10 的内存映像：

vol.py -f memory.raw --profile=Win10x64_19041 shimcachemem

它会遍历 SYSTEM hive 在内存中的表示里的 AppCompatCache 结构，并以与离线 parser 相同的方式打印 (mtime, path) 行。插件源码位于 Volatility 2 仓库。

用 Volatility 3

Volatility 3 以 windows.shimcachemem 形式提供：

vol -f memory.raw windows.shimcachemem

不再需要选择 profile。Vol 3 会自动识别 OS。Volatility 3 文档把该插件与其他 Windows 工件集一并记录。既然 dump 已经打开了，你不妨同时拉取进程、网络连接和模块列表。RAM parser 介绍了更广泛的内存取证工作流。

用 Velociraptor

如果是要规模化采集而不是分析单一 dump，Velociraptor 的 Windows.Registry.AppCompatCache 工件会通过活体注册表视图，直接从运行中的端点读取内存中的 ShimCache。这与 OS 在关机时会刷新的是同一份缓存，但无需等待关机。

把两种视图结合起来

实际中你往往会两者都拥有：

来自 Volatility 或 Velociraptor 的内存缓存。
同一主机 SYSTEM hive 的磁盘缓存。

在没有发生过 clean shutdown 的任何时刻，内存副本是磁盘副本的超集。但在长时间运行后，磁盘副本里可能包含一些已经被驱逐出内存的条目。把两者都取下来，按 (path, mtime) 去重，把并集喂入你的狩猎工作流。

如果两种视图在同一个槽位上对路径或时间戳的看法不一致，那就是一个篡改指标。见反取证。

有用的后续步骤

一旦你拿到条目：

用 Shimcache Parser 对提取出的 hive 做快速离线分诊。在浏览器内运行，不上传。
如果你要亲自解码原始 blob，请参阅二进制格式参考。
在声称内存恢复出来的条目意味着程序运行过之前，请参阅执行证明。
如果怀疑缓存已经从内存和磁盘上都被部分擦除，可对 pagefile.sys 进行 carving；碎片有时会在 swap 中存活。

从内存转储中提取 ShimCache