5.5 · Forense de memoria

8 min de lectura · blue-team / memoria-forense / dfir-forense / malware-analysis / incident-response · ⎙ PDF

Panorama#

El bloque rojo dejó dos técnicas que derrotan por diseño al análisis de disco. La evasión de AV/EDR (3.11) mostró el malware fileless, que ejecuta en RAM sin escribir un ejecutable, de modo que el antivirus que escanea archivos no ve nada; y la persistencia en Linux (3.14) mostró los rootkits, que manipulan las estructuras del sistema operativo para ocultarse de las herramientas del propio host. Contra ambas, hay un lugar donde no pueden esconderse: la memoria. Para ejecutar, el código tiene que estar en RAM; para ocultar un proceso, el rootkit tiene que dejar la evidencia de la manipulación en las estructuras del kernel. El forense de memoria es la disciplina que lee ese estado, y es el quinto y último de los capítulos-fundamento de P5 —tras el marco (5.1), la telemetría (5.2), la identidad (5.3) y la respuesta (5.4)—.

Su premisa es la volatilidad: la memoria pierde su contenido en cuanto se corta la energía o se reinicia el equipo. Todo lo que vive solo ahí —los procesos activos, las conexiones de red establecidas, el historial de la consola, las credenciales temporales en claro, el código inyectado sin archivo— desaparece con el apagado y es irrecuperable desde un disco estático. De ahí el principio operativo que 5.4 ya adelantó como regla del triaje: capturar la RAM en vivo, antes de aislar o apagar el equipo. Es el eslabón más alto del orden de volatilidad, y equivale, del lado forense, a la cadena de custodia que el método OSINT (2.1) exigía sobre la evidencia: sin captura no hay caso.

flowchart LR
  ACQ["Adquisición en vivo\n(Belkasoft RAM Capturer →\nimagen raw/hiberfil/crash)"] --> PROF["Perfil\n(imageinfo · kdbgscan →\nWin7SP1x64)"]
  PROF --> HID["Procesos ocultos\n(pslist vs psscan ·\npsxview)"]
  PROF --> INJ["Código inyectado\n(malfind · dlldump)"]
  PROF --> NET["Canal de red\n(netscan)"]
  PROF --> CRED["Credenciales\n(hashdump · lsadump ·\ncmdscan)"]
  INJ & HID --> DUMP["procdump / memdump →\ndisco"]
  DUMP -.->|"análisis estático / reversing"| C58["5.8"]
  classDef n fill:#1e293b,stroke:#475569,color:#e2e8f0;
  class ACQ,PROF,HID,INJ,NET,CRED,DUMP,C58 n;

Adquisición: capturar lo frágil sin corromperlo#

La adquisición es la fase más delicada porque el acto de recolectar altera lo recolectado. La memoria de un sistema encendido cambia de continuo —cada proceso rutinario escribe sobre regiones que pueden contener los artefactos que se buscan—, de modo que la captura debe transferir el contenido a un almacenamiento persistente con la mínima interacción posible; un análisis de RAM solo es válido si la imagen se tomó sin corromper el estado original. En la práctica se usa una herramienta dedicada de adquisición en vivo —Belkasoft RAM Capturer, entre otras— que vuelca el estado completo a una imagen, la cual luego se lleva a una estación forense aislada (por ejemplo Kali) para el análisis. Volatility acepta varios formatos de entrada, y conviene conocerlos porque a veces la memoria ya está capturada sin haberla tomado a propósito: el volcado crudo (raw, copia binaria exacta), el archivo de hibernación del sistema (hiberfil.sys), el snapshot de una máquina virtual y el crash dump de Microsoft. Cada uno es una foto de la RAM en un instante; la disciplina es tomarla antes de que el reinicio la borre.

Volatility: perfilar el sistema y desenmascarar lo oculto#

