Memory Forensics con Volatility 3: Analizando Dumps en Lab Reproducible

La memory forensics es la disciplina de reconstruir la verdad volatil de un sistema comprometido a partir de una imagen de RAM: procesos en ejecucion, sockets abiertos, payloads descifrados y codigo inyectado que nunca toca el disco. Volatility 3 es el estandar de codigo abierto para esto, reescrito por completo en Python 3, usando tablas de simbolos en lugar de perfiles rigidos. En Basilisk analizamos cada dump en un laboratorio reproducible para que un resultado resista en tribunal y en revision por pares. Esta guia va desde la adquisicion de la imagen hasta la deteccion de inyeccion de procesos, con comandos que puedes seguir directamente.

Por que importa la memoria volatil

Casi todo malware moderno existe solo en RAM en algun momento: loaders sin archivo, beacons inyectados en explorer.exe, volumenes LUKS o BitLocker cuyas claves estan en memoria. Quien solo imagina el disco pierde el arbol de procesos, las conexiones de red al C2, el portapapeles, los strings descifrados y los restos de procesos terminados. El orden de volatilidad segun RFC 3227 es claro: registros de CPU y cache primero, luego RAM, luego swap, y solo despues el disco. Por eso la primera accion en un incidente en vivo suele ser una captura limpia de memoria, antes de que alguien apague el sistema o ejecute una limpieza.

Adquirir la imagen de memoria

La adquisicion debe preservar la integridad: huella minima, hashing inmediato, cadena de custodia documentada. En Windows usamos WinPmem o Magnet RAM Capture, en Linux AVML o LiME como modulo de kernel, y en entornos virtualizados el snapshot nativo del hipervisor, que suele ser la via mas limpia. Justo despues del dump calculamos sha256sum imagen.raw y registramos el valor en la bitacora del caso. Una imagen sin hash y sin timestamp es forensemente inutil. Para analisis de Windows tambien es valioso el pagefile.sys correspondiente, porque las paginas paginadas a disco aparecen de otro modo como huecos.

Montar un laboratorio reproducible

La reproducibilidad es el nucleo de la forensia seria. Trabajamos en un contenedor Docker o un venv de Python con una version de Volatility 3 fijada, paquetes de simbolos hasheados y la imagen montada como volumen de solo lectura. Cada analisis parte del mismo requirements.txt para que un colega produzca exactamente el mismo resultado. La imagen original queda intacta; todo el trabajo corre sobre una copia verificada cuyo hash coincide con el original. Registramos cada comando ejecutado con timestamp en un runbook del caso, para que toda la cadena de analisis sea luego reproducible paso a paso.

Volatility 3 y las tablas de simbolos

Volatility 3 abandona los perfiles rigidos de la version 2 y usa en su lugar Intermediate Symbol Files (ISF) generados a partir de los simbolos de depuracion del kernel. Para Windows el framework carga simbolos automaticamente desde el servidor de simbolos de Microsoft usando el GUID del kernel; para Linux y macOS generas el ISF a partir del System.map y los headers del kernel con dwarf2json. La primera corrida siempre es vol -f imagen.raw windows.info para confirmar version del sistema, base del kernel y zona horaria. Si el paquete de simbolos esta mal, todo plugin posterior devuelve basura, por eso este paso nunca se salta.

Analizar procesos: pslist, psscan, pstree

El corazon del analisis es el contexto de proceso. windows.pslist recorre la lista doblemente enlazada de procesos activos tal como la mantiene el kernel. windows.psscan, en cambio, escanea la memoria buscando firmas _EPROCESS y por eso tambien encuentra procesos terminados u ocultos por DKOM que fueron desenlazados de la lista. La diferencia entre ambas salidas es un indicador clasico de rootkit. windows.pstree muestra la jerarquia padre-hijo, donde las anomalias saltan de inmediato: un cmd.exe bajo winword.exe, un powershell.exe bajo outlook.exe o un lsass.exe con padre equivocado son senales de alarma.

Red y handles

Despues de los procesos vienen las conexiones. windows.netscan reconstruye endpoints TCP y UDP con IP destino, puerto, estado y proceso propietario, exponiendo canales C2 activos incluso cuando la conexion fue breve. windows.handles lista los handles abiertos de un proceso a archivos, claves de registro, mutexes y named pipes; un mutex sospechoso suele ser la firma de una familia de malware conocida. windows.dlllist y windows.ldrmodules comparan los modulos cargados: una DLL presente en la imagen de memoria pero ausente de las tres listas de carga sugiere con fuerza carga reflexiva de DLL.

Detectar inyeccion y hollowing

El plugin mas importante para amenazas activas es windows.malfind. Busca regiones de memoria que combinan proteccion PAGE_EXECUTE_READWRITE, ausencia de respaldo en archivo y bytes ejecutables al inicio, que es el patron clasico de inyeccion de shellcode y process hollowing. La salida muestra un hex dump; una cabecera MZ o la firma delatora 4D 5A en una region RWX confirma un PE inyectado. Como complemento, windows.hollowprocesses atrapa el caso en que un proceso legitimo fue iniciado y su memoria reemplazada por codigo ajeno. Cada hallazgo se contrasta con windows.vadinfo para nombrar con exactitud la region VAD afectada.

