TL;DR. El ShimCache vive en memoria. El hive SYSTEM en disco solo contiene entradas volcadas en el último apagado limpio. Para recuperar las entradas de la sesión activa de un host en ejecución o caído, corre windows.shimcachemem de Volatility 3 contra un volcado de RAM, o sácalas en vivo con el artefacto Windows.Registry.AppCompatCache de Velociraptor.
El cache vive en memoria volátil mientras Windows corre. Solo se escribe al hive SYSTEM en apagado limpio. Eso significa que una imagen de memoria suele ser el único sitio donde encontrar entradas del ShimCache de la sesión actual, que son precisamente las entradas más relevantes para un incidente activo. El post de momento de almacenamiento cubre el porqué.
Cuándo la copia en memoria importa más que el disco
Quieres el cache en memoria cuando:
- El host no se ha apagado limpiamente desde el incidente. La mayoría de reinicios forzados, BSOD y cortes de luz dejan el ShimCache en disco obsoleto.
- Sospechas anti-forense. Un atacante que editó el hive en disco puede no haber tocado la copia en memoria, que se reconstruye en cada sesión. Mira detección de anti-forense.
- Necesitas entradas que fueron desalojadas del hive en disco en el último volcado. El tope de 1.024 entradas rota las viejas, pero pueden seguir en memoria bajo condiciones específicas.
Con Volatility 2
El plugin clásico es shimcachemem. Contra una imagen de memoria de XP a Win10:
vol.py -f memory.raw --profile=Win10x64_19041 shimcachemem
Recorre las estructuras AppCompatCache dentro de la representación en memoria del hive SYSTEM e imprime filas (mtime, path) igual que haría un parser offline. El código fuente del plugin está en el repo de Volatility 2.
Con Volatility 3
Volatility 3 lo trae como windows.shimcachemem:
vol -f memory.raw windows.shimcachemem
Ya no hay que seleccionar perfil. Vol 3 averigua el OS automáticamente. Los docs de Volatility 3 documentan el plugin junto al resto del conjunto de artefactos de Windows. Ya que tienes el dump abierto, aprovecha y saca también procesos, conexiones de red y listas de módulos. El parser de RAM cubre el workflow más amplio de memory forensics.
Con Velociraptor
Para recolectar a escala en vez de analizar un único dump, el artefacto Windows.Registry.AppCompatCache de Velociraptor lee el ShimCache en memoria directamente desde un endpoint en ejecución via la vista del registro vivo. Mismo cache que el SO habría volcado al apagar, sin esperar al apagado.
Combinando las dos vistas
En la práctica, a menudo tendrás ambas:
- El cache en memoria de Volatility o Velociraptor.
- El cache en disco del hive SYSTEM en el mismo host.
La copia en memoria es un superset de la copia en disco en cualquier momento en que no haya habido un apagado limpio. Pero la copia en disco puede incluir entradas que ya fueron desalojadas de la memoria tras un uptime largo. Saca ambas, deduplica por (path, mtime) y mete la unión en tu workflow de hunting.
Si las dos vistas discrepan en rutas o timestamps para el mismo slot, es un indicador de manipulación. Mira anti-forense.
Próximos pasos útiles
Una vez que tienes las entradas:
- Usa el Shimcache Parser para triage offline rápido de un hive extraído. Corre en tu navegador, sin subida.
- Mira la referencia del formato binario si estás decodificando el blob crudo tú mismo.
- Mira prueba de ejecución antes de afirmar que una entrada recuperada de memoria significa que un programa corrió.
- Carvea pagefile.sys si sospechas que el cache ha sido borrado parcialmente de memoria y disco; los fragmentos a veces sobreviven en el swap.
Lectura adicional
- Documentación de Volatility 3. framework moderno de memory forensics.
- Volatility Foundation en GitHub. código de plugins incluyendo
shimcachemem. - Velociraptor
Windows.Registry.AppCompatCache. recolección en sistema vivo.