El análisis se hace con Volatility, el framework de referencia, y su primer paso es perfilar la imagen: determinar la arquitectura y la versión exacta del sistema operativo, porque Volatility interpreta las estructuras de datos del kernel según ese perfil y un perfil errado invalida todo el análisis. Los plugins imageinfo y kdbgscan leen la imagen y sugieren el perfil (por ejemplo Win7SP1x64), que se pasa a todos los comandos siguientes.

Con el perfil fijado, la técnica más importante de todo el capítulo es una triangulación: contrastar dos vistas de la lista de procesos. El plugin pslist recorre la lista doblemente enlazada que el kernel mantiene de sus procesos —la misma que consultan tasklist o el Administrador de tareas—. El plugin psscan, en cambio, escanea la memoria física buscando las firmas (pool tags) de las estructuras de proceso, sin confiar en ninguna lista. La diferencia es decisiva: un rootkit que oculta un proceso lo hace desenlazándolo de la lista del kernel —la manipulación que 3.14 describió para lsmod—, de modo que desaparece de pslist pero sigue apareciendo en psscan, porque la estructura sigue en memoria. Un proceso que está en psscan y no en pslist es, casi por definición, algo que quiso esconderse (o un proceso ya terminado). El plugin psxview automatiza esta comparación cruzando varias fuentes a la vez. Es la verificación desde fuera que 3.14 nombró como la única defensa fiable contra un rootkit, materializada sobre un volcado estático que el rootkit ya no controla.

# 1) Perfilar la imagen (imprescindible: un perfil errado invalida el análisis):
volatility -f ram.mem imageinfo
volatility -f ram.mem kdbgscan # → Win7SP1x64
# 2) Triangular procesos: la lista del kernel (pslist) vs el escaneo de memoria (psscan)
volatility -f ram.mem --profile=Win7SP1x64 pslist # lo que el SO "admite"
volatility -f ram.mem --profile=Win7SP1x64 psscan # lo que hay de verdad (incl. ocultos)
volatility -f ram.mem --profile=Win7SP1x64 psxview # cruza ambas listas automáticamente

Cazar el código inyectado, el canal y las credenciales#

Localizado lo sospechoso, un segundo grupo de plugins extrae la evidencia concreta. El más directo contra la inyección es malfind, que busca regiones de memoria ejecutables sin un archivo de respaldo en disco —típicamente páginas marcadas RWX (lectura/escritura/ejecución) que no corresponden a ningún módulo cargado—: es exactamente la firma del thread injection y del VirtualAlloc con permisos 0x40 que la evasión de 3.11 usaba para correr shellcode en un proceso legítimo, vista ahora desde el volcado. Para la biblioteca inyectada, dlllist enumera los módulos de un proceso y dlldump los extrae para analizarlos. El canal de red se recupera con netscan, que lista las conexiones y puertos —el beacon del C2 (3.10) que no dejó rastro en disco pero mantenía una conexión establecida—. Y las credenciales en memoria salen con hivelist (ubica las colmenas del registro) más hashdump y lsadump: es el otro lado del volcado de LSASS (4.5) —donde el atacante extraía los hashes de la memoria con Mimikatz, el forense los recupera del mismo lugar para saber qué credenciales quedaron expuestas—. El historial de la consola local se reconstruye con cmdscan. Finalmente, todo binario o región sospechosa se extrae intacto al disco con procdump y memdump, para su disección estática posterior —el puente directo con el análisis de malware (5.8), que trabaja sobre esas muestras sin ejecutarlas—.

La regla mental del forense de memoria: el disco dice lo que el atacante dejó; la RAM dice lo que está ejecutando. Un binario cifrado o empaquetado se ve ininteligible en disco, pero en memoria tuvo que desempaquetarse para correr —por eso malfind y memdump a menudo recuperan la carga en claro que el análisis estático no podía leer—. Es la misma razón por la que el 4104 de PowerShell (5.2) capturaba el script desofuscado: en el punto de ejecución, el malware no puede seguir escondido.

