Forense de memoria avanzado: plugins Volatility 3 y malware en RAM

La lección de Volatility que ya publicamos cubre el flujo básico: crear un dump, identificar el perfil, correr pstree, netscan, malfind, hashdump. Eso es suficiente para la mayoría de incidentes simples. Pero cuando te enfrentas a malware sofisticado — un beacon de Cobalt Strike con configuración XOR en memoria, un proceso hollowed que se hace pasar por svchost.exe, un rootkit que manipula las estructuras del kernel para esconderse — los plugins básicos no alcanzan. Necesitas técnicas avanzadas, plugins especializados y, a veces, escribir tus propios plugins.

Esta lección va un nivel más allá. Cubre la arquitectura interna de Volatility 3 para que entiendas cómo crear plugins custom, las técnicas de inyección y ocultación de malware en memoria y cómo detectarlas, el uso de YARA dentro de dumps de memoria, la generación de timelines desde artefactos de memoria y las técnicas anti-forense que los atacantes usan para dificultar el análisis.

Es la tercera lección de la Tanda 8. Si no leíste la lección básica de Volatility, hazlo primero: esta asume que ya sabes capturar un dump, elegir symbol tables y correr los plugins esenciales.

Analiza solo dumps de equipos propios o con autorización explícita. Las técnicas de detección de malware que se enseñan aquí son defensivas, pero el conocimiento es de doble uso. Aplica siempre el marco ético y legal.

Qué cubre esta lección avanzada#

La forense de memoria avanzada se mueve en tres ejes que los plugins básicos no cubren bien.

El primer eje es la detección de técnicas sofisticadas de inyección: process hollowing, reflective DLL injection, APC injection, y otros métodos que el malware usa para ejecutar código en el contexto de procesos legítimos sin dejar binarios en disco. El segundo eje es el análisis temporal: usar el plugin timeliner y otros para reconstruir la secuencia exacta de eventos desde la memoria, incluyendo timestamps de creación de procesos, conexiones de red y modificaciones de registro. El tercer eje es la extensibilidad: cómo escribir plugins propios cuando ninguno existente hace exactamente lo que necesitas.

Arquitectura de plugins en Volatility 3#

Volatility 3 reescribió completamente la arquitectura de plugins respecto a Vol 2. Cada plugin es una clase Python que hereda de interfaces.plugins.PluginInterface y define qué datos necesita y cómo los presenta.

Estructura básica de un plugin#

from volatility3.framework import interfaces, renderers
from volatility3.framework.configuration import requirements

class MiPlugin(interfaces.plugins.PluginInterface):
    """Descripción del plugin."""

    _required_framework_version = (2, 0, 0)

    @classmethod
    def get_requirements(cls):
        return [
            requirements.TranslationLayerRequirement(
                name="primary",
                description="Memory layer",
                architectures=["Intel32", "Intel64"]
            ),
            requirements.SymbolTableRequirement(
                name="nt_symbols",
                description="Windows kernel symbols"
            ),
        ]

    def run(self):
        # Lógica del plugin
        kernel = self.context.modules[self.config["nt_symbols"]]
        # ... acceder a estructuras de memoria ...
        return renderers.TreeGrid(
            [("PID", int), ("Name", str), ("Finding", str)],
            self._generator()
        )

    def _generator(self):
        # Yield filas de resultados
        yield (0, (1234, "svchost.exe", "RWX region detected"))

Conceptos clave#

• TranslationLayer: abstracción que traduce direcciones virtuales a físicas en el dump.
• SymbolTable: definición de las estructuras del kernel (EPROCESS, KTHREAD, etc.) para el build específico del OS.
• TreeGrid: estructura de salida tabular que todos los plugins usan para renderizar resultados.
• Automagic: módulos que detectan automáticamente el OS, la arquitectura y las symbol tables necesarias.

Symbol tables para kernels custom#

Para kernels Linux compilados a medida (común en entornos embebidos o cloud), necesitas generar el ISF (Intermediate Symbol Format) manualmente.

# Descargar dwarf2json
git clone https://github.com/volatilityfoundation/dwarf2json.git
cd dwarf2json && go build

# Generar ISF desde el kernel con símbolos de debug
./dwarf2json linux --elf /usr/lib/debug/boot/vmlinux-$(uname -r) > linux-custom.json

# Colocar el ISF donde Volatility lo encuentre
cp linux-custom.json ~/.local/lib/python3/volatility3/symbols/linux/

Técnicas avanzadas de detección de malware#

El malware moderno rara vez existe como un ejecutable convencional en la lista de procesos. Usa técnicas de inyección para esconderse dentro de procesos legítimos.

Cuándo se necesita análisis avanzado#

• El triaje básico (pstree + netscan) no revela nada anómalo pero el IDS sigue detectando tráfico C2.
• Un proceso legítimo como svchost.exe o explorer.exe tiene conexiones de red que no debería.
• malfind detecta regiones RWX pero necesitas determinar qué tipo de inyección es.
• Necesitas reconstruir un timeline preciso de cuándo se creó cada proceso y conexión.
• Sospechas de un rootkit a nivel de kernel que oculta procesos o módulos.
• Quieres buscar IOCs específicos (hashes, strings, patrones hex) en toda la memoria.

