Que es Memory Forensics y Por Que es Esencial en DFIR

La evidencia que desaparece al pulsar el boton de apagado

TL;DR: El memory forensics es la disciplina de capturar y analizar la memoria RAM para hallar rastros de ataques que no existen en el disco duro. A diferencia de las auditorías de archivos, la memoria es volátil y toda su información se borra inmediatamente al pulsar el botón de apagado. Por ello, es una práctica esencial en DFIR para descubrir malware avanzado y procesos ocultos antes de que la evidencia desaparezca para siempre.

Imagina un escenario frecuente en respuesta a incidentes. Tu SOC detecta tráfico anomalo hacia una IP externa desde un servidor critico. El EDR no muestra ficheros maliciosos en disco. Los logs del sistema parecen limpios. El antivirus no ha saltado. Y sin embargo, algo esta exfiltrando datos. La respuesta a este misterio casi siempre esta en la memoria RAM.

La memoria volatil es el escenario donde el malware vive, respira y opera. Cada proceso en ejecución, cada conexión de red activa, cada credencial introducida por un usuario, cada clave de cifrado usada por ransomware: todo existe en RAM mientras el sistema funciona. Y todo desaparece cuando apagas el equipo.

El análisis forense de memoria (memory forensics) es la disciplina que permite capturar, preservar y analizar ese contenido volatil antes de que se pierda. Para un analista DFIR, es la diferencia entre reconstruir un incidente completo y trabajar con un puzzle al que le faltan las piezas más importantes.

Que hay en la memoria RAM que no esta en ningun otro sitio

La pregunta correcta no es "que puedo encontrar en memoria" sino "que me estoy perdiendo si no analizo la memoria". La lista es extensa.

Procesos en ejecución y sus relaciones

La RAM contiene la lista completa de procesos activos, incluyendo aquellos que herramientas del sistema operativo como el Administrador de Tareas no muestran. Un rootkit puede ocultar un proceso de las APIs normales del sistema, pero su estructura (EPROCESS en Windows) sigue existiendo en memoria fisica. Volatility puede recorrer las estructuras del kernel directamente y encontrar procesos que las herramientas del usuario nunca veran.

Cada proceso incluye su PID, su proceso padre (PPID), la linea de comandos con la que fue lanzado, la hora de creación, el usuario que lo ejecuta, las DLLs cargadas, los handles abiertos y los hilos activos. Esta información revela anomalias como un proceso cmd.exe lanzado desde un proceso de Microsoft Word (indicador clasico de explotación de documento), o un svchost.exe ejecutandose fuera de la ruta esperada.

Código inyectado y malware en memoria

El malware moderno frecuentemente se inyecta en procesos legitimos para evitar detección. Técnicas como process hollowing, DLL injection, reflective DLL loading y process doppelganging dejan el código malicioso unicamente en el espacio de direcciones de un proceso legitimo. En disco no hay ningun fichero sospechoso. En memoria, el código inyectado tiene caracteristicas detectables: regiones de memoria con permisos de lectura, escritura y ejecución (PAGE_EXECUTE_READWRITE), secciones que no corresponden a ninguna DLL cargada desde disco, o cabeceras PE en regiones que no deberian contenerlas.

Conexiones de red activas e historicas

La RAM preserva el estado de todas las conexiones TCP y UDP, incluyendo aquellas que ya se cerraron pero cuyas estructuras no han sido reutilizadas. Esto es fundamental para identificar comunicaciones C2 (Command and Control) que el firewall no registro o que el malware cerro tras enviar datos. Las direcciones IP, puertos, timestamps y el proceso asociado a cada conexión están disponibles en el volcado de memoria.

Credenciales y claves criptograficas

Los procesos de autenticación de Windows (lsass.exe) mantienen en memoria hashes NTLM, tickets Kerberos y, en configuraciones vulnerables, contrasenas en texto plano. Herramientas como Mimikatz explotan exactamente esta realidad. El análisis forense de memoria permite ver que credenciales estaban expuestas durante un incidente, evaluar el alcance del compromiso y determinar si el atacante pudo moverse lateralmente.