La interfaz gráfica y las estructuras profundas#

Para el analista que arranca, Volatility Workbench (de PassMark) ofrece una interfaz gráfica que evita memorizar la sintaxis: se carga la imagen, se elige el perfil de un menú, y se ejecutan los plugins con botones, con la ventaja añadida de exportar la salida a disco y registrar la marca de tiempo de cada comando —trazabilidad útil para el informe forense y la cadena de custodia—. Más allá de replicar el catálogo de consola, la herramienta facilita el acceso a plugins de estructuras profundas del kernel que persiguen la persistencia avanzada: vadinfo/vadtree recorren los descriptores de memoria virtual (VAD) que mapean las regiones de un proceso, mftparser reconstruye marcas de tiempo desde la tabla maestra de archivos, y ssdt inspecciona la tabla de despacho de servicios del sistema —la System Service Descriptor Table—, precisamente la que un rootkit de kernel engancha para interceptar syscalls, como describió 3.14. Leer la SSDT desde el volcado revela los enganches que el rootkit instaló para mentirle al sistema en vivo.

Cierre: donde lo invisible se vuelve visible#

El forense de memoria es el punto donde las dos grandes evasiones del bloque rojo pierden su ventaja. El fileless ganó contra el escaneo de disco porque nunca escribió un archivo, pero tuvo que residir en RAM para ejecutar, y ahí malfind lo encuentra. El rootkit ganó contra las herramientas del host porque manipuló sus listas, pero la estructura sigue en memoria, y ahí psscan lo delata. Por eso este capítulo es el complemento necesario de la telemetría de 5.2: los Event Logs registran lo que el sistema reportó, la memoria muestra lo que el sistema era en el instante de la captura, incluso lo que un atacante le ocultó al propio sistema. Encaja como una pieza precisa del ciclo de respuesta: la captura de RAM es el primer movimiento del triaje de 5.4 (antes de aislar), y los binarios que memdump extrae son la entrada del análisis de malware (5.8). Con esto quedan cerrados los cinco fundamentos de P5 —el marco, la telemetría, la identidad, la respuesta y el forense—; los seis capítulos siguientes (5.6 a 5.11) aplican todo este instrumental a las técnicas concretas que el bloque rojo dejó apuntadas.

Referencias#

blue-dfir/memoryforensic/cap-03 — Fundamentos: el orden de volatilidad, las amenazas que viven en memoria (rootkits, fileless, inyección), la adquisición en vivo con Belkasoft RAM Capturer y los formatos de volcado (raw, hiberfil, VM snapshot, crash dump).
blue-dfir/memoryforensic/cap-04 — Volatility Framework: el perfilado con imageinfo/kdbgscan, la triangulación pslist vs psscan, y los plugins de extracción (dlllist/dlldump, netscan, hivelist/hashdump/lsadump, cmdscan, procdump/memdump).
blue-dfir/memoryforensic/cap-05 — Volatility Workbench: la interfaz gráfica, el registro con marcas de tiempo para la trazabilidad, y los plugins de estructuras profundas (malfind, psxview, vadinfo/vadtree, mftparser, ssdt).
The Volatility Foundation — el framework de referencia (Volatility 3 como versión actual) y su documentación de plugins.

Mencionado en

