es

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

5 min de lectura

TL;DR. Los atacantes luchan contra el ShimCache sobre todo evitando apagados limpios para que el cache nunca se vuelque. Las ediciones directas del registro suelen dejar el blob malformado. Detecta manipulaciones via caches inusualmente cortos, ausencia de binarios de Windows que siempre están, tamaños de entrada malformados, o divergencia entre memoria y disco.

El cache es más difícil de manipular que la mayoría de los artefactos de Windows. No imposible. Tras unos cuantos incidentes dejas de sorprenderte por lo que los atacantes intentan y empiezas a sorprenderte por las veces que dejan huellas. Este es el catálogo de técnicas que de verdad he visto usar, y lo que cada una deja atrás.

Lo que los atacantes intentan de verdad

1. Reinicio forzado antes del volcado. La anti-forense más limpia contra el cache es no darle nunca a Windows la oportunidad de escribirlo. Fuerza un corte de luz duro o mata la VM en el hipervisor, y el ShimCache en memoria de esa sesión simplemente se pierde. El hive en disco sigue conteniendo lo que se volcó en el apagado limpio anterior. Es con diferencia el patrón más común en compromisos de ransomware. Mira cuándo se escribe el cache para el mecanismo.

2. Ediciones directas al blob del valor. Un atacante con nivel SYSTEM puede sobrescribir HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache. En teoría eso elimina entradas específicas. En la práctica el diseño binario es lo bastante no trivial como para que las ediciones a mano dejen el blob malformado o el conteo de entradas sin sentido.

3. Reemplazo offline del hive. Si el atacante puede bajar el sistema, puede cambiar el hive SYSTEM por completo. Raro fuera del trabajo de estado-nación pero pasa. El registry parser puede mostrarte si los timestamps y la estructura del hive SYSTEM son consistentes con el resto de los artefactos del host.

4. Timestomping del binario. Como el cache guarda la mtime $STANDARD_INFORMATION del archivo, un atacante que hace timestomping del binario antes de que Windows lo examine desplaza el timestamp cacheado. El cache no miente; los metadatos del archivo que capturó ya estaban manipulados. Cruza con el atributo $FILE_NAME de la MFT, que es más difícil de manipular.

5. Borrado de artefactos corroborantes. Los atacantes que aprenden lo que hace el ShimCache también suelen vaciar AmCache, Prefetch, EVTX y la papelera, dejando al ShimCache como único testigo y esperando que se descarte por las razones del post de prueba de ejecución.

Señales de detección

Cuando sospeches manipulación, busca:

  • Cache inusualmente corto. Windows llena el cache hasta unas 1.024 entradas con el uso normal. Un blob con un puñado de entradas en un sistema que lleva días funcionando es una señal fuerte de manipulación.
  • Ausencia de entradas que siempre están. Varios binarios de Windows aparecen de forma fiable en casi cualquier ShimCache, según la versión: componentes de shell, helpers de tareas programadas, herramientas de actualización del SO. Su ausencia en una estación de trabajo que se ha usado es sospechosa.
  • Tamaños de entrada malformados. Un blob que falla al parsear a medias, con el resto del buffer a ceros o relleno de basura, es un indicador clásico de edición torpe. El Shimcache Parser muestra esto como un error explícito.
  • Divergencia entre memoria y disco. Compara el cache extraído de un volcado de RAM con el hive en disco (guía de extracción). Entradas presentes en memoria pero ausentes en disco pueden significar un reinicio forzado. Entradas presentes en disco que contradicen la memoria (distintas rutas o mtimes para el mismo slot) sugieren que alguien escribió en el hive.
  • Discrepancia AmCache y ShimCache. AmCache muestra un binario ejecutado pero el ShimCache está vacío para ese archivo. Pregunta por qué. Los atacantes que vacían ShimCache a menudo olvidan que AmCache existe.
  • Huellas de herramientas anti-forense. Mira en Prefetch, Sysmon Event ID 1 y el USN journal buscando evidencia de reg.exe, PowerShell Remove-ItemProperty o editores de hive de terceros corriendo en la ventana relevante.

Lo que esto le dice a los investigadores

Unas cuantas reglas prácticas que aplico en cada informe:

  • Trata un ShimCache vacío o casi vacío como evidencia. No como ausencia de evidencia. Documéntalo explícitamente.
  • Saca un volcado de RAM cuando puedas. Suele atrapar lo que el hive ha perdido.
  • Corrobora siempre con AmCache y Prefetch. Mira la referencia de artefactos. Tres artefactos son mucho más difíciles de vaciar de forma consistente que uno.
  • No afirmes "el atacante limpió el ShimCache" salvo que puedas mostrar qué se limpió. Apunta a huecos en el conteo de entradas, ausencia de binarios de baseline o divergencia memoria-disco.

Lectura adicional

Artículos relacionados