Las claves de cifrado de ransomware también residen en RAM mientras el proceso de cifrado esta activo. En casos documentados, analistas han recuperado claves AES de memoria de procesos de ransomware, permitiendo descifrar ficheros sin pagar rescate.

Registro del sistema (hives en memoria)

Windows carga los hives del registro en memoria para acceso rápido. Analizando la RAM se puede acceder al estado del registro tal como era en el momento de la captura, incluyendo claves de persistencia (Run, RunOnce, Services), configuración de seguridad, y evidencia de USB conectados. Esto complementa el análisis de registro desde disco porque muestra el estado en tiempo real, no el último punto de guardado.

Historial de comandos y artefactos de usuario

La RAM preserva buffers de consola (historial de cmd.exe y PowerShell), contenido del portapapeles, fragmentos de documentos abiertos, URLs visitadas recientemente y otros artefactos efimeros que nunca se escriben a disco de forma persistente.

El problema de la volatilidad: RFC 3227

El RFC 3227 (Guidelines for Evidence Collection and Archiving) establece un principio que todo analista forense debe interiorizar: la evidencia debe recopilarse en orden de volatilidad, de la más volatil a la menos volatil.

El orden es:

1. Registros de CPU y cache
2. Memoria RAM
3. Estado de la red (conexiones activas, tablas de enrutamiento)
4. Procesos en ejecución
5. Disco duro (sistema de ficheros)
6. Medios de almacenamiento externo
7. Logs remotos, backups

Los puntos 2, 3 y 4 están todos contenidos en un volcado de memoria RAM. Un solo dump de RAM captura simultaneamente procesos, conexiones de red, credenciales, código en ejecución y configuración del sistema. Por eso la adquisición de memoria es el primer paso critico en cualquier respuesta a incidentes competente.

El problema práctico es que la RAM se corrompe con cada segundo que pasa. Cada nuevo proceso que se lanza, cada página de memoria que se libera, cada operación del sistema operativo sobrescribe datos potencialmente relevantes. La ventana de oportunidad para capturar evidencia intacta es limitada.

Malware fileless: cuando el disco no tiene respuestas

El término "fileless malware" no significa que no exista fichero alguno en ningun momento. Significa que el malware opera principalmente en memoria, minimizando o eliminando su presencia en disco. Las técnicas incluyen:

Ejecución directa en memoria. El payload se descarga, se ejecuta en memoria y nunca toca el disco. PowerShell, WMI, macros de Office y herramientas LOLBins (Living Off The Land Binaries) facilitan este patron.

Persistencia sin fichero. El malware se almacena en el registro de Windows, en tareas programadas con comandos inline, o en suscripciones WMI. Al reiniciar, el sistema operativo reconstruye el malware en memoria desde estos repositorios que un antivirus tradicional basado en ficheros no escanea.

Reflective loading. El payload se carga en memoria de un proceso existente sin usar las APIs estandar del sistema operativo (LoadLibrary). No aparece en la lista de DLLs cargadas del proceso y no deja rastro en el log de carga de módulos.

Segun reportes de Elastic Security Labs, más del 50% de las amenazas detectadas en 2025 emplean alguna variante de ejecución en memoria. Para un analista, esto convierte el análisis de memoria de una técnica avanzada en una necesidad básica.

Conceptos fundamentales de memoria

Para analizar memoria eficazmente necesitas entender como la gestiona el sistema operativo.

Memoria virtual vs memoria fisica

Cada proceso en un sistema operativo moderno opera con su propio espacio de direcciones virtuales. En Windows de 64 bits, cada proceso ve un rango de direcciones de 0 a 128 TB (teorico). El sistema operativo (a traves de la MMU, Memory Management Unit, del procesador) traduce estas direcciones virtuales a direcciones fisicas en la RAM real.