0.3 · Sistemas operativos: privilegio, procesos y aislamientoEl sustrato de ejecución sobre el que corre todo lo demás. El sistema operativo tiene una sola misión de seguridad: administrar el privilegio y hacer cumplir el aislamiento, de modo que un programa no pueda hacer lo que no le corresponde ni tocar lo que no es suyo. Este capítulo explica la frontera primaria —la que separa el núcleo (kernel), que manda sobre el hardware, del espacio de usuario, donde corren los programas— y por qué esa frontera es la línea que la escalada de privilegios busca cruzar. Recorre el modelo de privilegio de Windows (los identificadores de seguridad, los tokens de acceso, los niveles de integridad, el control de cuentas de usuario y el papel central del proceso que custodia las credenciales, LSASS) y el de Linux (usuarios y grupos, los bits de permiso, el conjunto de capabilities que fragmenta el poder de root, el bit setuid, los espacios de nombres que aíslan contenedores y la interfaz de llamadas al sistema como la puerta entre el usuario y el núcleo). El hilo que une todo es el privilegio como la abstracción central: comprenderlo es comprender por qué la escalada, el volcado de credenciales y la evasión son variaciones de un mismo movimiento —conseguir más autoridad de la otorgada, o esconderse de quien la vigila—. No rehace el volcado de credenciales de la Parte 4 ni la escalada de la Parte 3: nombra la arquitectura de privilegio que ambos presuponen.
1.6 · El panorama de amenazas: actores, cibercrimen e IAEl producto estratégico del ciclo, y el único capítulo del manual con fecha de vencimiento. Antes que las cifras —que caducan— desarrolla cómo se lee un informe de panorama sin heredar el sesgo de visibilidad de quien lo publica, y luego las tres direcciones del cambio en 2025-2026: acceso sin malware, ejecución sin binario propio e industrialización del intermediario. Cierra con lo que no cambió, que suele ser lo más caro, y con el cierre de la Parte 1.
5.1 · El programa de defensa: detección y threat huntingEl capítulo-marco que abre P5 y da vuelta el manual: del atacante que necesita todos los eslabones al defensor que solo necesita fallar uno. La defensa no es una suma de herramientas sino un programa activo de funciones que interoperan —inteligencia, detección, respuesta, validación, cacería y control— bajo el mismo supuesto de compromiso que gobierna al atacante. Su tesis operativa: la detección se construye por comportamiento (TTP), no por artefacto atómico (la pirámide del dolor de Bianco), y la cacería dirigida por hipótesis retroalimenta la detección en un ciclo cerrado (hunt-to-detection). Es el espejo azul de la metodología de pentest (3.1) y del método OSINT (2.1).
5.4 · Respuesta a incidentes y recuperaciónEl destino de toda detección o cacería confirmada: la función Respond del programa de defensa. El capítulo desarrolla el ciclo de respuesta a incidentes del NIST —preparación, detección/análisis, contención/erradicación/recuperación, post-incidente— alrededor de una tesis sobre el tempo: la remediación prematura, ejecutada antes de acotar el alcance, alerta al adversario y desata un juego de whack-a-mole que prolonga el incidente y facilita la reinfección. Distingue la remediación táctica (contener, restaurar, erradicar) de la estratégica (los cambios arquitectónicos que impiden repetir la intrusión), aborda la particularidad de la respuesta en la nube (la responsabilidad compartida limita el acceso a la evidencia) y cierra con la recuperación: sin un plan de DR/BCP con backups offline, el ransomware gana. Es la función que 5.1 nombró y donde converge la telemetría de 5.2, la contención de identidad de 5.3 y el forense de 5.5.
5.6 · Detección de movimiento lateral en el SIEMEl primero de los seis capítulos que cierran, desde el lado azul, las técnicas del bloque rojo. El movimiento lateral es la fase que convierte un equipo comprometido en una red comprometida, y no puede ejecutarse en silencio: toda ejecución remota en Windows deja un rastro característico —un inicio de sesión de red, un servicio recién instalado, un recurso administrativo tocado, un proceso hijo que no corresponde—. Recorre la telemetría de cada vía (PsExec y admin shares, WMI y WinRM, RDP, pass-the-hash) insistiendo en la regla que las une: el evento se lee correlacionando origen y destino, nunca en una máquina sola. Cierra con la contracara arquitectónica —la segmentación reduce el blast radius y obliga al tráfico este-oeste a cruzar un punto donde se lo puede ver— y con los dos casos donde el lateral es el punto de detección final. Es el espejo azul de 4.8, 4.9 y 3.13.
5.8 · Análisis de malware y detección de evasiónLa respuesta azul a la evasión de 3.11, y el capítulo con más hilos entrantes de P5. Su tesis es una distinción que ordena todo lo demás: la evasión gana contra la firma, no contra el comportamiento, porque para ejecutar el código tiene que desempaquetarse, tocar el sistema y comunicarse. Recorre el laboratorio propio y su hardening contra las comprobaciones anti-VM, la cadena estático→dinámico→unpacking→reversing, y el punto donde el análisis deja de escalar: el código virtualizado. De ahí sale el segundo movimiento, el más incómodo y el más útil: medir empíricamente qué detecta el sensor propio en lugar de creerle a la hoja de producto —cuatro pruebas documentadas encuentran ventanas de horas, formatos contenedor ignorados y cadenas de LOLBins no correlacionadas—. Incluye el análisis del artefacto de acceso inicial —documentos y scripts maliciosos: la desofuscación de JS/VBA y macros con box-js, pdf-parser y oledump, y la emulación de shellcode con scdbg—, que es la ilustración más pura de la tesis (el script tiene que desofuscarse para correr) y dice qué aristas padre-hijo alertar. Cierra con la otra cara de la fatiga de alertas: el falso positivo heredado de una reputación ajena. Cierra 3.11 y 2.6.
5.10 · Detección de persistencia en LinuxEl espejo azul de 3.14. La persistencia tiene una debilidad que la exfiltración y el C2 no tienen: deja un artefacto quieto en disco, y los disparadores que el sistema honra son finitos, por lo tanto enumerables. De ahí que la detección sea auditoría de un conjunto acotado contra una línea base, y no persecución de un comportamiento fugaz. Recorre la telemetría nativa de Linux y su hueco más grande —no hay auditoría de creación de procesos por defecto—, auditd y AIDE con sus límites honestos, la señal que rinde en cada familia de disparador, y la verificación de paquetes como línea base criptográfica gratuita. Cierra con el caso donde la regla se invierte: cuando el host miente, hay que observarlo desde fuera. Cierra 3.14.
5.11 · Detección en runtime de contenedoresEl espejo azul de 3.16 y el capítulo que cierra P5. El contenedor de propósito único invierte el problema que hacía caro todo lo anterior: su comportamiento permitido es tan pequeño y está tan declarado que la línea base deja de ser un proyecto y pasa a derivarse de la definición del workload. Sobre esa ventaja se apoya el IDS de runtime por eBPF, con sus tres límites honestos. Pero el sensor de host solo cubre la mitad: el adversario que roba un token de service account no ejecuta nada en ningún nodo, y ahí el audit log del API server pasa de complemento a fuente primaria. Cierra con lo que la efimeridad le hace al forense y con la propiedad más aprovechable del modelo: en Kubernetes el ataque se declara antes de ejecutarse. Cierra 3.16 y la Parte 5.
5.12 · Detección de rootkits: integridad de kernel y arranqueA un rootkit no se le pregunta si está: posee el árbitro que respondería. Este capítulo consolida las dos detecciones que P5 ya construyó —el forense de memoria de 5.5 para la vista cruzada en Windows y la detección de persistencia de 5.10 para Linux— y añade lo que ninguno alcanza: la escalera de profundidad completa hasta el firmware, el vector de entrada al anillo 0 que domina hoy (BYOVD, cargar un driver firmado pero vulnerable), y la arquitectura de integridad que es la única defensa que gana. La tesis es incómoda pero clarificadora: contra un adversario que reside en la capa donde corren las herramientas de inspección, la respuesta no es detección sino diseño —negar el punto de observación (HVCI/VBS mueve el árbitro por debajo del kernel), controlar quién entra al anillo 0 (lista de drivers bloqueados) y anclar el arranque en el hardware (Secure Boot + arranque medido + TPM)—; y donde la detección todavía aplica, tiene que venir desde abajo o desde afuera del rootkit, nunca del host que este ya controla.