Investigar un incidente real con Amcache: walkthrough

El host es CORP-FS-04, un servidor de archivos Windows Server 2019. Las operaciones de backup murieron a las 02:14 UTC el martes pasado. El admin de guardia encontró dos recursos compartidos llenos de extensiones .[recovery-id]@onionmail.org.locked y una nota de rescate en cada directorio. EDR estaba desplegado desde hacía dos semanas y todavía no se había configurado para alertar sobre comportamiento de cifrado. La respuesta en vivo arrancó a las 09:00 UTC, cuatro horas después de la detección.

Esto es ficticio, pero está hecho de piezas de casos reales. El punto no es la narrativa del rescate; el punto es qué aportó la Amcache, dónde se ganó su sitio, y dónde tuve que ser honesto sobre lo que no probó.

Qué se recogió#

Triage de KAPE, lanzado desde un share de red, volcó los targets estándar en \\evidence\corp-fs-04\:

  • Amcache.hve, Amcache.hve.LOG1, Amcache.hve.LOG2
  • La carpeta Prefetch
  • Todos los event logs de Windows, incluyendo Microsoft-Windows-Sysmon%4Operational.evtx (Sysmon estaba desplegado desde hacía tres meses, qué suerte)
  • $MFT, $LogFile, $UsnJrnl:$J del journal USN
  • Las hives Software, System, Security y Default user del Registro
  • Snapshots VSS de antes de la ventana de cifrado

La hive Amcache fue el primer artefacto que abrí, porque la pregunta sobre la mesa era "qué herramienta cifró los archivos", y la Amcache es el lugar más barato para buscar ejecutables que pueden haberse borrado tras el cifrado.

Primera pasada: parsear y filtrar#

AmcacheParser:

AmcacheParser.exe -f Amcache.hve --csv .\parsed\ --mp -i

UnassociatedFileEntries.csv tenía 14.802 filas. AssociatedFileEntries.csv, otras 6.991. Veintiún mil filas son demasiadas para leer a ojo.

Reglas de filtrado en el orden que siempre las aplico:

  1. Tirar todo bajo c:\windows\winsxs\, c:\windows\servicing\, c:\program files\microsoft\. Eso es ruido de SO.
  2. Tirar entradas con IsOsComponent = True. Más ruido de SO.
  3. Quedarse con entradas donde LowerCaseLongPath esté en \users\, \programdata\, \windows\temp\, \perflogs\, o cualquier sitio con \appdata\ en la ruta.
  4. Quedarse con entradas donde Publisher esté vacío o sea Unknown. El software firmado con publisher real rara vez es la primera pista.
  5. Ordenar por KeyLastWrite descendente.

Quedaron 47 filas. Manejable.

Las tres entradas que destacaron#

Tres filas del conjunto filtrado eran anómalas.

KeyLastWrite: 2025-05-20 01:47:33 UTC
LowerCaseLongPath: c:\programdata\health-mon\svchealth.exe
OriginalFileName: rundll32.exe
FileId: 00007a3f5b9c8e2d4a6f1b3c5e7d9f1a2b4c6e8d
Publisher: (vacío)
LinkDate: 2015-08-14 03:22:11
BinaryType: pe64_file
Size: 487424

KeyLastWrite: 2025-05-20 01:47:34 UTC
LowerCaseLongPath: c:\programdata\health-mon\nx.exe
OriginalFileName: nx.exe
FileId: 0000d4e2c8a7f3b1e5d9c2a4f6e8b1d3c5a7f9e2
Publisher: (vacío)
LinkDate: 2024-11-03 09:14:22
BinaryType: pe64_file
Size: 2.148.352

KeyLastWrite: 2025-05-20 01:51:12 UTC
LowerCaseLongPath: c:\windows\temp\enc.exe
OriginalFileName: enc.exe
FileId: 0000a1b2c3d4e5f6789012345678901234567890
Publisher: (vacío)
LinkDate: 1970-01-01 00:00:00
BinaryType: pe64_file
Size: 3.891.200