Plugins avanzados paso a paso#

yarascan: buscar patrones con YARA#

# Buscar con una regla YARA en todos los procesos
vol -f dump.raw windows.yarascan --yara-file cobalt-strike.yar

# Buscar una string específica en toda la memoria del kernel
vol -f dump.raw windows.yarascan --yara-rules "rule test { strings: $a = \"beacon\" condition: $a }"

# Buscar en un proceso concreto
vol -f dump.raw windows.yarascan --yara-file rules.yar --pid 4120

yarascan es el puente entre YARA y la forense de memoria. Puedes usar cualquier regla YARA existente (de repositorios como YARA-Rules, Florian Roth's signature-base) y aplicarla sobre el dump.

timeliner: reconstruir la secuencia#

# Generar timeline unificado
vol -f dump.raw timeliner.Timeliner

# Exportar a formato body para mactime
vol -f dump.raw timeliner.Timeliner --body-file timeline.body
mactime -b timeline.body -d > timeline.csv

El timeliner combina timestamps de múltiples fuentes en memoria: creación de procesos, conexiones de red, claves de registro modificadas, timestamps de archivos en caché. El resultado es una secuencia cronológica que reconstruye el incidente.

vadinfo: inspeccionar regiones de memoria#

# Ver detalles de todas las VADs de un proceso
vol -f dump.raw windows.vadinfo --pid 4120

# Columnas: start, end, tag, protection, committed, private
# Buscar: PAGE_EXECUTE_READWRITE (RWX), IMAGE sin archivo mapeado

Las regiones VAD (Virtual Address Descriptor) del kernel describen cada segmento de memoria de un proceso. Una región con protección RWX que no está mapeada a un archivo en disco es altamente sospechosa.

ssdt: detectar hooks de rootkit#

# Verificar System Service Descriptor Table
vol -f dump.raw windows.ssdt

# Entradas que apuntan fuera de ntoskrnl.exe o win32k.sys son hooks

Un rootkit de kernel puede hookear la SSDT para interceptar syscalls. Si una entrada de la SSDT apunta a una dirección fuera de los módulos legítimos del kernel, hay un hook instalado.

Walkthrough: detectar process hollowing y beacon C2#

Un equipo reporta tráfico sospechoso saliente desde un servidor. El dump de memoria está listo. Vamos a encontrar el malware.

Paso 1: árbol de procesos#

vol -f dump.raw windows.pstree
# Todos los svchost.exe deben ser hijos de services.exe
# Un svchost.exe hijo de cmd.exe o powershell.exe es anómalo

Paso 2: verificar con psscan#

# Comparar pslist vs psscan
vol -f dump.raw windows.pslist > pslist.txt
vol -f dump.raw windows.psscan > psscan.txt

# Si un PID aparece en psscan pero no en pslist: DKOM
diff <(awk '{print $1}' pslist.txt | sort) <(awk '{print $1}' psscan.txt | sort)

Paso 3: inspeccionar proceso sospechoso#

# VADs del proceso sospechoso (PID 4120)
vol -f dump.raw windows.vadinfo --pid 4120
# Buscar: Protection PAGE_EXECUTE_READWRITE, Tag: VadS (no VadI)

# malfind para detectar shellcode
vol -f dump.raw windows.malfind --pid 4120
# Si muestra un PE header (MZ) en una región RWX: process hollowing confirmado

Paso 4: buscar beacon con YARA#

# Regla para detectar config de Cobalt Strike
vol -f dump.raw windows.yarascan --yara-rules "rule CS_Config { strings: \$config = { 00 01 00 01 00 02 ?? ?? 00 02 00 01 00 02 ?? ?? } condition: \$config }"

Paso 5: extraer y analizar#

# Dumpear la memoria del proceso sospechoso
vol -f dump.raw windows.dumpfiles --pid 4120 --dump-dir ./extracted/

# Dumpear la región VAD sospechosa específica
vol -f dump.raw windows.vadyarascan --pid 4120 --dump

# Calcular hash del binario extraído
sha256sum ./extracted/*
# Buscar en VirusTotal, MISP, OTX

Paso 6: conexiones de red#

vol -f dump.raw windows.netscan | grep 4120
# PID 4120 -> 203.0.113.5:443 ESTABLISHED (C2 identificado)

# Correlacionar timing de conexiones con timeliner
vol -f dump.raw timeliner.Timeliner | grep "4120\|203.0.113.5"

Qué revelan las técnicas avanzadas#

Anti-forense en memoria y cómo superarla#

Los atacantes sofisticados conocen las técnicas de forense de memoria y aplican contramedidas.

DKOM (Direct Kernel Object Manipulation)#

El rootkit modifica la lista enlazada de estructuras EPROCESS en el kernel para ocultar su proceso. pslist camina esa lista y no lo ve. Contramedida: psscan escanea la memoria buscando pool tags de EPROCESS, encontrando incluso los desenlazados.

Timestomping en memoria#

Algunos rootkits modifican los timestamps de creación de procesos en la estructura EPROCESS para confundir el timeline. Contramedida: comparar timestamps de proceso con timestamps de conexiones de red y entradas de registro, que se almacenan en estructuras distintas.

Cifrado de payload en memoria#

El malware mantiene su payload cifrado en memoria y solo lo descifra justo antes de ejecutarlo, volviendo a cifrar después. Contramedida: capturar el dump durante la ejecución activa del malware (no cuando está idle), o buscar el stub de descifrado con YARA.

Destrucción de evidencia en memoria#

El malware puede borrar sus propias páginas de memoria después de ejecutar (VirtualFree, NtFreeVirtualMemory). Contramedida: los page tables del kernel mantienen información residual, y las pool allocations pueden contener fragmentos. Plugins de bajo nivel que escanean pool memory pueden encontrar restos.

Evasión de YARA#

Malware que fragmenta sus strings para evitar matches de YARA: cada string está partida entre varias regiones de memoria. Contramedida: reglas YARA con wildcards hex y condiciones basadas en proximidad, o dumpear toda la memoria del proceso y buscar en el dump consolidado.

Errores comunes en análisis avanzado#

• Asumir que malfind detecta todo: solo encuentra regiones RWX con patrones sospechosos. Un beacon con protección RX (no W) post-inyección puede escapar.
• No actualizar las symbol tables: Volatility 3 necesita ISF actualizados para builds recientes de Windows. Símbolos incorrectos producen resultados corruptos o crashes.
• Correr demasiados plugins sin hipótesis: el análisis avanzado debe ser guiado. Empieza con lo que sabes (alerta del IDS, IP sospechosa) y profundiza desde ahí.
• No preservar el dump original: si corres plugins sobre el dump original y la herramienta escribe en el directorio del dump, puedes contaminar la evidencia.
• Ignorar los timestamps relativos: en un dump, todos los timestamps son del momento de captura. No confundir con el momento del incidente.
• Escribir plugins custom sin tests: un bug en tu plugin puede hacer que descartes evidencia válida o reportes falsos positivos.
• No cruzar hallazgos de memoria con disco y red: un proceso sospechoso en memoria debe corroborarse con logs del disco y tráfico de red.

Preguntas frecuentes#

¿Volatility 3 detecta todo tipo de rootkit?#

No. Vol 3 detecta rootkits que manipulan estructuras conocidas del kernel (EPROCESS, SSDT, IDT, callbacks). Rootkits que operan a nivel de hypervisor (hyperjacking) o firmware están fuera del alcance del análisis de memoria convencional.

¿Puedo usar YARA rules de repositorios públicos directamente?#

Sí, pero con cuidado. Reglas diseñadas para escanear archivos en disco pueden generar falsos positivos en memoria porque las strings aparecen en contextos diferentes (datos de red en buffers, strings cargadas por antivirus que analizan las mismas firmas). Valida siempre los resultados manualmente.

¿MemProcFS es mejor que Volatility?#

Son complementarios. MemProcFS monta el dump como un filesystem virtual donde puedes navegar procesos, módulos, registry como si fueran archivos. Es más intuitivo para exploración rápida. Volatility tiene más plugins especializados y es mejor para automatización con scripts. Muchos analistas usan ambos.

¿Cómo practico análisis avanzado de memoria?#

El laboratorio snort de whoami-labs incluye escenarios con artefactos de malware en memoria. Además, recursos gratuitos como los challenges del Volatility Foundation y los dumps de Malware Traffic Analysis proporcionan PCAPs y dumps para practicar.

¿Se puede hacer forense de memoria en contenedores?#

Los contenedores comparten el kernel del host. Un dump de la memoria del host contiene los procesos de todos los contenedores. Vol 3 los muestra como procesos normales. La dificultad está en identificar qué proceso pertenece a qué contenedor, usando los namespaces y cgroups visibles en las estructuras del kernel.

Resumen#

• La forense de memoria avanzada va más allá de pstree y netscan: detecta inyecciones sofisticadas, rootkits y beacons cifrados.
• Process hollowing se detecta comparando el contenido de la VAD con el ejecutable en disco: PE header en región RWX sin archivo mapeado.
• yarascan aplica reglas YARA sobre la memoria, conectando threat intelligence con análisis forense.
• timeliner genera una secuencia cronológica de eventos desde múltiples fuentes en memoria.
• DKOM se derrota comparando pslist (lista enlazada) con psscan (escaneo de pool memory).
• Volatility 3 es extensible: puedes escribir plugins custom en Python heredando de PluginInterface.

Fuentes y lecturas recomendadas#

• Volatility 3 — GitHub
• Volatility 3 Documentation
• 13Cubed — Memory Forensics (YouTube)
• SANS FOR508 — Advanced Incident Response
• dwarf2json — Symbol Table Generator
• Cobalt Strike YARA Rules — Elastic