Volatility Framework

Volatility Framework

En el 82 % de las detecciones de 2025 analizadas por CrowdStrike, los atacantes no dejaron malware residente en disco —eran 79 % en la edición anterior—, según su Global Threat Report 2026. La tendencia lleva años subiendo y explica por dónde va el trabajo forense: cada punto que gana el ataque malware-free es un punto que pierde el análisis de disco frente al de memoria. Conviene leer bien qué significa «malware-free»: que no hay un binario malicioso residente en disco, no que el ataque viva únicamente en RAM. Buena parte de esas intrusiones usan credenciales legítimas y herramientas del propio sistema, y dejan rastro en registros, artefactos de ejecución y logs. Lo que sí implica es que buscar solo ficheros maliciosos en el disco no los encuentra, y ahí es donde el análisis de memoria y el de artefactos aportan lo que falta. Volatility Framework es la herramienta forense open-source más utilizada del mundo para analizar estos ataques, empleada por fuerzas de seguridad, agencias de inteligencia, academias forenses y peritos informáticos en más de 100 países. La versión Volatility 3 v2.26.0, publicada en mayo de 2025, es la que el proyecto señala como hito de convergencia con Volatility 2. Conviene no leerlo como paridad completa: el propio proyecto dice que aspira a alcanzarla, y hay plugins de la versión 2 —el del portapapeles, entre otros— que no se portaron.

Definición técnica

Volatility Framework es un framework de análisis forense de memoria escrito en Python que permite extraer, analizar e interpretar artefactos digitales contenidos en volcados (dumps) de memoria RAM de sistemas Windows, Linux y macOS. (Para Android existe la captura con LiME, pero Volatility 3 no trae plugins de Android.) Desarrollado inicialmente en 2007 por Aaron Walters y mantenido por la Volatility Foundation, se ha convertido en el estándar de facto para el análisis de memoria forense.

Arquitectura del framework:

┌──────────────────────────────────────────────────┐
│                 Volatility 3                      │
├──────────────────────────────────────────────────┤
│  Interfaz CLI                                     │
│  vol -f memoria.raw windows.pslist                │
├──────────────────────────────────────────────────┤
│  Framework Core                                   │
│  - Autodetección de perfil OS                     │
│  - Sistema de plugins modular                     │
│  - Renderizadores (tabla, JSON, CSV)              │
├──────────────────────────────────────────────────┤
│  Plugins por OS                                   │
│  ├── windows.* (pslist, netscan, malfind...)     │
│  ├── linux.* (pslist, bash, mount...)            │
│  ├── mac.* (pslist, netstat, bash...)            │
│  └── (no hay familia android: ver la nota de abajo)  │
├──────────────────────────────────────────────────┤
│  Symbol Tables                                    │
│  - ISF (Intermediate Symbol Format)               │
│  - Autodescargas desde Symbol Server              │
└──────────────────────────────────────────────────┘

Diferencias clave Volatility 2 vs Volatility 3:

Plugins esenciales para análisis forense

Los plugins de Volatility permiten extraer categorías específicas de artefactos de memoria:

Procesos y ejecución

## Listar procesos activos (incluye PID, PPID, timestamps)
vol -f memoria.raw windows.pslist

## Árbol de procesos (relaciones padre-hijo)
vol -f memoria.raw windows.pstree

## Procesos ocultos (detección rootkits)
vol -f memoria.raw windows.psscan

## Líneas de comando ejecutadas
vol -f memoria.raw windows.cmdline

## DLLs cargadas por cada proceso
vol -f memoria.raw windows.dlllist --pid 4892

Red y conexiones

## Conexiones de red activas y puertos en escucha
vol -f memoria.raw windows.netscan

## Sockets abiertos por proceso
vol -f memoria.raw windows.netstat

Detección de malware

## Regiones de memoria sospechosas (inyección de código)
vol -f memoria.raw windows.malfind

## Escaneo con reglas YARA
vol -f memoria.raw yarascan --yara-file reglas_malware.yar
## Requiere yara-x o yara-python>=3.8, que NO se instalan con «pip install volatility3»:
## sin ellas el plugin no se registra y el CLI da «invalid choice». Instalar con
## pip install "volatility3[full]" y comprobar antes del incidente, no durante.

## Drivers del kernel (detección rootkits)
vol -f memoria.raw windows.driverscan

## Hooks de SSDT (System Service Descriptor Table)
vol -f memoria.raw windows.ssdt

Credenciales y registros

## Hashes de contraseñas (SAM + SYSTEM)
vol -f memoria.raw windows.hashdump

## Credenciales en caché (LSA Secrets)
vol -f memoria.raw windows.lsadump

## Registro de Windows desde memoria
vol -f memoria.raw windows.registry.hivelist

Filesystem y ficheros

## Ficheros abiertos en memoria
vol -f memoria.raw windows.filescan

## Volcado de fichero específico desde memoria
vol -f memoria.raw windows.dumpfiles --virtaddr 0xfa8001a23060