Unas cuantas cosas antes de seguir.

OriginalFileName: rundll32.exe en un archivo en c:\programdata\health-mon\svchealth.exe es el tipo de detalle para el que existe la Amcache. El atacante nombró el archivo para parecer una herramienta de monitoreo, pero el recurso de versión PE sigue diciendo rundll32.exe, lo que significa que alguien empaquetó un binario custom usando el recurso de versión de un binario de Microsoft como punto de partida. Eso por sí solo es interesante.

LinkDate: 1970-01-01 en la tercera entrada es un cantazo. Quien construyó enc.exe o no le importó o puso el timestamp deliberadamente a cero. Ambas son banderas.

Los tres valores de KeyLastWrite están dentro de cuatro minutos uno de otro. O el Compatibility Appraiser corrió una vez en esa ventana y advirtió los tres archivos en un solo escaneo, o se crearon muy cerca en el tiempo y una corrida del Appraiser los recogió juntos. De cualquier modo: los tres están relacionados.

El pivote SHA-1#

Quité el prefijo 0000 de cada FileId y consulté VirusTotal:

  • 7a3f5b9c8e2d4a6f1b3c5e7d9f1a2b4c6e8d (svchealth.exe): 41 / 73 detecciones. Etiquetado como RemoteUtilities por varios vendors. No es malware en sentido estricto; es una herramienta comercial de administración remota que los afiliados de ransomware abusan habitualmente para acceso hands-on-keyboard. El hash coincidió con un build conocido.
  • d4e2c8a7f3b1e5d9c2a4f6e8b1d3c5a7f9e2 (nx.exe): 0 / 73. Desconocido. Sin envío previo.
  • a1b2c3d4e5f6789012345678901234567890 (enc.exe): 64 / 73 detecciones. Varios vendors lo etiquetaron como variantes de la familia Ransom:Win64/Ryuk. El hash coincidió con un envío reciente desde una sandbox en Europa del Este, tres días antes del incidente.

Así que: un RAT comercial, un binario desconocido que merece detonarse, una payload de ransomware conocida. Eso me dice qué estaba probablemente en este host. No me dice que algo se haya ejecutado todavía.

Corroborar ejecución#

La Amcache dice que estos archivos existían. No dice que se ejecutaran. Tengo que ir a otro sitio para eso.

Prefetch primero. Parseado con PECmd.exe:

  • SVCHEALTH.EXE-A1B2C3D4.pf: presente, última corrida 2025-05-20 01:48:02 UTC, run count 7. Definitivamente ejecutado. Varias veces.
  • NX.EXE-E5F6789A.pf: presente, última corrida 2025-05-20 01:55:18 UTC, run count 1. Ejecutado una vez.
  • ENC.EXE-12345678.pf: no presente.

El tercer archivo falta en Prefetch. Dos razones por las que eso puede pasar en un servidor: Prefetch a veces está deshabilitado por defecto en SKUs de Windows Server (en este lo está, comprobé el valor de Registro EnablePrefetcher, puesto a 0), o el archivo corrió menos del umbral de Prefetch (improbable para un encryptor de ransomware en un fileserver). La SKU de servidor lo explica limpiamente.

Así que Prefetch corrobora ejecución para dos de tres. Para el tercero, necesito Sysmon.

Sysmon (EventID 1 ProcessCreate) confirmó:

  • c:\programdata\health-mon\svchealth.exe: spawneado varias veces, padre services.exe (instalado como servicio) y luego cmd.exe. Primero visto 2025-05-20 01:46:51.
  • c:\programdata\health-mon\nx.exe: spawneado 2025-05-20 01:55:14, padre svchealth.exe, línea de comandos incluía -scan 10.0.0.0/24. Ese es el paso de movimiento lateral / reconocimiento.
  • c:\windows\temp\enc.exe: spawneado a las 2025-05-20 02:13:47, padre svchealth.exe, línea de comandos enc.exe -p \\corp-fs-04\fileshare. Esa es la invocación del encryptor. Coincide con el timestamp 02:14 del incidente en el fallo del backup.

