TL;DR. La marca de tiempo del ShimCache es la fecha de última modificación $STANDARD_INFORMATION del ejecutable, copiada del sistema de archivos — no la hora de ejecución ni la de cacheo. Es una propiedad del archivo, nunca un evento en una línea de tiempo.
El error más común en el análisis de ShimCache es leer la columna de marca de tiempo como «cuándo se ejecutó». No lo es. Esa confusión ya ha puesto horas falsas en informes de incidentes reales. Este artículo explica con precisión qué es ese valor y cómo usarlo sin sacar una conclusión equivocada.
Qué es realmente la marca de tiempo
Cada entrada ShimCache almacena la fecha de última modificación (mtime de $STANDARD_INFORMATION) del ejecutable, tal como estaba en el volumen NTFS en el momento en que Windows registró la entrada. Es una copia directa de un atributo del sistema de archivos. No dice nada sobre la creación del proceso, la carga del módulo o el apagado.
Tres consecuencias inmediatas:
- Un binario compilado el año pasado y ejecutado hoy muestra la fecha del año pasado.
- Un archivo copiado con una herramienta que preserva marcas de tiempo conserva su mtime original, no la hora de copia.
- Dos equipos que ejecutan el mismo binario firmado mostrarán la misma marca de tiempo — porque es una propiedad del archivo, no de la máquina.
Por qué no es la hora de ejecución
Windows añade una entrada ShimCache cuando examina un archivo por razones de compatibilidad de aplicaciones — lo que a menudo, pero no siempre, coincide con la ejecución. Incluso cuando coincide, el caché almacena el mtime del archivo, no el instante del examen. Así, la marca de tiempo responde a «¿cuándo se modificó por última vez este archivo?» y nunca a «¿cuándo se ejecutó?». La distinción ejecución/existencia se trata a fondo en ¿Demuestra el ShimCache que un programa se ejecutó?.
Cuándo sigue siendo valiosa
Débil como hora de evento, es fuerte como ancla de identidad:
- Detección de manipulación. Si un binario del sistema como
svchost.exemuestra un mtime que no concuerda con el nivel de parches del equipo, ese archivo fue reemplazado. - Correlación de compilación. El malware compilado en una campaña suele compartir un grupo de mtime entre víctimas — útil para agrupar.
- Ordenación, con cuidado. Dentro de un mismo equipo, las entradas se almacenan en un orden de inserción aproximado. El orden es más fiable que las marcas absolutas para secuenciar la actividad.
Cómo abusan de ella los atacantes
Como es solo un atributo del sistema de archivos, es trivialmente falsificable. El timestomping (por ejemplo, fijar un mtime en 2009-07-14, la fecha clásica de kernel32.dll) hace que un dropper se camufle entre los archivos del sistema. El ShimCache registra fielmente el valor manipulado — así que una marca «limpia» de 2009 en una ruta dentro de C:\Users\Public\ es en sí misma una señal de alarma. Los patrones antiforenses están catalogados en ¿Pueden los atacantes borrar el ShimCache?.
Usarla correctamente en una línea de tiempo
Coloca el mtime del ShimCache en una columna separada de las horas de evento — nunca lo fusiones en la línea de tiempo principal como si fuera una acción. Corrobora la secuencia con artefactos que sí llevan horas de evento: horas de ejecución de Prefetch, instalación/primer arranque de AmCache, Security 4688, Sysmon 1. La referencia cruzada completa está en Prefetch, AmCache, ShimCache: referencia rápida.
Para inspeccionar tú mismo los valores en crudo, suelta una colmena SYSTEM en el Shimcache Parser — muestra el mtime almacenado exacto por entrada, en tu navegador, sin subir nada.
Lectura adicional
- Mandiant: leveraging the ShimCache — el estudio original que definió el uso forense del artefacto.
- AppCompatCacheParser de Eric Zimmerman — parser de referencia cuya salida usa la misma semántica de mtime.