## Historial del portapapeles
## OJO: windows.clipboard NO existe en Volatility 3 — era un plugin de la versión 2
## y no se portó. El CLI responde «invalid choice».

Flujo de trabajo forense con Volatility

Caso práctico: detección de malware fileless en servidor empresarial

Nota: El siguiente caso es un ejemplo compuesto y anonimizado basado en tipologías reales de peritaje informático. No representa un caso específico real.

Contexto: Una empresa logística de Valencia detectó transferencias bancarias no autorizadas por 120.000 EUR durante el fin de semana. El servidor de facturación no mostraba signos de compromiso en el análisis de disco: ni malware en disco, ni archivos sospechosos, ni cambios en el registro. El antivirus no reportó detecciones.

Investigación forense con Volatility:

1. Adquisición de memoria: Se capturó un volcado de 32 GB de la RAM del servidor Windows Server 2019 con FTK Imager antes de apagar la máquina
2. Análisis de procesos (pslist + pstree): Se identificó un proceso svchost.exe con PID 7832 cuyo proceso padre (PPID) era powershell.exe en lugar de services.exe (comportamiento anómalo)
3. Análisis de inyección (malfind): Se detectó código inyectado con permisos RWX en el espacio de memoria de svchost.exe. El código era un implante Cobalt Strike Beacon
4. Conexiones de red (netscan): El proceso falso svchost.exe mantenía una conexión HTTPS activa a una IP externa candidata a C2 —cuya geolocalización no basta para situar al atacante: hay que descartar antes que sea una salida de Tor, una VPN o un servicio compartido—
5. Credenciales (hashdump + lsadump): Se extrajeron hashes NTLM que revelaron que el atacante había obtenido las credenciales del administrador de dominio
6. Líneas de comando (cmdline): Se recuperaron los comandos PowerShell ejecutados por el atacante, incluyendo el script de transferencia bancaria

Qué aportó el análisis de memoria: el proceso enmascarado, su conexión saliente y las órdenes ejecutadas, que en disco no dejaban un binario que buscar. No es que el ataque fuera «indetectable» sin él —quedaba rastro en registros y artefactos de ejecución, y ahí es donde se corrobora— sino que la memoria es donde ese rastro se explica. El informe reconstruyó el timeline, que es lo que permite a la entidad y a las fuerzas de seguridad rastrear la infraestructura C2.

Marco legal en España

Relevancia probatoria:

• LECrim Art. 363: El juez puede acordar la obtención de muestras y datos que requieran intervención corporal o análisis técnicos. El volcado de memoria RAM se equipara a una adquisición forense digital
• LECrim Art. 588 sexies: Registro de dispositivos informáticos. La adquisición de memoria RAM requiere autorización judicial cuando el equipo está en posesión de un investigado
• Art. 326 LEC: Documentos privados en formato electrónico. Los resultados de Volatility, debidamente documentados con cadena de custodia, tienen valor probatorio como pericia informática

Estándares aplicables:

• ISO/IEC 27037:2012: Directrices para la adquisición de evidencia digital volátil (la memoria RAM es evidencia volátil por definición)
• RFC 3227: Guidelines for Evidence Collection and Archiving. Establece el “orden de volatilidad”: la memoria RAM debe capturarse antes que cualquier dato de disco
• UNE 71506:2013: Metodología para análisis forense de evidencias electrónicas

RGPD y protección de datos:

• Los volcados de memoria pueden contener datos personales (contraseñas, emails, documentos abiertos). Su tratamiento requiere base jurídica legítima (investigación penal, interés legítimo en auditoría interna)
• El perito debe aplicar el principio de minimización, analizando solo los datos relevantes para la investigación

Conceptos relacionados

• Memoria RAM forense - Fundamentos teóricos del análisis de memoria volátil
• Volatilidad y memoria forense - Concepto de orden de volatilidad en evidencia digital
• Análisis de malware - Volatility es herramienta esencial para análisis de malware fileless
• YARA Rules - Reglas de detección que Volatility puede ejecutar sobre memoria
• Timeline forense - Volatility contribuye artefactos temporales al timeline global
• KAPE - Herramienta complementaria para triage de disco y memoria

Preguntas frecuentes

¿Volatility es gratuito?

Si. Volatility Framework es software libre y de código abierto, con dos licencias distintas según la versión: la 2 es GPL-2.0 y la 3 —la del repositorio que se enlaza— se publica bajo la Volatility Software License 1.0. Si el dictamen declara la licencia de la herramienta, conviene decir cuál de las dos. Puede descargarse gratuitamente desde el repositorio oficial de GitHub (volatilityfoundation/volatility3). No requiere licencia comercial ni suscripción, lo que lo convierte en herramienta accesible para cualquier perito informático.

¿Puede Volatility analizar la memoria de un teléfono móvil?

Volatility 3 no trae plugins de Android: en la versión 2.28 no existe ninguno con android ni dalvik en el nombre, y el CLI responde «invalid choice». Lo que sí funciona en Android es capturar la memoria con LiME, cargándolo como módulo de kernel; el análisis posterior habrá que hacerlo con otras herramientas. Además, esa captura es compleja y generalmente requiere acceso root o herramientas hardware especializadas. Para forense móvil, es más común utilizar herramientas como Cellebrite UFED o MSAB XRY que incluyen capacidades de análisis de memoria.

