Detección de Rootkits con Volatility y GMER: Guía Práctica de Análisis Forense

Por qué la memoria no miente

Un rootkit controla lo que el sistema operativo te muestra. Cuando ejecutas tasklist, dir o sc query en un sistema infectado, las respuestas pasan por APIs del kernel que el rootkit ya ha comprometido. El resultado: procesos invisibles, drivers fantasma, archivos que no existen para el SO pero están en disco.

La memoria RAM es diferente. Un dump de memoria captura el estado bruto de todas las estructuras del kernel: listas de procesos, tablas de syscalls, callbacks, drivers cargados, páginas de memoria de cada proceso. El rootkit manipula las APIs que leen estas estructuras, pero no puede alterar las estructuras en sí sin romper la estabilidad del sistema. Y si las altera (DKOM), deja rastros en otras estructuras que no modificó.

Esa asimetría es la base de toda la detección forense de rootkits: analizar la memoria fuera del sistema comprometido, donde el rootkit no tiene control.

Volatility Framework: la herramienta de referencia

Volatility es el framework open-source de referencia para análisis forense de memoria. Soporta Windows, Linux y macOS. Dos versiones coexisten en la práctica:

Aspecto	Volatility 2	Volatility 3
Python	2.7 (EOL)	3.7+
Perfiles	Ficheros .zip por cada versión exacta del kernel	Tablas de símbolos ISF (auto-detección)
Arquitectura	Monolítica	Modular (plugins como paquetes)
Rendimiento	Más lento en dumps grandes	Optimizado, uso de caché
Extensibilidad	Herencia de clases compleja	Framework de plugins limpio
Estado	Mantenimiento mínimo	Desarrollo activo

Para investigaciones nuevas, Volatility 3 es la elección correcta. Los ejemplos de este artículo usan vol3 (alias de python3 vol.py).

Obtener un dump de memoria

Antes de analizar, necesitas capturar la RAM del sistema sospechoso:

# Windows: WinPmem (recomendado por el proyecto Volatility)
winpmem_mini_x64.exe memdump.raw

# Linux: LiME (Loadable Kernel Module)
sudo insmod lime-$(uname -r).ko "path=/tmp/memdump.lime format=lime"

# Virtualización: snapshot de la VM y extraer el .vmem

Captura la memoria lo antes posible. Cada segundo que pasa, el contenido cambia y se pierden artefactos.

Plugins de Volatility para cazar rootkits

pslist vs psscan: detectar DKOM

El primer análisis de cualquier investigación de rootkits: comparar la lista de procesos "oficial" con lo que realmente existe en memoria.

# pslist: recorre la lista doblemente enlazada de EPROCESS
# Ve lo que el kernel (y el rootkit) quiere que veas
vol3 -f memdump.raw windows.pslist

# psscan: escanea TODA la memoria buscando pool tags 'Proc'
# Encuentra procesos desenlazados por DKOM
vol3 -f memdump.raw windows.psscan

La técnica: si un proceso aparece en psscan pero no en pslist, fue desenlazado de la lista activa. Es la firma clásica de DKOM.

# Ejemplo de resultado comparado:
# pslist:  PID 4, 324, 680, 1024, 1536, 2048
# psscan:  PID 4, 324, 680, 888, 1024, 1536, 2048
#
# PID 888 solo en psscan → oculto por DKOM → investigar

ssdt: detectar SSDT hooking

La SSDT (System Service Descriptor Table) contiene punteros a todas las funciones de syscalls del kernel. Un rootkit que hookea la SSDT reemplaza punteros legítimos con direcciones de sus propias funciones.

# Listar entradas de la SSDT y verificar que apuntan a ntoskrnl.exe
vol3 -f memdump.raw windows.ssdt

Cada entrada debería apuntar a una dirección dentro del rango de ntoskrnl.exe o win32k.sys. Si una entrada apunta a un módulo desconocido o a una dirección fuera de estos rangos, es un hook.

# Entrada normal:
# NtCreateFile  → 0xfffff800`12345678 (ntoskrnl.exe)

# Entrada hookeada:
# NtCreateFile  → 0xfffff880`AABBCCDD (malicious.sys)

