Adquirir Amcache.hve en sistemas vivos y apagados

La forma más rápida de arruinar una investigación de Amcache es adquirir la hive mal. He heredado casos donde el colector tomó Amcache.hve con xcopy, se saltó el par .LOG1 / .LOG2 y le entregó al analista una hive que se abre con advertencias y a la que le falta la semana más reciente de inventario. La hive estaba ahí. El método de adquisición la tiró a la basura.

Este post es la versión de "cómo capturar el archivo correctamente" que me hubiera gustado ver en todos los runbooks de IR.

El archivo está bloqueado, y ese es todo el problema#

C:\Windows\AppCompat\Programs\Amcache.hve lo abre el kernel como hive. El handle se mantiene abierto mientras Windows está corriendo. En un host vivo:

  • Un CopyFile normal en user-mode contra la ruta viva falla con sharing violation.
  • xcopy / robocopy contra la ruta viva fallan del mismo modo o, peor, producen silenciosamente un archivo de cero bytes en algunos builds de Windows cuando se ejecutan desde una shell privilegiada con ciertos switches.
  • reg save HKLM\... Amcache.hve no funciona porque Amcache es una hive independiente, no montada bajo HKLM por defecto. Puedes cargarla con reg load HKLM\Amcache C:\Windows\AppCompat\Programs\Amcache.hve solo si no la tiene abierta otro proceso, cosa que en un sistema vivo sí ocurre.

Hay cuatro formas legítimas de leer el archivo: snapshotear el volumen y leer del snapshot, usar un lector NTFS raw que se salta el lock, usar una herramienta que sabe manejar específicamente la hive, o apagar el host e imagear el disco.

Las tres primeras aplican en un host vivo. La cuarta, cuando el host ya está apagado.

Adquisición en vivo que realmente funciona#

Volume Shadow Copy#

El método más aburrido y a la vez el más fiable. Crear un shadow copy, montarlo, copiar el archivo fuera.

vssadmin create shadow /for=C:

vssadmin devuelve la ruta del shadow, normalmente algo como \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1. No puedes hacer cd a esa ruta porque la normalización de rutas Win32 la odia. El truco es crear un enlace simbólico o usar una herramienta que consume rutas raw directamente. mklink /D C:\shadow \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\ y luego copy C:\shadow\Windows\AppCompat\Programs\Amcache.hve* C:\out\ funciona.

Dos notas prácticas. Asegúrate de incluir el wildcard para llevarte Amcache.hve, Amcache.hve.LOG1 y Amcache.hve.LOG2. Y limpia el shadow copy cuando termines salvo que tengas razón para conservarlo; los shadow copies abandonados son cómo una workstation se queda sin disco en el peor momento posible.

Velociraptor#

Si tienes Velociraptor desplegado (y en la mayoría de engagements IR empresariales así debería ser), esto es de una línea:

SELECT * FROM Artifact.Windows.Forensics.Amcache()

El artefacto gestiona el bloqueo leyendo a través del acceso NTFS raw de ntfs.sys, reproduce los logs de transacción y devuelve filas parseadas. Si prefieres la hive cruda en vez de la salida parseada, Windows.KapeFiles.Targets con _AmcacheHive como target te da el archivo y los logs en un zip.

Para barridos sobre muchos hosts, ese es el flujo. Cazar por el parque, traerse cada hive, post-procesar centralmente.

KAPE#

KAPE de Eric Zimmerman maneja el target Amcache de serie. kape.exe --tsource C: --target Amcache --tdest .\out\ recoge la hive más los logs, usando su lector NTFS raw integrado. Hace lo correcto con los locks.

KAPE también es la herramienta correcta cuando necesitas recoger Amcache junto a todo lo demás para un paquete de triage. El target BasicCollection más los módulos dirigidos te dan Amcache, Prefetch, MFT, Event Logs, USN journal, hives del Registro y el resto del kit estándar en una sola pasada.

FTK Imager#

Si solo tienes FTK Imager (porque el responder está en sitio con una llave USB y nada más), funciona. Add Evidence Item > Physical Drive > navegar a \Windows\AppCompat\Programs\ > clic derecho > Export Files. FTK Imager usa lecturas de disco raw, así que el lock es irrelevante.

Este es el método al que vuelvo cuando estoy sentado delante del portátil de un directivo con poco tiempo y poca libertad de despliegue.

reg save con un reg load previo#

Lo menciono porque la gente lo intenta. No funciona sobre la hive viva porque la hive ya está abierta. Sí puede funcionar sobre una copia extraída: sacas la hive con uno de los métodos anteriores, la cargas localmente con reg load HKLM\AmcacheTemp C:\path\to\Amcache.hve, consultas y luego reg unload. Eso es para análisis, no para adquisición.

El problema LOG1 / LOG2#

Amcache.hve.LOG1 y Amcache.hve.LOG2 son los logs de transacción de páginas sucias que el kernel escribe para mantener la hive consistente. Son críticos por dos razones.

Primero, si la hive estaba siendo escrita cuando la capturaste, el archivo principal queda inconsistente y los logs contienen las páginas que faltan. Sin ellos, los parsers se negarán a abrir la hive o la abrirán con datos viejos. Revisa siempre la salida del parser buscando mensajes de "log replay" o advertencias "primary sequence != secondary".

