¿Pueden los atacantes borrar el ShimCache? Anti-forense y detección

4 min de lectura

TL;DR. Los atacantes luchan contra ShimCache principalmente evitando apagados limpios (para que nunca se vuelque). Las ediciones directas del registro suelen dejar el blob malformado. Detecta manipulación vía cachés anormalmente cortas, binarios siempre-presentes de Windows ausentes, tamaños de entrada malformados, o divergencia memoria/disco.

El ShimCache es más difícil de manipular que la mayoría de los artefactos de Windows, pero no es intocable. Este post recorre lo que los atacantes intentan realmente, por qué la mayoría de intentos dejan huellas y cómo detectar manipulación durante el análisis.

El maletín anti-forense del atacante

1. Reinicio duro antes del volcado. La «anti-forense» más limpia contra el ShimCache es no darle a Windows la oportunidad de escribirlo. Si el atacante fuerza un corte duro (o mata una VM a nivel hypervisor), el ShimCache en memoria de esa sesión simplemente se pierde. La colmena en disco aún guarda lo que se volcó en el anterior apagado limpio. Mira cuándo se escribe el caché para el mecanismo.

2. Edición directa del blob del valor del registro. Un atacante privilegiado puede sobreescribir el valor HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache. En teoría, esto permite quitar entradas específicas — en la práctica, el diseño binario es lo bastante no trivial como para que las malas ediciones suelan dejar el blob malformado.

3. Reemplazo offline de la colmena SYSTEM. Si el atacante puede dejar el sistema offline, puede intercambiar el archivo de la colmena. Es raro en intrusiones oportunistas pero aparece en casos de Estado.

4. Time stomping del binario. Como el ShimCache almacena el mtime $STANDARD_INFORMATION del archivo, un atacante que altere los timestamps del binario antes de que Windows lo examine desplaza la marca temporal cacheada. El ShimCache en sí no miente — los metadatos que capturó ya estaban manipulados.

5. Borrado de AmCache y Prefetch. Atacantes que conocen los artefactos corroborantes los borran también, dejando al ShimCache como testigo solitario y esperando que sea descartado por las razones de nuestro post sobre prueba de ejecución.

Señales de detección

Cuando sospeches manipulación, busca:

  • ShimCache inusualmente corto. Windows llena el caché hasta ~1.024 entradas con uso normal. Un blob con solo unas pocas entradas en un sistema que lleva días corriendo es una fuerte señal de manipulación.
  • Entradas siempre-presentes ausentes. Varios binarios de Windows aparecen de forma fiable en casi todos los ShimCache (según versión: shell, helpers de tareas programadas, herramientas de Windows Update). Su ausencia en una estación usada es sospechosa.
  • Tamaños de entrada malformados. Un blob que falla al parsear a la mitad, con el resto del búfer a cero o lleno de ruido, es indicador clásico de edición tosca. El Shimcache Parser lo emergerá como error explícito.
  • Divergencia memoria / disco. Compara el ShimCache extraído de memoria (guía) con la colmena en disco. Entradas presentes en memoria pero ausentes en disco pueden significar reinicio duro — pero entradas en disco que contradicen la memoria (rutas o mtimes distintos para el mismo slot) sugieren que alguien escribió en la colmena.
  • Desajuste entre AmCache y ShimCache. Si AmCache muestra que un binario se ejecutó pero el ShimCache que debería tener también la entrada está vacío, pregunta por qué. Los borrados de ShimCache que no tocan AmCache son comunes porque los atacantes no siempre se dan cuenta de que AmCache existe.

Qué dice esto a los investigadores

Unas reglas prácticas:

  • Trata un ShimCache vacío o casi-vacío como evidencia, no como ausencia de evidencia. Documéntalo.
  • Saca la imagen de memoria cuando puedas. Frecuentemente atrapa lo que la colmena perdió.
  • Corrobora siempre con AmCache y Prefetch (referencia). Tres artefactos son mucho más difíciles de borrar consistentemente que uno.
  • No afirmes «el atacante borró el ShimCache» sin poder mostrar qué se borró — señala huecos en el conteo de entradas, binarios base ausentes o divergencia memoria/disco.

Lectura adicional

Artículos relacionados