En Windows x64 moderno con PatchGuard activo, los SSDT hooks son raros (PatchGuard los detecta y causa BSOD). Pero en análisis de sistemas legacy o donde PatchGuard fue deshabilitado, sigue siendo relevante.

callbacks: enumeración de kernel callbacks

Los rootkits modernos prefieren registrar kernel callbacks legítimos en vez de hookear la SSDT. Windows ofrece mecanismos como PsSetCreateProcessNotifyRoutine, CmRegisterCallback y ObRegisterCallbacks que permiten a drivers recibir notificaciones de eventos del sistema.

# Enumerar callbacks registrados en el kernel
vol3 -f memdump.raw windows.callbacks

Un callback registrado por un driver desconocido (no firmado, sin nombre reconocible, cargado desde una ruta inusual) es sospechoso. Los callbacks legítimos pertenecen a drivers de antivirus, EDR y componentes del SO.

modules vs modscan: drivers ocultos

Igual que con procesos, los drivers del kernel tienen una lista oficial y se pueden buscar por pool tags en toda la memoria.

# Lista oficial de modulos cargados (recorre PsLoadedModuleList)
vol3 -f memdump.raw windows.modules

# Escaneo de pool tags de drivers en toda la memoria
vol3 -f memdump.raw windows.modscan

Un driver que aparece en modscan pero no en modules fue desenlazado de la lista de módulos cargados. Es la misma técnica DKOM aplicada a drivers en vez de procesos.

# Verificar un driver sospechoso
vol3 -f memdump.raw windows.driverscan
# Muestra todos los objetos DRIVER_OBJECT en memoria

malfind: código inyectado

malfind busca regiones de memoria con permisos sospechosos (PAGE_EXECUTE_READWRITE) que contienen código ejecutable. Es el detector de inyección de código por excelencia.

# Buscar regiones de memoria con codigo inyectado
vol3 -f memdump.raw windows.malfind

# Filtrar por PID especifico
vol3 -f memdump.raw windows.malfind --pid 888

malfind identifica:

• Regiones RWX (lectura, escritura, ejecución simultánea) que no están respaldadas por un fichero en disco
• Código ejecutable (detecta encabezados PE, shellcode) en regiones que no deberían contenerlo
• Process hollowing y reflective DLL injection

Una región RWX sin fichero asociado que comienza con MZ (cabecera PE) o con instrucciones de shellcode comunes (fc e8, 31 c0) es altamente sospechosa.

driverirp: IRP hooking

Los drivers de Windows procesan solicitudes mediante IRP (I/O Request Packets). Cada driver tiene una tabla de funciones IRP (MajorFunction array) que determina cómo responde a operaciones como lectura, escritura o control. Un rootkit puede reemplazar estas funciones para interceptar operaciones de I/O.

# Analizar las tablas IRP de todos los drivers
vol3 -f memdump.raw windows.driverirp

Si las funciones MajorFunction de un driver del sistema (por ejemplo, el driver del sistema de ficheros NTFS) apuntan a direcciones fuera de su propio módulo, hay un IRP hook.

apihooks: inline hooking

El inline hooking modifica los primeros bytes de una función para redirigir su ejecución. En vez de cambiar un puntero en una tabla, reescribe el código de la función con un JMP a la función maliciosa.

# Detectar inline hooks en modulos del kernel
vol3 -f memdump.raw windows.apihooks

El plugin compara los primeros bytes de funciones críticas del kernel con los bytes esperados (del fichero en disco). Si detecta un JMP, CALL o secuencia de trampolín que no coincide con el binario original, reporta un hook.

Flujo práctico: cazando un rootkit paso a paso

Esta es la metodología recomendada para una investigación de rootkit con Volatility 3. Orden importa: cada paso informa al siguiente.

Paso 1: Identificar el perfil del sistema

vol3 -f memdump.raw windows.info
# Output: version del SO, arquitectura, KDBG, DTB
# Vol3 auto-detecta, no necesitas especificar perfil manualmente

Paso 2: Análisis cross-view de procesos

