TL;DR. ShimCache vive en HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache. Windows lo reconstruye en memoria cada sesión y solo lo vuelca a la colmena SYSTEM al apagado limpio — un reinicio forzado puede tirar las entradas recientes por completo. No olvides reproducir SYSTEM.LOG1 / SYSTEM.LOG2.
Muchos tropiezos con el ShimCache vienen de un único malentendido: los investigadores asumen que el caché se actualiza como un archivo de log, con entradas volcadas a disco a medida que suceden. No es así. Aquí explicamos exactamente dónde vive el ShimCache y cuándo escribe Windows en él.
La ruta en el registro
El ShimCache vive dentro de la colmena SYSTEM, en:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache
Ese último AppCompatCache es un valor, no una subclave. Su dato es un único blob binario cuyo esquema varía según la versión de Windows — XP, 7, 8, 8.1, 10 y 11 usan cada uno un diseño ligeramente distinto. El recorrido del formato binario cubre el esquema moderno de Windows 10/11 al detalle.
Puedes leer ese mismo valor offline extrayendo la colmena SYSTEM — es uno de los archivos bajo C:\Windows\System32\config\ — y apuntando un parser hacia ella. El Shimcache Parser hace exactamente eso, en tu navegador, sin subir el archivo a ningún sitio.
El truco del ControlSet «actual»
Windows mantiene en realidad varios ControlSets (ControlSet001, ControlSet002, a veces más). En cada momento, exactamente uno es el conjunto activo, indicado por el valor HKLM\SYSTEM\Select\Current. CurrentControlSet es un alias en ejecución hacia el que esté activo.
Al analizar offline deberías:
- leer
HKLM\SYSTEM\Select\Current(un DWORD, normalmente 1 o 2), - recorrer el valor
ControlSetXXX\Control\Session Manager\AppCompatCache\AppCompatCachecorrespondiente, - caer en
ControlSet001yControlSet002siSelect\Currentno es legible.
La mayoría de parsers — incluida esta herramienta — lo hacen automáticamente.
Cuándo se escribe el caché
Aquí va la parte que sorprende: mientras el sistema está corriendo, el ShimCache vive en memoria. Windows solo lo vuelca a la colmena SYSTEM en un apagado limpio. Por tanto:
- Un reinicio forzado, corte de luz, BSOD o kill de VM a nivel hipervisor descartará cualquier entrada reciente que no se haya persistido todavía.
- Un triaje en caliente de un sistema en marcha con
reg.exeo RegRipper ve el ShimCache previamente persistido, no el que se está construyendo en memoria. - El análisis de memoria (p. ej. el plugin Volatility
shimcachemem) puede recuperar el caché actual en memoria antes de que se pierda.
Ese timing es la razón por la que el análisis dead-box de una colmena suele pasar por alto la actividad más reciente, y por la que los investigadores recurren a AmCache (que escribe continuamente — ver ShimCache vs AmCache) para cubrir ese hueco.
¿Y el log de transacciones del registro?
La colmena SYSTEM va acompañada de archivos de log de transacciones (SYSTEM.LOG1, SYSTEM.LOG2). Pueden contener escrituras sin volcar que nunca llegaron a la colmena principal. Los parsers offline robustos los replican antes de leer el ShimCache; si haces tu propio análisis, ten esto en cuenta o usa un parser que lo haga.
Check-list rápida
- Valor ShimCache:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache - ControlSet activo seleccionado por
HKLM\SYSTEM\Select\Current - Almacenado en memoria, volcado solo en apagado limpio — corrobora con AmCache para la actividad reciente
- Replica los logs
SYSTEM.LOG*antes de analizar para una imagen actualizada
Lectura adicional
- Microsoft Learn — Registry hives — referencia canónica sobre archivos de colmena y ControlSets.
- ShimCacheParser de Mandiant — parser Python original, útil como referencia de formato.
- Velociraptor
Windows.Registry.AppCompatCache— lógica de recolección en sistemas en vivo.