Esto significa que dos procesos pueden usar la "misma" dirección virtual (por ejemplo 0x00400000) pero estar apuntando a zonas completamente distintas de la RAM fisica. Para el analista forense, esto implica que necesitas reconstruir las tablas de páginas (page tables) de cada proceso para acceder a su memoria. Volatility hace esto automaticamente.

Paginacion y fichero de página

Cuando la RAM fisica se llena, el sistema operativo mueve páginas poco usadas al fichero de paginacion en disco (pagefile.sys en Windows, swap en Linux). Esto significa que parte de la memoria de un proceso puede no estar en el dump de RAM. Para un análisis completo, conviene capturar también el pagefile.

Estructuras del kernel

El kernel del sistema operativo mantiene estructuras de datos criticas en memoria que describen el estado del sistema:

EPROCESS (Windows). Cada proceso tiene una estructura EPROCESS en el espacio del kernel. Contiene PID, PPID, nombre del proceso, token de seguridad, y punteros a la lista doblemente enlazada de todos los procesos. Rootkits que ocultan procesos manipulan esta lista enlazada (técnica DKOM, Direct Kernel Object Manipulation), pero la estructura EPROCESS sigue existiendo en memoria y puede encontrarse mediante scanning.

VAD (Virtual Address Descriptor). El arbol VAD de cada proceso describe todas las regiones de memoria asignadas: donde están, que tamaño tienen, que permisos tienen y si están respaldadas por un fichero en disco. El plugin malfind de Volatility usa los VADs para encontrar regiones sospechosas.

Networking structures. Las conexiones TCP/UDP se representan como estructuras en el pool de memoria del kernel. Incluso conexiones cerradas pueden persistir hasta que el sistema recicle esa memoria.

Que herramientas se usan

El ecosistema de memory forensics se centra en unas pocas herramientas clave:

Volatility 3 es el framework de referencia. Es open source, basado en Python, y soporta Windows, Linux y macOS. Funciona mediante plugins que extraen información específica del dump de memoria: procesos, DLLs, conexiones de red, registro, y mucho más. Lo cubrimos en profundidad en el tercer artículo de esta serie.

Rekall fue un fork de Volatility mantenido por Google que aportaba ideas interesantes como el análisis live de memoria. El proyecto se descontinuo oficialmente, pero algunos de sus conceptos fueron integrados en Volatility 3.

WinDbg es el depurador de Microsoft. Puede cargar crash dumps y volcados de memoria completos. Es útil para análisis profundo de estructuras del kernel, pero tiene una curva de aprendizaje pronunciada.

YARA no es una herramienta de memory forensics en si misma, pero sus reglas pueden ejecutarse contra volcados de memoria para buscar patrones de bytes específicos de familias de malware conocidas.

Formatos de volcado de memoria

Los dumps de memoria vienen en varios formatos segun la herramienta de adquisición:

Raw/dd. Un volcado lineal de la memoria fisica, byte a byte. Es el formato más universal y el que más herramientas soportan. Su tamaño es igual al de la RAM del sistema.

ELF core dump. Formato usado por LiME en Linux y por QEMU. Incluye metadatos sobre la arquitectura en cabeceras ELF.

Crash dump (DMP). Formato nativo de Windows. Puede ser completo (full dump) o parcial (kernel dump, minidump). Los crash dumps de Windows incluyen metadatos útiles como la versión del kernel.

VMware snapshot (VMEM). Cuando tomas un snapshot de una máquina virtual VMware, el fichero .vmem es la memoria RAM de esa VM. Volatility lo soporta directamente.

Hibernation file (hiberfil.sys). Windows guarda el contenido de la RAM a disco durante la hibernacion. Volatility puede procesarlo, aunque la compresion y la estructura requieren conversion previa.

Casos reales donde memory forensics fue decisivo