# Guardar outputs para comparar
vol3 -f memdump.raw windows.pslist > pslist.txt
vol3 -f memdump.raw windows.psscan > psscan.txt

# Comparar PIDs (buscar procesos solo en psscan)
diff <(awk '{print $1}' pslist.txt | sort) \
     <(awk '{print $1}' psscan.txt | sort)

Paso 3: Verificar integridad del kernel

# SSDT hooks
vol3 -f memdump.raw windows.ssdt > ssdt.txt

# Callbacks sospechosos
vol3 -f memdump.raw windows.callbacks > callbacks.txt

# Drivers ocultos
vol3 -f memdump.raw windows.modscan > modscan.txt
vol3 -f memdump.raw windows.modules > modules.txt

Paso 4: Buscar código inyectado

# Malfind en todos los procesos
vol3 -f memdump.raw windows.malfind > malfind.txt

# Si encontraste un PID sospechoso en paso 2
vol3 -f memdump.raw windows.malfind --pid 888

# Extraer el binario inyectado para analisis con YARA
vol3 -f memdump.raw windows.malfind --pid 888 --dump

Paso 5: Analizar hooks de I/O

# IRP hooks en drivers
vol3 -f memdump.raw windows.driverirp > driverirp.txt

# Inline hooks
vol3 -f memdump.raw windows.apihooks > apihooks.txt

Paso 6: Extraer artefactos del proceso sospechoso

# DLLs cargadas por el proceso oculto
vol3 -f memdump.raw windows.dlllist --pid 888

# Handles abiertos (ficheros, registry keys, mutexes)
vol3 -f memdump.raw windows.handles --pid 888

# Conexiones de red del proceso
vol3 -f memdump.raw windows.netscan | grep 888

# Volcar el ejecutable del proceso
vol3 -f memdump.raw windows.pslist --pid 888 --dump

Paso 7: Correlacionar con reglas YARA

# Escanear la memoria con reglas YARA de rootkits conocidos
vol3 -f memdump.raw yarascan.YaraScan \
  --yara-file rootkit_signatures.yar

# Escanear solo el espacio de kernel
vol3 -f memdump.raw yarascan.YaraScan \
  --yara-file rootkit_signatures.yar --kernel

GMER: escáner de rootkits en vivo para Windows

GMER es una herramienta gratuita de detección de rootkits que opera en un sistema Windows en ejecución. A diferencia de Volatility (que analiza dumps offline), GMER trabaja en vivo: accede directamente a las estructuras del kernel desde el propio sistema potencialmente infectado.

Qué verifica GMER

Componente	Qué busca
SSDT	Entradas hookeadas en la System Service Descriptor Table
IDT	Hooks en la Interrupt Descriptor Table
IRP	Hooks en las tablas IRP de drivers del sistema de ficheros
Inline hooks	Modificaciones de código en funciones del kernel y de drivers
Procesos ocultos	Procesos no visibles para el API de Windows
Threads ocultos	Threads sin proceso padre visible
Ficheros ocultos	Ficheros no visibles para FindFirstFile/FindNextFile
Registry oculto	Claves de registro invisibles para RegEnumKey
Drivers ocultos	Drivers no listados en la enumeración estándar
Servicios ocultos	Servicios no visibles en el Service Control Manager

Uso de GMER

1. Descargar gmer.zip desde gmer.net (renombrar a nombre aleatorio)
2. Ejecutar como administrador
3. Click en "Scan" - escanea todas las categorias
4. Revisar resultados: lineas en ROJO indican modificaciones sospechosas
5. Pestaña "Processes" - comparar con Task Manager
6. Pestaña "Files" - buscar ficheros ocultos en directorios del sistema
7. Pestaña "Registry" - buscar claves ocultas de persistencia

Renombrar el ejecutable antes de ejecutarlo es importante: algunos rootkits monitorizan la creación de procesos con nombre gmer.exe y se desactivan o bloquean su ejecución.

Ventajas de GMER

• No requiere crear un dump de memoria (útil cuando no puedes extraer un dump)
• Interfaz gráfica simple que marca anomalías en rojo
• Detección en tiempo real de las técnicas más comunes
• Gratuito y portable (no requiere instalación)