¿Cómo se captura la memoria RAM de un servidor para analizarla con Volatility?

Depende del sistema operativo. En Windows, herramientas como FTK Imager, WinPmem o Belkasoft RAM Capturer pueden generar un volcado en formato raw o crash dump. En Linux, LiME (Linux Memory Extractor) crea módulos del kernel para captura. En entornos cloud (AWS/Azure), pueden utilizarse herramientas nativas como AVML. El volcado debe generarse en un medio externo, nunca en el propio disco del sistema investigado.

¿Los resultados de Volatility son admisibles en un tribunal español?

Si, siempre que se cumplan los estándares de cadena de custodia. El perito debe documentar: cómo y cuándo se adquirió el volcado de memoria, hash SHA-256 del fichero de volcado, versión de Volatility utilizada, plugins ejecutados y parámetros, y que el análisis se realizó sobre una copia del volcado original. La naturaleza open-source de Volatility refuerza la transparencia y reproducibilidad del análisis.

Artefactos de memoria más valiosos en investigaciones forenses

Artefactos recuperables exclusivamente de memoria RAM:

Por qué la memoria RAM es irremplazable:

Muchos de estos artefactos no existen en ningún otro lugar. Un malware fileless que opera exclusivamente en memoria no deja rastro en el disco duro. Las contraseñas en texto plano almacenadas temporalmente en la memoria del proceso LSASS de Windows se borran al apagar el equipo. Las conexiones de red activas desaparecen. Por eso, en la respuesta a incidentes, la captura de memoria RAM es la operación forense más urgente.

Volatility en la práctica: scripts y automatización

Para peritajes con análisis repetitivos conviene automatizar. Volatility 3 sí tiene una API de Python —volatility3.framework, con su contexto y sus automagics—, pero el script de abajo no la usa: envuelve la línea de comandos, que para un triaje es más que suficiente y mucho más legible. Conviene decirlo para no confundir una cosa con la otra, y recordar crear antes el directorio de salida, porque la redirección del shell no lo crea:

Ejemplo de script de triaje automático:

#!/usr/bin/env python3
"""
Script de triaje forense con Volatility 3.
Ejecuta los plugins más relevantes y genera informe.
"""
import subprocess
import hashlib
import datetime

DUMP = "memoria.raw"
OUTPUT = f"triaje_{datetime.datetime.now().strftime('%Y%m%d_%H%M%S')}"

plugins = [
    "windows.pslist",
    "windows.psscan",
    "windows.netscan",
    "windows.malfind",
    "windows.cmdline",
    "windows.dlllist",
    "windows.svcscan",
]

for plugin in plugins:
    output_file = f"{OUTPUT}/{plugin}.txt"
    cmd = f"vol -f {DUMP} {plugin} > {output_file}"
    subprocess.run(cmd, shell=True)
    print(f"[OK] {plugin}")

Este tipo de automatización permite al perito realizar un triaje completo de un volcado de memoria en minutos, identificando rápidamente los artefactos que requieren análisis manual profundo.

Referencias y fuentes

1. Volatility Foundation - “The Volatility Framework”, sitio oficial. volatilityfoundation.org

2. CrowdStrike — Global Threat Report: 82 % de detecciones sin malware en 2025 (79 % en la edición anterior), 89 % más de ataques de adversarios asistidos por IA y un tiempo de propagación medio de 29 minutos. Dos cautelas al citarlo: esa URL no tiene versión por edición y sirve siempre la última, así que el año hay que comprobarlo en la página, no darlo por el del ancla; y la casa publica además un Threat Hunting Report con ventana de observación distinta, cuyas cifras no son intercambiables

3. GitHub - “volatilityfoundation/volatility3”, repositorio oficial Volatility 3. github.com/volatilityfoundation/volatility3

4. SANS Institute - “FOR508: Advanced Incident Response, Threat Hunting, and Digital Forensics”, curso que utiliza Volatility extensivamente. sans.org

5. RFC 3227 - “Guidelines for Evidence Collection and Archiving”, orden de volatilidad. ietf.org/rfc/rfc3227

6. ISO/IEC 27037:2012 - Directrices para identificación, recolección, adquisición y preservación de evidencia digital. iso.org

7. NIST SP 800-86 — Guide to Integrating Forensic Techniques into Incident Response, National Institute of Standards and Technology (2006). Ficha oficial en NIST CSRC

8. Aaron Walters - “The Volatility Framework: Volatile memory artifact extraction utility”, publicación original. volatilityfoundation.org

9. UNE 71506:2013 - Metodología para el análisis forense de evidencias electrónicas, AENOR. une.org

10. (Retirado un listado de herramientas de un sitio de contenidos. Para el catálogo real y actualizado, la referencia es el repositorio de Volatility y la documentación de cada proyecto.)