Qué te dice realmente la Amcache en una investigación DFIR

La mayoría de los artículos sobre Amcache la tratan como un registro limpio de "cada programa que se ejecutó en este host". No lo es. Después de unos cientos de incidentes dejas de confiar en ese marco y empiezas a tratar la hive por lo que realmente es: un efecto secundario ruidoso y asíncrono del Program Compatibility Assistant haciendo su trabajo, que en DFIR resulta muy útil porque sobrevive a desinstalaciones, borrados de archivos y manipulaciones del Registro mucho mejor de lo que la mayoría espera.

Este post es la versión de la conversación que tendría con un analista nuevo de mi equipo. Lo que prueba la hive, lo que no, y los sitios concretos donde he visto descarrilar investigaciones.

Dónde vive la hive y por qué eso ya importa#

C:\Windows\AppCompat\Programs\Amcache.hve en Windows 7 SP1 y posteriores. Es una hive del Registro en el formato regf habitual, lo que significa que cualquier parser capaz de leer NTUSER.DAT puede, en principio, leerla. Lo que la hace interesante forensicamente es que compattelrunner.exe la escribe de forma transparente cada vez que el Program Compatibility Assistant inventaria el sistema, lo cual ocurre por planificación (Microsoft\Windows\Application Experience\Microsoft Compatibility Appraiser) y en ciertos eventos de instalador/desinstalador.

Algunas consecuencias prácticas:

• La hive vive fuera del perfil de usuario, así que es por-máquina, no por-usuario. No puedes atribuir una entrada a una cuenta concreta solo desde la hive.
• La tarea del Appraiser se puede deshabilitar por política de grupo, por ciertos scripts "telemetry remover" y por algunas configuraciones de baseline de EDR. En esos hosts la hive puede llevar semanas obsoleta. He heredado investigaciones donde el equipo de IR había dado por buena la Amcache como pistola humeante antes de comprobar si la tarea estaba corriendo.
• Como es una hive normal, tiene un par de logs de transacción (Amcache.hve.LOG1 / Amcache.hve.LOG2). Recógelos siempre junto al archivo principal. Replayear esos logs recupera entradas que estaban en vuelo en el momento de adquisición y a veces saca registros que nunca llegaron a la hive viva.

Qué prueba realmente una entrada#

La respuesta honesta es: un archivo estaba presente en disco en el momento en que el Appraiser recorrió el filesystem. Nada más.

Aquí empiezan los errores más comunes. La hive no prueba ejecución. Prueba existencia en tiempo de escaneo. Operativamente, esa distinción importa por tres razones:

1. Archivos soltados y borrados entre pasadas del Appraiser no dejan nada. Un operador de red team que sabe lo que hace puede meter y quitar una herramienta dentro de una sola ventana de escaneo. La Amcache nunca lo va a mencionar. Combina la hive con Prefetch y los logs de Sysmon / Security antes de afirmar "no hay evidencia de ejecución".
2. Inventariar un instalador no es ejecutar el payload. Cuando corrió el Setup, el Appraiser indexó todo lo que copió en Program Files. Eso incluye lanzadores de shellcode y herramientas de exfil empaquetadas que nunca se invocaron. La presencia de evil.exe bajo InventoryApplicationFile es interesante, no condenatoria.
3. Los binarios en recursos de red también aparecen. Las rutas UNC se inventarian cuando el Appraiser las ve montadas. Si un usuario hizo doble clic en un archivo de \\fileserver\public\, la entrada puede parecer indistinguible de un binario instalado localmente. Lee la ruta con cuidado.

Lo que la hive sí prueba, y de forma fiable, es que el archivo existió con un hash SHA-1 concreto en un momento concreto. Eso basta para pivotar: contra threat intel, contra VirusTotal, contra otros hosts del parque, aun cuando el archivo en disco haya desaparecido hace tiempo. Es lo más útil que da la Amcache, y la razón por la que siempre cojo la hive lo primero en un host donde sospecho borrado de archivos.

Los timestamps te van a engañar si les dejas#

Hay al menos cinco campos con forma de timestamp repartidos por las claves que te importan, y no todos significan lo mismo. Los nombres no se explican solos, la documentación es escasa, y los valores reflejan eventos distintos según el build de Windows.

Una guía breve de campo que aguanta entre Win7, Win10 y Win11:

• FileId no es un timestamp. Es un hash SHA-1 con prefijo 0000. La gente tropieza con esto en scripts.
• LinkDate (cuando está) es el timestamp de compilación del cabecero PE. Controlable por el atacante. Trátalo como metadato del binario, no como cuándo tocó la máquina.
• El tiempo LastWrite de la clave InventoryApplicationFile\<id> es, en la práctica, el proxy más útil para "el Appraiser advirtió este archivo". No es creación ni ejecución del archivo.
• InstallDate bajo InventoryApplication es lo que el instalador reportó. Los instaladores MSI suelen rellenarlo honestamente. Los instaladores mal empaquetados y muchos droppers de malware no, así que no te apoyes en él para timelines de adversario.
• Construye una super-timeline pivotando por la MFT y el journal USN antes de comprometerte con una narrativa basada solo en timestamps de Amcache. Validar cruzado es barato; estar equivocado en el informe final no.