Limitaciones de GMER

• Opera dentro del sistema comprometido: el rootkit puede detectar y bloquear GMER
• No funciona en sistemas x64 modernos con Secure Boot activo (requiere driver sin firmar)
• Un rootkit sofisticado puede "desactivarse" al detectar la carga del driver de GMER
• No detecta rootkits de firmware o hypervisor (operan por debajo del kernel)
• Última actualización oficial hace años, soporte limitado para kernels recientes de Windows

Por estas limitaciones, GMER es un complemento, no un sustituto del análisis forense con Volatility.

Herramientas complementarias

RootkitRevealer (Sysinternals)

Herramienta clásica de Mark Russinovich que compara los resultados de las APIs de alto nivel del SO con acceso directo al sistema de ficheros (parseo raw de NTFS) y al registro (parseo raw de hives). Las discrepancias revelan ocultación.

Limitaciones: descontinuada, solo 32-bit, no funciona en Windows modernos. Pero el concepto de cross-view analysis que implementó sigue siendo la base de toda detección de rootkits.

Reglas YARA para rootkits

YARA permite escribir firmas que detectan patrones de bytes, strings y estructuras en memoria o disco. Para rootkits, las reglas buscan:

rule Rootkit_DKOM_Unlink {
    meta:
        description = "Detecta patron de unlink de EPROCESS"
        author = "MalwareIntel Research"
        reference = "T1014 - Rootkit"

    strings:
        // Patron tipico de DKOM: mov [eax], ecx ; mov [ecx+4], eax
        // (reescribir Flink y Blink de la lista enlazada)
        $unlink_32 = { 89 08 89 41 04 }
        $unlink_64 = { 48 89 08 48 89 41 08 }

        // Strings comunes en drivers de rootkit
        $s1 = "\\Device\\devapi" wide
        $s2 = "NtQuerySystemInformation" ascii
        $s3 = "ActiveProcessLinks" ascii

    condition:
        uint16(0) == 0x5A4D and
        (any of ($unlink_*)) and
        (2 of ($s*))
}

Las reglas YARA se integran directamente con Volatility via el plugin yarascan.

Análisis cross-view: el concepto central

Toda la detección de rootkits se basa en un principio: comparar la misma información obtenida por dos métodos diferentes.

Metodo 1 (alto nivel):    API del SO → ve lo que el rootkit permite
Metodo 2 (bajo nivel):    Acceso directo a memoria/disco → ve la realidad

Discrepancia = evidencia de ocultacion

Aplicaciones concretas del cross-view:

Vista alta (comprometible)	Vista baja (fiable)	Rootkit detectado
pslist (lista enlazada)	psscan (pool tags)	DKOM en procesos
modules (PsLoadedModuleList)	modscan (pool tags)	DKOM en drivers
SSDT (tabla actual)	ntoskrnl.exe en disco	SSDT hooking
FindFirstFile (API)	parseo raw NTFS	Ocultación de ficheros
RegEnumKey (API)	parseo raw de hive	Ocultación de registro
EnumDeviceDrivers (API)	MmUnloadedDrivers	Drivers descargados

Ejemplo: detectando un rootkit DKOM paso a paso

Escenario: un analista SOC recibe una alerta de tráfico C2 desde una estación de trabajo. El Task Manager no muestra procesos sospechosos. Se captura un dump de memoria.

# 1. Identificar el sistema
vol3 -f workstation.raw windows.info
# Windows 10 x64 Build 19045

# 2. Listar procesos (vista "oficial")
vol3 -f workstation.raw windows.pslist
# PID  PPID  Name           CreateTime
# 4    0     System         2026-05-20 08:00:01
# 324  4     smss.exe       2026-05-20 08:00:03
# 420  324   csrss.exe      2026-05-20 08:00:05
# 680  420   services.exe   2026-05-20 08:00:06
# 1024 680   svchost.exe    2026-05-20 08:00:10
# 2048 1024  explorer.exe   2026-05-20 08:15:22
# (... procesos normales)

