Volatility 3:
análisis de memoria RAM para respuesta a incidentes
Blue Team y Forense Digital | unfantasmaenelsistema.com
El disco duro cuenta lo que un sistema guardó. La memoria RAM cuenta lo que un sistema estaba haciendo en el momento exacto en que lo miraste: qué procesos corrían, qué conexiones tenían abiertas, qué había descifrado en claro, qué se inyectó en qué. Un malware moderno puede vivir entero en memoria sin tocar el disco nunca —y entonces el análisis forense clásico de disco no ve absolutamente nada—. Ahí es donde entra el análisis de memoria.
Este artículo es una introducción práctica a Volatility 3, el marco de análisis de memoria de referencia, libre y multiplataforma. Veremos por qué la RAM importa, cómo se captura sin destruir pruebas, cómo se estructura Volatility 3 frente a la versión 2, y qué plugins usar en un triaje de diez minutos. Todo con imágenes de memoria de retos públicos: nada de sistemas ajenos.
Qué aprenderás en este artículo
Por qué la memoria volátil contiene pruebas que el disco nunca tendrá · El orden de volatilidad y la cadena de custodia al adquirir RAM · Herramientas de adquisición en Windows y Linux, y el problema del page smearing · Qué cambió entre Volatility 2 y 3, y qué son las symbol tables · Los plugins clave y un flujo de triaje rápido para clasificar una máquina comprometida
1. Por qué la RAM importa en un incidente
Cuando respondes a un incidente, la memoria del equipo afectado suele ser la fuente de pruebas más rica y la que antes desaparece. Contiene cosas que en el disco no vas a encontrar, o no en claro:
- Código que solo vive en memoria: cargadores sin fichero (fileless), inyección en procesos legítimos, shellcode reflejado. Nunca se escribió un .exe que analizar
- Secretos en claro: claves de cifrado, contraseñas en cachés de procesos, tokens de sesión, material de una bóveda ya desbloqueada
- Estado de red vivo: conexiones establecidas, puertos a la escucha, sockets de un canal de mando y control que en los logs quizá no quedó registrado
- Procesos y su linaje: qué proceso lanzó qué, líneas de comando completas, DLLs cargadas, handles a ficheros y claves de registro abiertos en ese instante
- Artefactos ya borrados del disco pero todavía presentes en la caché de memoria del sistema de ficheros
El precio de toda esa riqueza es que es efímera. Apagar el equipo la destruye; incluso dejarlo encendido la va sobrescribiendo. Por eso la captura de memoria es de las primeras acciones en la respuesta, y por eso se hace con método.
2. Orden de volatilidad y cadena de custodia
El orden de volatilidad (formalizado en el RFC 3227) dice que hay que recoger las pruebas de la más efímera a la más persistente: primero registros y caché de CPU, luego tabla de rutas y ARP, luego la memoria RAM, después el disco, y al final soportes de archivo y copias de seguridad. En la práctica de campo, la RAM es lo primero que captura un analista tras aislar el equipo de la red.
Cadena de custodia: cada volcado debe quedar documentado —quién lo tomó, cuándo, con qué herramienta y versión, en qué equipo— y sellado con un hash criptográfico (SHA-256) calculado nada más obtener el fichero. Cualquier análisis posterior se hace sobre copias, nunca sobre el original, y se vuelve a verificar el hash antes y después. Si el hash no cuadra, la prueba deja de ser fiable.
# Sellar el volcado nada mas obtenerlo (Linux / macOS) sha256sum incidente01-memoria.raw > incidente01-memoria.raw.sha256 # Verificar antes de empezar el analisis sha256sum -c incidente01-memoria.raw.sha256 # Equivalente en PowerShell Get-FileHash .\incidente01-memoria.raw -Algorithm SHA256
Marco legal: solo con autorización
Capturar y analizar la memoria de un sistema que no es tuyo, sin autorización escrita del titular, puede ser delito de descubrimiento y revelación de secretos y de daños informáticos · En España son de aplicación los artículos 197, 197 bis, 197 ter y 264 del Código Penal · Trabaja siempre sobre infraestructura propia, un laboratorio aislado, o con un contrato o encargo formal de respuesta a incidentes que delimite el alcance por escrito · Los ejemplos de este artículo usan imágenes de memoria de retos forenses públicos, creadas para practicar
3. Adquisición: cómo se captura la memoria
La captura la hace una herramienta dedicada que lee la memoria física del sistema en vivo y la escribe a un fichero, idealmente en un soporte externo para no tocar el disco interno. Cada sistema operativo tiene sus opciones.
| Sistema | Herramienta | Notas |
|---|---|---|
| Windows | WinPMEM | Libre, de código abierto, sin instalación; salida en formato raw o AFF4 |
| Windows | Magnet RAM Capture | Gratuita, interfaz mínima, muy usada en campo |
| Windows | DumpIt (Comae/Magnet) | Un solo ejecutable, doble clic y volcado; formato raw o Microsoft crash dump |
| Windows | FTK Imager | También captura RAM además de imágenes de disco |
| Linux | AVML | De Microsoft, un binario estático que funciona en casi cualquier kernel sin compilar módulos |
| Linux | LiME | Módulo del kernel (LKM); requiere cabeceras del kernel exacto o compilación cruzada |
| macOS | OSXPmem / cierre de sesión | Cada vez más limitado por SIP; a menudo se recurre a la partición de hibernación |
| Máquinas virtuales | Fichero de estado del hipervisor | Un .vmem (VMware) o una snapshot equivale a un volcado limpio y consistente |
3.1 El problema del page smearing
Capturar la RAM de un sistema en marcha no es instantáneo: mientras la herramienta recorre gigabytes de memoria, el sistema sigue funcionando y modificando esas mismas páginas. El resultado es un volcado ligeramente inconsistente —las tablas de páginas apuntan a contenido que ya cambió— y se conoce como page smearing. Se traduce en errores de Volatility al recorrer estructuras, procesos que aparecen a medias o direcciones que no resuelven.
- Es más frecuente cuanta más RAM tiene el equipo y más cargado está en el momento de la captura
- Se mitiga capturando lo más rápido posible y, en máquinas virtuales, pausando la VM y usando el fichero de memoria del hipervisor en vez de una herramienta dentro del huésped
- Si un plugin falla de forma rara, sospecha antes del volcado que de Volatility
4. Volatility 2 frente a Volatility 3
Volatility 3 es una reescritura completa. Si vienes de la versión 2 o de tutoriales antiguos, estos son los cambios que más te van a afectar:
| Aspecto | Volatility 2 | Volatility 3 |
|---|---|---|
| Lenguaje | Python 2 (fin de vida) | Python 3 |
| Perfil del sistema | Había que indicar –profile=Win7SP1x64 | Autodetección mediante symbol tables |
| Nombres de plugins | pslist, netscan | Con espacio de nombres: windows.pslist, windows.netscan |
| Windows: símbolos | Perfiles precompilados incluidos | Descarga automática de PDB desde los servidores de símbolos de Microsoft |
| Linux/macOS | Perfil generado a mano con dwarfdump | Fichero ISF (JSON) de symbol table por kernel |
| Rendimiento | Más lento, más memoria | Núcleo reescrito, notablemente más rápido |
Las symbol tables (ISF, Intermediate Symbol Format) son ficheros JSON que describen dónde está cada estructura del kernel en esa versión concreta del sistema. Para Windows, Volatility 3 las obtiene solo descargando el PDB correspondiente. Para Linux necesitas el ISF del kernel exacto de la imagen: lo generas con `dwarf2json` a partir del `vmlinux` con símbolos de depuración, o lo bajas de un repositorio comunitario.
# Instalacion (entorno virtual recomendado) python3 -m venv vol3 && source vol3/bin/activate pip install volatility3 # Ayuda y listado de plugins disponibles vol -h # Primer contacto: informacion general de la imagen vol -f incidente01-memoria.raw windows.info
5. Los plugins que se usan en casi todos los casos
5.1 Procesos: qué corría y de dónde salió
- windows.pslist: procesos siguiendo la lista doblemente enlazada del kernel — la vista «oficial»
- windows.psscan: busca estructuras de proceso por firma en toda la memoria — encuentra procesos ocultos o ya terminados que pslist no muestra
- windows.pstree: la misma lista pero como árbol padre-hijo, ideal para ver linajes anómalos (un `winword.exe` que lanza `powershell.exe` que lanza `cmd.exe`)
- windows.cmdline: la línea de comandos completa de cada proceso, argumentos incluidos
- windows.dlllist y windows.ldrmodules: DLLs cargadas por proceso; comparar ambas revela módulos que se cargaron sin pasar por el cargador normal de Windows
Comparar `pslist` con `psscan` es uno de los primeros gestos del análisis: si `psscan` devuelve un proceso que `pslist` no lista, alguien lo ha desenlazado de la estructura del kernel para esconderlo (técnica de DKOM).
5.2 Red: con quién hablaba el equipo
- windows.netscan: escanea toda la memoria en busca de estructuras de conexión y socket — direcciones, puertos, estado y el PID dueño de cada conexión
- windows.netstat: equivalente al comando `netstat`, recorriendo las tablas del sistema
Una conexión saliente a una IP desconocida en un puerto alto, cuyo dueño es un proceso que no debería tener red (por ejemplo `notepad.exe`), es una señal de libro de un canal de mando y control o de código inyectado.
5.3 Inyección y código anómalo
- windows.malfind: busca regiones de memoria privadas, ejecutables y con permiso de escritura (RWX) que no se corresponden con ningún fichero en disco — el patrón típico de shellcode inyectado. Vuelca un extracto de cada región para inspección
- windows.hollowprocesses / comparación de rutas: process hollowing consiste en arrancar un proceso legítimo suspendido, vaciar su imagen y sustituirla por otra. Se detecta cuando la imagen mapeada en memoria no coincide con el ejecutable de la ruta declarada
- windows.svcscan: servicios de Windows registrados, incluidos los que se crearon para persistencia
5.4 Ficheros, registro y credenciales
- windows.filescan + windows.dumpfiles: localiza objetos de fichero en memoria y extrae su contenido — útil para recuperar un ejecutable que ya se borró del disco
- windows.handles: handles abiertos por un proceso (ficheros, claves, mutex). Un mutex con nombre peculiar suele ser un indicador de compromiso reutilizable
- windows.registry.hivelist / printkey: navegar las ramas de registro cargadas, por ejemplo las claves `Run` de autoarranque
- windows.hashdump / lsadump / cachedump: extraen hashes de credenciales de las estructuras de SAM y LSA presentes en memoria. Solo en tu laboratorio o en un encargo con alcance que lo cubra
| Pregunta del analista | Plugin de Volatility 3 |
|---|---|
| ¿Qué procesos corrían? | windows.pslist, windows.pstree |
| ¿Hay procesos ocultos? | windows.psscan (comparar con pslist) |
| ¿Con qué se lanzó cada proceso? | windows.cmdline |
| ¿Qué conexiones de red había? | windows.netscan, windows.netstat |
| ¿Hay código inyectado? | windows.malfind, windows.ldrmodules |
| ¿Process hollowing? | comparar imagen mapeada vs ruta en disco |
| ¿Persistencia por servicio o registro? | windows.svcscan, windows.registry.printkey |
| ¿Ficheros borrados recuperables? | windows.filescan + windows.dumpfiles |
6. Un triaje de diez minutos
Ante una imagen de memoria de la que no sabes nada, este recorrido rápido suele bastar para decidir si la máquina está comprometida y por dónde seguir:
IMG=incidente01-memoria.raw # 1. Contexto: version de Windows, hora del volcado vol -f $IMG windows.info # 2. Arbol de procesos: buscar linajes raros vol -f $IMG windows.pstree # 3. Procesos ocultos: comparar con psscan vol -f $IMG windows.psscan # 4. Lineas de comando completas vol -f $IMG windows.cmdline # 5. Conexiones de red y sus duenos vol -f $IMG windows.netscan # 6. Inyeccion de codigo vol -f $IMG windows.malfind # 7. Persistencia: servicios y claves Run vol -f $IMG windows.svcscan
Con eso en la mano ya tienes hipótesis: un proceso sospechoso con su PID, su padre, su línea de comando, sus conexiones y quizá una región RWX. El siguiente paso es volcar ese proceso (`windows.memmap –dump` o `windows.dumpfiles`) y llevarlo a un análisis estático o a un entorno de sandbox, siempre aislado.
El análisis de memoria no sustituye al resto
Un volcado es una foto de un instante: no verás lo que pasó antes ni después · Combínalo siempre con los logs del sistema, la telemetría de EDR, los artefactos de disco y la línea temporal — la memoria confirma y enriquece, rara vez cierra el caso sola
7. Dónde practicar
- Volatility Foundation publica imágenes de ejemplo y documentación oficial en volatilityfoundation.org
- Retos forenses públicos: los CTF de estilo DFIR (Magnet Weekly, DEF CON, CyberDefenders, MemLabs de stuxnet999) incluyen volcados de memoria con solución explicada
- Móntate tu propio caso: en un Windows de laboratorio aislado, ejecuta una muestra de un repositorio de pruebas o simplemente unas herramientas administrativas, captura la RAM con WinPMEM y analízala
- El libro The Art of Memory Forensics sigue siendo la referencia conceptual, aunque sus ejemplos usen Volatility 2
Referencias
volatility3.readthedocs.io — Documentación oficial y lista completa de plugins · github.com/volatilityfoundation/volatility3 — Código y ejemplos · github.com/microsoft/avml — Adquisición de memoria en Linux sin compilar módulos · cyberdefenders.org — Retos de análisis de memoria con imágenes descargables · RFC 3227 — Directrices para la recogida y el archivo de pruebas
Conclusión
El análisis de memoria llena el hueco que el forense de disco no puede cubrir: el estado vivo de un sistema, con su código efímero, sus secretos en claro y sus conexiones abiertas. Volatility 3 hace ese análisis accesible —libre, en Python 3, con autodetección del sistema— y un puñado de plugins (pstree, psscan, cmdline, netscan, malfind, svcscan) resuelve la mayor parte de un triaje inicial.
La técnica solo vale si la prueba es sólida: captura rápido para minimizar el page smearing, sella el volcado con un hash en cuanto lo tengas, trabaja sobre copias y documenta cada paso. Y hazlo únicamente sobre sistemas propios, de laboratorio o dentro de un encargo formal — la memoria de un equipo ajeno está tan protegida por la ley como cualquier otro secreto.
unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)