TL;DR. Sí. Una entrada del ShimCache persiste en el registro independientemente de si el archivo sigue existiendo en disco. Borrar el binario no borra su entrada del ShimCache. Por eso justamente el artefacto es tan útil para pillar herramientas que un atacante soltó, usó y borró.
El cache guarda una ruta y una marca de tiempo en un valor del registro. Ese valor no tiene enlace de vuelta al sistema de archivos. Cuando NTFS libera el ejecutable, los datos del registro no se mueven. Que es la razón entera por la que el artefacto vale la pena sacarlo, y la razón entera por la que a veces es la única evidencia que sobrevive a una intrusión.
Respuesta corta: sí, lo hace
El ShimCache guarda una ruta más la mtime $STANDARD_INFORMATION del archivo dentro del valor en HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache. Ese registro no tiene enlace de vuelta al sistema de archivos. Cuando se borra el ejecutable, NTFS libera el archivo. El valor del registro queda intacto. La entrada permanece hasta que la desalojan entradas más nuevas (el cache aguanta hasta ~1.024) o se limpia el valor en sí.
Así que un binario que un atacante soltó en C:\Users\Public\, ejecutó y borró diez minutos después puede dejar una entrada de ShimCache limpia y legible mostrando la ruta completa que ocupó.
Por qué esto es forensicamente potente
Las entradas de archivos borrados suelen ser la única evidencia que sobrevive del tooling del atacante:
- Un
mimikatz.exerenombrado borrado tras un robo de credenciales. - Un archivo de staging eliminado tras la exfiltración.
- Un dropper que se autoeliminó tras instalar una payload.
- Una copia de
7z.exeusada para empaquetar datos antes de la transferencia.
El archivo se ha ido. La ruta del cache te dice que existió, dónde, y (via la marca de tiempo de última modificación) lo enlaza con un build. Esta es la columna vertebral de cazar malware con el ShimCache y de las investigaciones de ransomware, donde los atacantes vacían sus herramientas rutinariamente.
Cruza con la MFT y el USN journal. Si el journal aún lleva la secuencia create-then-delete, tienes un anclaje de timeline limpio. La papelera casi nunca contiene estos (la saltan) pero compruébala igual.
¿Cuánto sobrevive una entrada de archivo borrado?
Se aplican dos límites:
- Desalojo. El cache está acotado a unas 1.024 entradas. En un host ocupado, mucha actividad de ejecutables puede empujar entradas viejas fuera. En un servidor tranquilo puede sobrevivir meses.
- Momento del volcado. Las entradas nuevas solo se persisten en el hive en apagado limpio. Si el host no se ha apagado desde el borrado, la entrada superviviente puede estar solo en memoria. Sácala de un volcado de RAM, mira la guía de extracción de memoria. El modelo de almacenamiento y volcado se cubre en dónde se almacena el ShimCache.
Lo que no prueba
Una entrada de archivo borrado prueba que el archivo existió y fue examinado en ese host. No prueba que el archivo se ejecutó, ni te dice cuándo se borró. La marca de tiempo es la mtime del archivo, no una hora de borrado. Trátalo como un testigo de existencia fuerte y corrobora la ejecución con Prefetch o AmCache. Mira ¿prueba el ShimCache la ejecución?.
Para comprobar qué entradas en un hive apuntan a archivos que ya no existen, parsealo con el Shimcache Parser y cruza las rutas con el sistema de archivos vivo (o una imagen forense). Todo corre localmente en tu navegador.
Lectura adicional
- Caching Out the Val de Mandiant. el argumento del ShimCache como testigo de herramientas borradas.
- Poster SANS DFIR de ejecución de programas. dónde encaja el ShimCache entre la evidencia de ejecución.