Extraer artefactos

Una vez confirmado un proceso sospechoso, extraemos evidencia. windows.memmap --pid N --dump guarda toda la memoria direccionable del proceso; windows.dumpfiles --pid N reconstruye archivos cacheados desde memoria. La region inyectada de malfind se puede aislar y pasar a una sandbox o a un desensamblador como Ghidra. Extraemos hives del registro con windows.registry.hivelist y windows.registry.printkey para inspeccionar claves de persistencia bajo Run y Services. Cada archivo extraido se hashea de inmediato y se enlaza a su PID de origen en el runbook del caso.

Errores comunes

El primer error es el paquete de simbolos equivocado, que arroja resultados plausibles pero por completo falsos. El segundo es ignorar la diferencia entre pslist y psscan, dejando procesos ocultos sin detectar. El tercero es trabajar sobre el original en vez de una copia hasheada, lo que destruye la cadena de evidencia. El cuarto es confiar en un solo indicador: un segmento RWX por si solo no es necesariamente malicioso, porque los compiladores JIT tambien crean tales regiones. El quinto es olvidar el pagefile.sys, lo que deja evidencia paginada faltante y el analisis lleno de huecos.

Checklist

Adquiere la imagen con huella minima y hasheala de inmediato con SHA-256. Trabaja en un laboratorio reproducible sobre una copia de solo lectura. Confirma la version del sistema y el paquete de simbolos correcto con windows.info. Tria procesos con pslist, psscan y pstree y anota las diferencias. Revisa la red con netscan, los modulos con dlllist y ldrmodules. Caza inyeccion con malfind y hollowprocesses. Extrae regiones sospechosas con memmap y dumpfiles, hasheales y documentales en el runbook. Respalda cada hallazgo con al menos dos indicadores independientes.

Linea de tiempo y correlacion

Un solo plugin da una instantanea; la historia del incidente emerge solo al correlacionar varias fuentes a lo largo de una linea de tiempo. windows.pstree con timestamps de creacion, combinado con los tiempos de conexion de netscan y los timestamps de windows.registry.userassist, produce una secuencia defendible: cuando arranco el loader, cuando abrio el canal C2, cuando se fijo la persistencia. Exportamos estos artefactos y los fusionamos en una herramienta de super-timeline como Plaso para que los eventos de disco y memoria queden en una unica vista cronologica. Solo entonces puedes separar causa de efecto y nombrar al paciente cero. La alineacion de zona horaria importa: windows.info da el bias, y cada timestamp se normaliza de forma consistente a UTC, de lo contrario fabricas una causalidad aparente que nunca existio. Una linea de tiempo limpia es la columna del informe final y lo primero que revisa un perito.

Memoria Linux y macOS

Windows domina los ejemplos, pero Volatility 3 tambien analiza imagenes Linux y macOS, siempre que exista el ISF correspondiente. Para Linux lo generas con dwarf2json a partir del System.map especifico del kernel y los simbolos de depuracion del kernel exacto en ejecucion, porque hasta una diferencia de patch-level rompe la estructura. Los nombres de plugin reflejan la logica de Windows: linux.pslist y linux.pstree para procesos, linux.bash extrae el historial de comandos directo de la memoria de la shell, y linux.check_syscall y linux.check_modules cazan rootkits de kernel que engancharon la tabla de syscalls. Para contenedores importa que un solo dump del host contiene todos los namespaces; los procesos de distintos contenedores aparecen lado a lado y se separan por su pertenencia a cgroup. macOS requiere un paquete de simbolos generado desde la KDK correspondiente. El principio queda identico: simbolos verificados primero, luego triage sistematico, luego extraccion evidenciada.

FAQ: Puedo analizar un dump de memoria sin un perfil exacto del sistema?

En Volatility 3 ya no hay perfiles elegidos a mano; el framework deriva la estructura de las tablas de simbolos. Para Windows esto ocurre automaticamente via el GUID del kernel y el servidor de simbolos de Microsoft. Para Linux debes generar tu mismo el ISF correspondiente a partir del System.map y los simbolos de depuracion del kernel con dwarf2json, de lo contrario los plugins fallan.

FAQ: Que pasa si malfind no encuentra nada pero la sospecha persiste?

malfind es potente pero no omnisciente: el malware avanzado puede evitar regiones RWX, mapear memoria como imagen o descomprimir codigo solo en tiempo de ejecucion. Complementa entonces el analisis con ldrmodules para DLLs desenlazadas, netscan para rastros de C2 y un escaneo YARA sobre toda la imagen con windows.vadyarascan para acertar firmas conocidas.

Conclusion

Takeaway practico: monta hoy un laboratorio reproducible, adquiere una imagen de una VM de prueba con un beacon conocido y corre toda la cadena desde windows.info hasta malfind hasta ver tu mismo el codigo inyectado. La memory forensics no es magia, es trabajo metodico: adquisicion limpia, simbolos verificados, triage sistematico de procesos, indicadores respaldados por varios y una cadena de evidencia sin romper. Quien hashea y registra cada paso entrega resultados que resisten tanto en un informe de respuesta a incidentes como en un tribunal. Repite el ejercicio con distintas tecnicas de inyeccion hasta que el patron en el hex dump salte a la vista de inmediato.