Ahora tengo ejecución para los tres, más la cadena padre-hijo, más las líneas de comandos. Sysmon fue el artefacto que cerró esto.

Qué aportó realmente la Amcache#

Vale la pena ser honesto aquí, porque cada artefacto tiene su trabajo y exagerar diluye el informe.

La Amcache aportó:

  1. La lista inicial. Sin la pasada de filtrado de Amcache habría estado nadando en 21.000 entradas sin punto de partida obvio. El filtro de rutas escribibles por usuario lo redujo a 47, las tres entradas sospechosas saltaron.
  2. Los hashes. Sysmon sí incluye hashes de proceso en configuraciones modernas, pero este Sysmon era más antiguo y el campo de hash estaba vacío para enc.exe. El FileId de Amcache me dio el SHA-1 que envié a VirusTotal, que es lo que desbloqueó el pivote de threat intel.
  3. El hash de enc.exe después de su borrado. El encryptor fue borrado de C:\Windows\Temp\ tras terminar el cifrado (el journal USN mostró el file create a las 02:13:47 y el delete a las 02:14:22). A las 09:00 UTC cuando arrancó la recolección, el binario había desaparecido. La fila de Amcache, con su SHA-1, seguía ahí. Esta es la killer feature del artefacto en acción.
  4. El detalle del recurso de versión. OriginalFileName: rundll32.exe en svchealth.exe es el tipo de detalle que no aparece en telemetría EDR y no aparece en Prefetch. La Amcache lo sacó a la luz.

La Amcache no aportó:

  1. Evidencia de ejecución. Prefetch y Sysmon dieron eso.
  2. Las líneas de comandos. Sysmon.
  3. La cadena padre-hijo. Sysmon.
  4. La lista de objetivos de movimiento lateral. Línea de comandos de Sysmon más los eventos 4624/4625 del log de seguridad de hosts vecinos.
  5. El punto de entrada. Todavía bajo investigación en el momento del informe; se sospecha brute force RDP basado en la frecuencia de Security 4625 en el host con cara pública que pivotó a CORP-FS-04.

Si solo tuviera la Amcache, el informe diría "tres binarios sospechosos estaban presentes en el host". No es suficiente. Con Prefetch, USN, MFT, Sysmon y el log de Security, se convierte en "el actor de amenazas desplegó un RAT comercial para persistencia, corrió reconocimiento de red, y ejecutó un encryptor conocido de la familia Ryuk contra el fileshare a las 02:13:47 UTC". La Amcache era load-bearing para la atribución por SHA-1; todo lo demás llevó la narrativa de ejecución.

La frase lista para informe#

La única frase que construí de este trabajo, que es lo que los lectores ejecutivos consumen de verdad:

"A las 02:13:47 UTC del 20 de mayo de 2025, el actor de amenazas ejecutó un binario de ransomware de la familia Ryuk (SHA-1 a1b2c3d4..., recuperado desde la Amcache pese al borrado del archivo tras el cifrado) contra la ruta UNC \\corp-fs-04\fileshare, precedido por el despliegue de una herramienta comercial de acceso remoto (RemoteUtilities, SHA-1 7a3f5b9c...) corriendo como svchealth.exe bajo C:\ProgramData\health-mon\ durante ~27 minutos previos."

Esa frase es defendible. Cada hash, ruta, hora y nombre de herramienta en ella sale al menos de dos artefactos. La Amcache aporta los hashes que sobreviven al borrado; Sysmon aporta la ejecución y las líneas de comandos; Prefetch corrobora dos de tres binarios; el journal USN aporta el timestamp del borrado.

Para esto está la Amcache. No un smoking gun. Un índice de hashes fiable y resistente al borrado que te permite pivotar cuando el resto de la evidencia ha sido destruida activamente.

Lecturas adicionales#

Etiquetasamcachedfirincident-responseransomwarecase-study

Artículos relacionados

← Volver a todos los artículos