TL;DR. 攻击者对抗 ShimCache 主要靠避免干净关机（让它永远不落盘）。直接编辑注册表通常会破坏 blob 的格式。可通过异常短的缓存、缺失的常驻 Windows 二进制、异常的条目大小，或内存与磁盘之间的不一致来识别篡改。
ShimCache 比大多数 Windows 工件更难篡改，但并非无懈可击。本文梳理攻击者实际会尝试什么、为什么大多数尝试都会留下指纹，以及分析时如何识别篡改。
攻击者常用的反取证手段
1. 在刷盘前硬重启。 对 ShimCache 而言，最「干净」的反取证手段就是不给 Windows 写入它的机会。攻击者强制断电（或在 hypervisor 层杀掉虚拟机）后，当前会话的内存中 ShimCache 直接丢失。磁盘上的配置单元仍保留 上一次 干净关机时刷下的内容。机制见 何时写入缓存。
2. 直接编辑注册表中的值 blob。 具有特权的攻击者可以覆写 HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache。理论上可移除特定条目 —— 但 二进制布局 足够复杂，糟糕的编辑通常会留下畸形的 blob。
3. 离线替换 SYSTEM 配置单元。 如果攻击者能让系统离线，便可替换配置单元文件。在机会性入侵中很少见，国家级攻击中偶有出现。
4. 篡改二进制的时间戳。 由于 ShimCache 保存的是文件的 $STANDARD_INFORMATION mtime，若攻击者在 Windows 检查之前修改了文件时间戳，缓存中的时间戳也会跟着偏移。ShimCache 本身没说谎 —— 它捕获的元数据本就已被篡改。
5. 抹除 AmCache 与 Prefetch。 了解佐证工件的攻击者通常也会一并抹除它们，留下 ShimCache 作为孤证，并指望它因 执行证明一文 所述原因被弃用。
检测迹象
怀疑篡改时，请查找：
- ShimCache 异常短。 正常使用下 Windows 会把缓存填到约 1,024 条。运行多日的系统上 blob 只有寥寥数条，是篡改的有力信号。
- 常驻条目缺失。 多数 ShimCache 中可靠出现的若干 Windows 二进制（按版本：shell、计划任务助手、Windows Update 工具）。一台被使用的工作站上它们缺席，相当可疑。
- 条目大小畸形。 解析中途失败、剩余 buffer 被清零或填以噪声的 blob，是粗劣编辑的经典指标。Shimcache Parser 会以明确错误提示。
- 内存与磁盘的分歧。 把从内存提取的 ShimCache（指南）与磁盘上的配置单元比较。内存里有而磁盘没有的条目可能意味着硬重启 —— 但磁盘上的条目与内存对应位置不一致（同一槽位的路径或 mtime 不同），则意味着有人写入了配置单元。
- AmCache 与 ShimCache 不一致。 当 AmCache 显示某二进制执行过，但本应承载该条目的 ShimCache 却为空时，要问为什么。攻击者并非总是意识到 AmCache 的存在，所以「只擦 ShimCache 不擦 AmCache」的情形很常见。
这意味着什么
几条实操规则：
- 把空的或近乎空的 ShimCache 当作证据，而非「无证据」。一定要记录。
- 能拿就拿内存镜像。 它常常补回配置单元失去的内容。
- 始终用 AmCache 与 Prefetch 印证（参考）。三件证据要被一致地擦除，远比擦一件要难。
- 断言「攻击者抹掉了 ShimCache」时，必须能展示 什么 被抹掉。 用条目数量的空缺、缺失的基线二进制、内存/磁盘的不一致来佐证。
延伸阅读
- Velociraptor 的
Windows.Registry.AppCompatCache—— 规模化采集以发现异常。 - Windows 10/11 AppCompatCache deep dive (Ø Security) —— 理解被篡改的 blob 必须造假哪些字段。
- ShimCache & AmCache forensic analysis (Mehrnoush) —— 含篡改情景的案例研究。