# 3. Escanear TODA la memoria por procesos
vol3 -f workstation.raw windows.psscan
# PID  PPID  Name           CreateTime
# (... mismos que arriba, MAS:)
# 3312 2048  svchst.exe     2026-05-20 14:33:47
#
# PID 3312 NO aparece en pslist → DKOM confirmado
# Nombre "svchst.exe" imita a "svchost.exe" (typosquatting)

# 4. Investigar el proceso oculto
vol3 -f workstation.raw windows.dlllist --pid 3312
# DLLs cargadas: ntdll.dll, kernel32.dll, ws2_32.dll (networking)
# DLL sospechosa: C:\ProgramData\update\core.dll

vol3 -f workstation.raw windows.handles --pid 3312
# Handle 0x1A4: \Device\Tcp (conexion de red activa)
# Handle 0x1B8: \REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
#               (persistencia en registro)

vol3 -f workstation.raw windows.netscan | grep 3312
# Proto  LocalAddr        ForeignAddr        State    PID
# TCPv4  192.168.1.50:443 185.220.101.4:8443 ESTAB   3312
# → Conexion C2 confirmada

# 5. Buscar el driver del rootkit
vol3 -f workstation.raw windows.modscan
# (comparar con modules: driver "updsvc.sys" solo en modscan)
# Base: 0xfffff880`11223344  Size: 0x8000  Path: \??\C:\Windows\Temp\updsvc.sys

# 6. Extraer artefactos para analisis posterior
vol3 -f workstation.raw windows.malfind --pid 3312 --dump
vol3 -f workstation.raw windows.pslist --pid 3312 --dump

# 7. Escanear con YARA
vol3 -f workstation.raw yarascan.YaraScan \
  --yara-file rootkit_signatures.yar --pid 3312

Resultado: rootkit con componente DKOM que oculta tanto el proceso (svchst.exe) como su driver (updsvc.sys). Conexión C2 activa a 185.220.101.4:8443. Persistencia via clave de registro Run.

Mapeo MITRE ATT&CK (perspectiva defensiva)

Técnica	ID	Detección con Volatility/GMER
Rootkit	T1014	pslist vs psscan, modules vs modscan, GMER scan completo
Process Injection	T1055	malfind (regiones RWX sin fichero)
Hooking	T1056.004	ssdt, apihooks, driverirp, GMER SSDT/IRP tabs
Hide Artifacts	T1564	Cross-view analysis (ficheros, registro, procesos)
Modify System Process	T1543	callbacks (notify routines maliciosas)
BYOVD	T1068	driverscan (drivers vulnerables conocidos cargados)
Deobfuscate/Decode	T1140	malfind + YARA (detectar payloads decodificados en memoria)

Recomendaciones para equipos SOC

1. Tener Volatility 3 preinstalado en las estaciones de análisis forense. No esperar al incidente para configurar la herramienta.
2. Mantener un repositorio actualizado de tablas de símbolos ISF para las versiones de Windows desplegadas en la organización.
3. Automatizar la comparación pslist vs psscan como parte de todo triage de memoria.
4. Integrar reglas YARA específicas de rootkits en el pipeline de análisis.
5. Documentar el baseline de drivers y callbacks legítimos de la organización. Sin un baseline limpio, distinguir lo legítimo de lo malicioso es mucho más difícil.
6. Usar GMER como herramienta de triaje rápido cuando no sea viable capturar un dump completo, pero nunca como única herramienta de análisis.

Fuentes y lecturas adicionales

• Ligh, M.H. et al. The Art of Memory Forensics. Wiley, 2014. La referencia definitiva sobre análisis forense de memoria con Volatility.
• Matrosov, A. et al. Rootkits and Bootkits. No Starch Press, 2019. Cobertura completa de técnicas de rootkit y bootkit con detección.
• Volatility Foundation y repositorio GitHub Volatility3. Documentación oficial y código fuente.
• GMER. Herramienta de detección de rootkits en vivo para Windows.
• MITRE ATT&CK, técnica T1014: Rootkit. Descripción de la técnica y procedimientos de detección.
• Russinovich, M. Windows Internals. Microsoft Press. Referencia sobre las estructuras internas del kernel de Windows que los rootkits manipulan.