Segundo, subclaves borradas recientemente suelen seguir existiendo como celdas no eliminadas en las páginas del log. He recuperado entradas de .LOG1 que un atacante había purgado de la hive principal minutos antes de la adquisición. Si solo te llevas el .hve, tiras esa recuperación a la basura.

La regla es: nunca recojas la hive sin los logs. Haz match con wildcard Amcache.hve* en toda recolección. Velociraptor y KAPE lo hacen automáticamente; los copy ad hoc no, salvo que los obligues.

Otro modo de fallo aparte: recoger los logs pero no replayarlos. Algunos parsers los replayean automáticamente (AmcacheParser, yarp), otros no (builds antiguos de RegRipper). Si no estás seguro, comprueba abriendo la hive recuperada en dos parsers y comparando filas. Una diferencia significativa quiere decir que uno de ellos no replayeó.

Adquisición en disco apagado#

Cuando tienes una imagen de disco (E01, raw, VHDX) o una unidad apagada:

  • Monta la imagen en solo lectura con FTK Imager, Arsenal Image Mounter o losetup más ntfs-3g en Linux.
  • Navega a \Windows\AppCompat\Programs\ en el sistema de archivos montado.
  • Copia Amcache.hve, Amcache.hve.LOG1, Amcache.hve.LOG2 a la máquina de análisis.
  • Parsea normalmente.

No hay problemas de bloqueo en una imagen muerta. Lo único a vigilar son los volume shadow copies de la imagen, que pueden contener hives Amcache más antiguas. Si la hive viva ha sido manipulada, una copia más antigua desde \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN\Windows\AppCompat\Programs\Amcache.hve puede llevar las entradas que el atacante eliminó. Herramientas como vshadowmount (libvshadow) en Linux o ShadowExplorer en Windows exponen esos snapshots de forma limpia.

Recupero filas históricas de Amcache desde shadow copies aproximadamente en uno de cada cinco casos donde la hive en disco muestra señales de poda.

Cómo se ven los scripts IR buenos#

Un script de recolección IR para Amcache que funciona, en pseudocódigo aproximado:

  1. Crear un snapshot VSS de C: (o usar lecturas NTFS raw directamente).
  2. Leer Amcache.hve, Amcache.hve.LOG1, Amcache.hve.LOG2 desde la ruta del snapshot.
  3. Calcular SHA-256 de cada archivo adquirido. Anotar en el registro de cadena de custodia.
  4. Comprimir los tres archivos juntos con un nombre con timestamp (<hostname>_<UTC-timestamp>_amcache.zip).
  5. Eliminar el snapshot.
  6. Enviar al almacenamiento central.

Si tu script no hace los seis pasos, arréglalo. En concreto: si no hashea los archivos adquiridos, no tienes historia de integridad. Si no recoge los logs, te faltan datos. Si deja snapshots atrás, antes o después tirarás un host en producción.

El artefacto Windows.KapeFiles.Targets de Velociraptor hace todo esto y más. Si estás escribiendo el tuyo propio desde cero, pregúntate por qué.

Trampas de xcopy y otros métodos ad hoc#

xcopy "C:\Windows\AppCompat\Programs\Amcache.hve" "C:\out\" en un host vivo fallará con sharing violation en la mayoría de casos. Algunos builds de Windows, con ciertas combinaciones de privilegios, producirán en cambio un archivo de cero bytes. Cualquiera de los dos modos de fallo grita si lo compruebas; ambos son silenciosos si no.

copy tiene el mismo problema. robocopy /B (modo backup) a veces funciona sobre la hive viva porque las aperturas en modo backup usan SeBackupPrivilege, pero los resultados son inconsistentes entre builds de Windows y no me fío. El Copy-Item de PowerShell es solo CopyFile por debajo.

certutil -urlcache -split no es relevante aquí, no, pero he visto a gente intentarlo.

Las únicas reglas fiables: snapshotear el volumen, usar una herramienta con acceso NTFS raw, o apagar el host. Cualquier otra cosa es suerte.

Verificar la adquisición#

Antes de marcharte de un host, verifica que el archivo que recogiste es parseable.

  • Abre con yarp-print (la CLI de Maxim Suhanov). Avisará de mismatches de secuencia y logs sin replayar.
  • Pasa AmcacheParser contra los archivos recogidos. Confirma que las filas bajo InventoryApplicationFile no son cero.
  • Comprueba al azar que el KeyLastWrite más reciente está cerca de "ahora" (dentro del ritmo de escaneo del Appraiser, típicamente horas). Si la entrada más reciente tiene días en un host que supuestamente operaba normal, puede que la tarea del Appraiser esté deshabilitada, la hive haya sido podada o tu ruta de adquisición fuera incorrecta.

Si algo huele mal, re-recoge antes de que el host cambie de estado. La verificación sobre el terreno te ahorra un vuelo de vuelta largo.

Lecturas adicionales#

Etiquetasamcachedfiracquisitionvelociraptorkape

Artículos relacionados

← Volver a todos los artículos