Los campos que se ganan su sitio#

Después de ProgramId y SHA-1, el campo que más toco es OriginalFileName bajo InventoryApplicationFile. Se saca del recurso de versión del PE y es más difícil de limpiar para atacantes descuidados que LowerCaseLongPath. Lo he usado para atar una svchost.exe renombrada y soltada en \AppData\Local\Temp\ a su identidad real (mimikatz.exe) porque el bloque de recursos nunca se editó.

BinaryType también merece lectura: pe32_file frente a pe64_file frente a xbox_one_pkg_file (sí, en serio). Desajustes entre BinaryType y la ruta pueden ser pista en samples packed o repackaged.

Las claves InventoryApplicationShortcut e InventoryDeviceContainer se pasan por alto con facilidad. La subclave de shortcut registra archivos .lnk que Windows examinó, incluidos los de medios removibles: a veces la única evidencia superviviente de que un usuario abrió un archivo desde una USB que ya salió del edificio. Combínalas con el parser de LNK y el shim cache para la afirmación más fuerte.

Anti-forense: qué pueden y qué no pueden hacer en silencio los atacantes#

La hive es un archivo de Registro normal. Cualquiera con SYSTEM puede escribirlo. En la práctica aparecen tres patrones:

• Borrado total. Amcache.hve está bloqueada mientras Windows corre, así que los atacantes matan compattelrunner y el proceso del Registro antes de borrar, o encolan un Pending File Rename. El borrado es fácil de detectar: el archivo debería estar siempre en un host sano, pero pierdes el contenido histórico. Espera tener un backup reciente o una shadow copy.
• Borrado dirigido de claves. Quitar subclaves concretas bajo InventoryApplicationFile para limpiar un binario particular. Posible, pero: la operación actualiza el LastWrite de la clave padre, y los logs de transacción pueden tener todavía el registro viejo. He recuperado ~30% de entradas "borradas" desde .LOG1/.LOG2 en casos donde el atacante no las limpió también.
• Mascarada de proveedor de confianza. Poner recursos de versión PE en una herramienta soltada para imitar un componente de Microsoft. Esto sobrevive en la Amcache, pero no cambia el SHA-1. La búsqueda por hash gana siempre a la búsqueda por string.

La categoría a la que recurren los atacantes competentes es deshabilitar la tarea del Compatibility Appraiser de entrada. En un host donde la Amcache esté sospechosamente vacía para el periodo de interés, revisa el historial del Task Scheduler en Microsoft-Windows-TaskScheduler%4Operational.evtx antes de asumir que la ausencia de evidencia es evidencia de ausencia.

Un flujo que sobrevive a revisión#

Lo que hago, en orden, en un host donde la Amcache importa:

1. Adquirir Amcache.hve, Amcache.hve.LOG1, Amcache.hve.LOG2 juntos. En sistema vivo, usar snapshot VSS o herramienta que maneje el lock correctamente. No copiar el archivo vivo con xcopy.
2. Replayear los logs. La mayoría de parsers lo hacen automáticamente; verifica comprobando que la hive recuperada abre sin warnings.
3. Sacar SHA-1, OriginalFileName, LowerCaseLongPath y el LastWrite de la clave para cada entrada de InventoryApplicationFile. Ese es el conjunto de trabajo.
4. Filtrar por rutas en directorios escribibles por usuario (\Users\*\AppData\, \Users\Public\, \ProgramData\ fuera de subdirs conocidos de vendor, C:\Windows\Temp\, C:\PerfLogs\). La mayor parte de actividad de adversario aterriza ahí.
5. Pivote por hash de los supervivientes. Cualquier cosa no firmada por un vendor conocido o no conocida por VirusTotal entra en la lista para corroborar en otro sitio.
6. Corroborar. Las afirmaciones más fuertes emparejan una fila de Amcache con un hit en Prefetch, un Sysmon process create o un Security 4688. Cualquier cosa basada solo en la hive lleva la caveat "evidencia de presencia de archivo; ejecución no corroborada".

Esa última viñeta es la que acabo imponiendo en cada informe.

Leer la hive sin salir del navegador#

El parser de este sitio lee Amcache.hve íntegramente en tu navegador, incluyendo replay de logs de transacción. Suelta la hive y devuelve una tabla plana de entradas de InventoryApplicationFile con los campos anteriores, rankeada por LastWrite. Filtra, pivota por hash, exporta. Sin subida, lo que importa cuando la hive viene de un entorno regulado.

Lecturas adicionales#

• Amcache.hve in Windows 8 de Yogesh Khatri, la ingeniería inversa pública original. Sigue siendo la mejor referencia única para el layout de campos.
• AmcacheParser de Eric Zimmerman, herramienta offline de referencia. Su esquema de salida es de facto estándar de la industria.
• MITRE ATT&CK T1070.009 Clear Persistence para el contexto de qué hacen los atacantes bien dotados con hives así.

Si te llevas una cosa: hash primero, ruta segundo, tiempo tercero. La Amcache da su mejor versión cuando la tratas como un índice de hash que de paso sabe qué archivos vio Windows, y la peor cuando tratas los timestamps como verdad de campo.