Operación Aurora (2009). El análisis de memoria de los sistemas comprometidos en Google revelo la presencia de un backdoor que operaba inyectado en procesos legitimos de Internet Explorer. El código malicioso fue extraido de la RAM para su análisis, lo que permitio atribuir el ataque al grupo APT1 y entender la cadena de explotación completa.

Stuxnet (2010). Parte del análisis de Stuxnet se realizo mediante volcados de memoria de sistemas SCADA infectados. Los drivers del rootkit y las configuraciones de los PLCs objetivo fueron extraidos de la RAM.

Ransomware con claves recuperables. Multiples operaciones de respuesta a incidentes han logrado recuperar claves AES-256 de ransomware activo en memoria, permitiendo el descifrado de ficheros. Esto funciona porque muchos ransomware mantienen la clave en memoria durante el proceso de cifrado, que puede durar horas en sistemas con muchos ficheros.

Ataques fileless con PowerShell. Campanas como PowerGhost y Purple Fox utilizan PowerShell para descargar y ejecutar payloads exclusivamente en memoria. Sin análisis de memoria, la única evidencia es el log de PowerShell (si estaba habilitado el logging avanzado) y las conexiones de red capturadas por el IDS.

Limitaciones del análisis de memoria

Es importante entender que no es:

No es una solución completa. El análisis de memoria complementa, no reemplaza, el análisis de disco, logs de red y otras fuentes de evidencia. Un incidente se reconstruye combinando todas las fuentes disponibles.

Depende del momento de captura. Si el sistema se reinicio antes de capturar la memoria, la evidencia volatil se perdio. Si el malware término su ejecución y libero su memoria, puede que los artefactos hayan sido sobrescritos.

Requiere conocimiento del sistema operativo. Analizar eficazmente un volcado de memoria exige entender las estructuras internas del OS. Las estructuras cambian entre versiones del kernel, lo que obliga a usar perfiles (profiles) o tablas de simbolos correctas.

Anti-forensics existe. Malware avanzado puede implementar técnicas anti-forenses: sobrescribir su propia memoria despues de ejecutar, usar memory-only encryption, o manipular las estructuras del kernel para confundir las herramientas de análisis.

Donde encaja memory forensics en el proceso DFIR

En el flujo estandar de respuesta a incidentes (NIST SP 800-61), el análisis de memoria se ubica en la fase de Detección y Análisis, pero su impacto llega a todas las fases:

Detección. Un volcado de memoria puede confirmar o descartar un compromiso cuando las alertas son ambiguas.

Análisis. Es la fuente principal para entender que hizo el atacante: que procesos lanzo, que credenciales robo, a que sistemas se conecto.

Contencion. El análisis de memoria identifica los procesos y conexiones maliciosos que necesitan ser terminados.

Erradicacion. Revela mecanismos de persistencia (servicios, claves de registro, tareas programadas) que deben eliminarse.

Leccion aprendida. Los artefactos de memoria alimentan los IOCs para mejorar la detección futura.

Proximo paso

En el siguiente artículo cubrimos las herramientas y técnicas de adquisición de memoria RAM: WinPmem, DumpIt, LiME, AVML y los procedimientos para garantizar que el volcado sea forense valido. La adquisición correcta es la base de todo lo que viene despues.

Recursos adicionales

Para profundizar en los fundamentos de memory forensics:

• "The Art of Memory Forensics" de Michael Hale Ligh, Andrew Case, Jamie Levy y Aaron Walters. Es la referencia clasica del campo.
• "Practical Memory Forensics" de Svetlana Ostrovskaya y Oleg Skulkin. Más reciente y con enfoque práctico.
• Volatility Foundation: https://volatilityfoundation.org (documentación oficial y plugins).
• SANS FOR508: Advanced Incident Response, Threat Hunting and Digital Forensics. El curso de referencia en la industria para memory forensics aplicado.
• MemLabs: https://github.com/stuxnet999/MemLabs. Coleccion de CTFs de memory forensics para practicar con volcados reales.