Forense de Memoria con Volatility 3 en Linux

🎯

Objetivos del Laboratorio

¿Qué vas a aprender y practicar?

Este laboratorio práctico te guiará a través del proceso completo de análisis forense de memoria RAM en sistemas Linux utilizando Volatility 3, el framework de análisis de memoria más utilizado en el mundo de la ciberseguridad defensiva y la respuesta a incidentes.

Al finalizar todos los ejercicios serás capaz de:

Capturar un volcado de memoria de un sistema Linux en vivo
Configurar correctamente Volatility 3 con las tablas de símbolos del kernel
Identificar y analizar procesos en ejecución, incluyendo procesos ocultos o sospechosos
Extraer y analizar conexiones de red activas en el momento del volcado
Examinar módulos del kernel para detectar rootkits y código malicioso
Detectar artefactos de malware mediante análisis de memoria y reglas YARA
Recuperar historial de comandos de bash y artefactos de navegadores web

📌 IMPORTANTE — VERSIÓN UTILIZADAEste laboratorio usa Volatility 3, la versión moderna y actualmente mantenida. Los comandos son completamente diferentes a Volatility 2 (legacy). Si encuentras guías antiguas que usan --profile=LinuxXxx, están desactualizadas. Volatility 3 determina el perfil automáticamente mediante tablas de símbolos JSON.

FASE 1Setup

FASE 2Captura

FASE 3Procesos

FASE 4Red

FASE 5Kernel

FASE 6Malware

FASE 7Artefactos

🧠

Teoría: Forense de Memoria RAM

Conceptos fundamentales antes de comenzar

💡¿POR QUÉ ANALIZAR LA MEMORIA?

La memoria RAM es una fuente de evidencia volátil e irrepetible. A diferencia del disco duro, los datos en RAM desaparecen cuando el sistema se apaga. Un análisis forense de memoria puede revelar:

Malware sin archivos (fileless malware): código malicioso que nunca toca el disco, solo existe en RAM
Procesos ocultos: rootkits que manipulan las estructuras del kernel para ocultar procesos
Credenciales en texto plano: contraseñas, tokens de sesión, claves de cifrado activas
Conexiones de red efímeras: canales C2 (Command & Control) activos en el momento del volcado
Comandos ejecutados: historial de bash, comandos de shells de atacantes
Módulos del kernel comprometidos: rootkits a nivel de kernel, hooks maliciosos
Artefactos de navegación: URLs visitadas, credenciales, cookies de sesión activas

🔬VOLATILITY 3 — ARQUITECTURA Y CAMBIOS RESPECTO A V2

Volatility 3 (publicado en 2020) supone una reescritura completa del framework. Los cambios más importantes son:

Característica	Volatility 2 (legacy)	Volatility 3 (actual)
Lenguaje	Python 2	Python 3 nativo
Identificación del OS	Perfil manual (`--profile=LinuxXxx`)	Automático mediante tablas de símbolos JSON (ISF)
Sintaxis de plugins	`linux_pslist`	`linux.pslist.PsList` (o `linux.pslist`)
Velocidad	Media	Significativamente más rápida
Mantenimiento	Abandonado (última versión: 2.6.x)	Activo — versión actual 2.x
Soporte Linux	Requiere compilar perfil manualmente	ISF Server con perfiles precompilados

⚠ ADVERTENCIA IMPORTANTEEl laboratorio original en GitHub que sirve de base usa comandos de Volatility 2 que ya no funcionan en Volatility 3. Todos los ejercicios de este manual han sido corregidos y actualizados para Volatility 3.

🏗️ESTRUCTURA DE UN VOLCADO DE MEMORIA Y LO QUE PODEMOS EXTRAER

Un volcado de memoria (memory image) es una copia bit a bit del contenido de la RAM en un instante dado. Volatility 3 lo analiza buscando estructuras conocidas del kernel Linux:

task_struct: estructura del kernel que representa cada proceso (base de linux.pslist)
files_struct: descriptores de archivos abiertos por cada proceso
sock / inet_sock: estructuras de sockets de red activos
module: lista enlazada de módulos del kernel cargados
Páginas de memoria de cada proceso: código, datos, pila, heap

📋

Prerrequisitos y Entorno de Laboratorio

Lo que necesitas antes de empezar

🖥️ENTORNO RECOMENDADO

Para este laboratorio necesitarás:

Sistema operativo: Ubuntu 22.04 LTS o Debian 12 (se recomienda máquina virtual o laboratorio aislado)
Python 3.8 o superior (incluido por defecto en Ubuntu 22.04)
Espacio en disco: mínimo 10 GB libres para el volcado de memoria y análisis
RAM del sistema anfitrión: al menos 4 GB recomendados para analizar volcados de otros sistemas
Conexión a Internet: para descargar Volatility 3 y las tablas de símbolos
Permisos de superusuario (sudo) para capturar memoria del sistema

Opcionalmente, puedes trabajar con un volcado de memoria de práctica. Más adelante se indica cómo obtener imágenes de ejemplo para CTF y formación.

📚CONOCIMIENTOS PREVIOS RECOMENDADOS

Manejo fluido de la terminal Linux (comandos básicos, redirección, pipes)
Conceptos de gestión de procesos en Linux (PID, PPID, estados de proceso)
Fundamentos de redes TCP/IP (puertos, sockets, estados de conexión)
Nociones básicas de la arquitectura del kernel Linux (espacio de usuario vs. espacio de kernel)
Comprensión de qué es un módulo del kernel y para qué sirve

💡 PARA CLASESi no tienes un sistema Linux comprometido disponible, puedes descargar imágenes de memoria de práctica de repositorios como MemLabs (github.com/stuxnet999/MemLabs) o los challenges de CyberDefenders y BlueTeamLabs Online que incluyen volcados de Linux para analizar.

⚙️

Instalación de Volatility 3

Dos métodos: pip o desde el código fuente

📌 NOTASe recomienda instalar Volatility 3 desde el repositorio oficial de GitHub para tener la versión más actualizada con todos los plugins. La versión de pip puede estar desfasada.

Actualizar el sistema e instalar dependencias base PREPARACIÓN

Antes de instalar Volatility 3, asegúrate de que el sistema está actualizado e instala las dependencias necesarias.

BASH — Actualizar sistema e instalar deps

# Actualizar listas de paquetes
sudo apt update && sudo apt upgrade -y

# Instalar Python 3, pip y dependencias necesarias
sudo apt install -y python3 python3-pip python3-venv git
sudo apt install -y python3-dev libssl-dev

Clonar el repositorio oficial de Volatility 3 DESCARGA

Clona el repositorio oficial desde GitHub para obtener la versión más reciente con todos los plugins actualizados.

BASH — Clonar Volatility 3

# Clonar el repositorio oficial
git clone https://github.com/volatilityfoundation/volatility3.git
cd volatility3

# Ver la versión
python3 vol.py --version

✅ ALTERNATIVA: Instalar via pipSi prefieres una instalación más rápida: pip3 install volatility3 — aunque puede no incluir los últimos plugins.

Instalar las dependencias de Python DEPENDENCIAS

BASH — Instalar requirements

# Instalar dependencias desde el archivo requirements
pip3 install -r requirements.txt

# O instalar manualmente las principales
pip3 install pefile capstone yara-python

Verificar la instalación listando los plugins disponibles VERIFICACIÓN

BASH — Verificar instalación

# Desde el directorio volatility3/
python3 vol.py --help

# Listar todos los plugins de Linux disponibles
python3 vol.py --help 2>&1 | grep 'linux\.'

🔑

Tablas de Símbolos del Kernel (ISF)

El paso más crítico — sin esto, Volatility 3 no puede analizar imágenes Linux

⚠ CONCEPTO CLAVE — OBLIGATORIO ENTENDEREn Volatility 3, las tablas de símbolos (ISF — Intermediate Symbol Files) reemplazan al concepto de 'perfil' de Volatility 2. Son archivos JSON comprimidos (.json.xz) que describen la estructura interna del kernel Linux específico del sistema analizado. Sin la tabla de símbolos correcta, Volatility 3 no puede analizar una imagen de Linux.

⬇️MÉTODO 1 — DESCARGAR TABLA PRECOMPILADA (recomendado)

BASH — Descargar tabla de símbolos (método automático)

# Primero, averigua la versión exacta del kernel
uname -a
# Ejemplo de salida: Linux ubuntu 5.15.0-91-generic #101-Ubuntu SMP ...

# Volatility 3 intentará descargarla automáticamente.
# Si no lo hace, búscala en el servidor ISF:
# https://isf-server.techanarchy.net/

# Descarga manual y colocación:
mkdir -p ~/volatility3/volatility3/symbols/linux

# Descarga el archivo .json.xz para tu versión de kernel
# y colócalo en el directorio symbols/linux:
wget -P ~/volatility3/volatility3/symbols/linux/ \
  https://isf-server.techanarchy.net/download/ubuntu/<tu-version-kernel>.json.xz

🔨MÉTODO 2 — GENERAR LA TABLA MANUALMENTE (si no existe precompilada)

💡 CUÁNDO USAR ESTE MÉTODOSi el kernel es personalizado, muy reciente, o no está en el servidor ISF, hay que generar la tabla de símbolos desde el propio sistema.

BASH — Generar tabla de símbolos desde el kernel actual

# En el sistema CUYA memoria vas a analizar:

# 1. Instalar dwarf2json
git clone https://github.com/volatilityfoundation/dwarf2json.git
cd dwarf2json
go build -o dwarf2json main.go  # Requiere Go instalado

# 2. Instalar debug symbols del kernel
sudo apt install linux-image-$(uname -r)-dbgsym

# 3. Generar el archivo ISF
sudo ./dwarf2json linux \
  --elf /usr/lib/debug/boot/vmlinux-$(uname -r) \
  > ~/linux-$(uname -r).json

# 4. Comprimir y mover al directorio de Volatility 3
xz ~/linux-$(uname -r).json
mv ~/linux-$(uname -r).json.xz \
  ~/volatility3/volatility3/symbols/linux/

❓ Pregunta de comprensión

¿Por qué Volatility 3 necesita tablas de símbolos específicas para cada versión del kernel Linux, mientras que en Windows puede funcionar con menos configuración?

💡 Pista: Piensa en las diferencias entre cómo se distribuye Windows vs cómo se compila el kernel Linux en cada distribución.

Ver respuesta

El kernel de Windows tiene una estructura relativamente homogénea entre versiones. Linux, en cambio, es compilado de forma diferente por cada distribución (Ubuntu, Debian, CentOS...) e incluso cada actualización puede cambiar las offsets de las estructuras internas. Las tablas de símbolos ISF codifican exactamente dónde están cada estructura (task_struct, sock, etc.) en ese kernel específico, algo que varía con cada compilación.

🔬

Ejercicio 1 — Captura de un Volcado de Memoria

Objetivo: obtener una imagen forense de la RAM del sistema

⚠ IMPORTANTE — VOLATILITY 3 NO CAPTURA MEMORIAVolatility 3 es exclusivamente una herramienta de análisis. La captura de memoria requiere una herramienta separada. A continuación se presentan las opciones más comunes para Linux.

Antes de poder analizar la memoria, necesitamos obtener un volcado (imagen) de la RAM del sistema objetivo. Existen varias herramientas para hacerlo en Linux.

Opción A — LiME (Linux Memory Extractor) — Método recomendado MÓDULO DEL KERNEL

LiME es el estándar de facto para captura de memoria en Linux. Funciona como un módulo del kernel que vuelca la memoria con mínimo impacto en el sistema. Es la única herramienta que captura toda la RAM de forma consistente.

BASH — Captura con LiME

# 1. Instalar dependencias para compilar módulos del kernel
sudo apt install build-essential linux-headers-$(uname -r)

# 2. Descargar y compilar LiME
git clone https://github.com/504ensicsLabs/LiME.git
cd LiME/src
make

# 3. Cargar el módulo y crear el volcado
# path= ruta del archivo de salida
# format=lime (formato nativo de LiME, compatible con Volatility 3)
sudo insmod lime-$(uname -r).ko \
  'path=/tmp/memory.lime format=lime'

# 4. Verificar que el volcado se ha creado
ls -lh /tmp/memory.lime

# 5. Una vez terminado, descargar el módulo
sudo rmmod lime

Opción B — /proc/kcore — Método alternativo (sin compilar) ACCESO DIRECTO

/proc/kcore es una interfaz del kernel que representa la memoria física en formato ELF. No siempre captura toda la RAM y puede fallar en kernels modernos con KASLR.

BASH — Captura via /proc/kcore

# Solo recomendado si LiME no está disponible
# NOTA: En kernels modernos con KASLR activo,
# esta imagen puede ser incompleta o inconsistente.

sudo dd if=/proc/kcore of=/tmp/memory.dd bs=1M

# Alternativa con más contexto:
sudo cp /proc/kcore /tmp/memory_kcore.img

⚠ LIMITACIÓN DE dd con /dev/memEl comando dd if=/dev/mem del laboratorio original ya NO funciona en kernels Linux modernos. Desde el kernel 4.x, el acceso a /dev/mem está restringido por defecto por razones de seguridad. Usar LiME es el método correcto.

Calcular el hash de integridad del volcado CADENA DE CUSTODIA

En un análisis forense real, documentar el hash del volcado es obligatorio para garantizar la cadena de custodia y demostrar que la evidencia no ha sido modificada.

BASH — Verificar integridad

# Calcular hash SHA-256 (más seguro que MD5)
sha256sum /tmp/memory.lime > /tmp/memory.lime.sha256
cat /tmp/memory.lime.sha256

# También guardar el hash MD5 para compatibilidad
md5sum /tmp/memory.lime > /tmp/memory.lime.md5

# Registrar metadatos del volcado
echo "Fecha: $(date)" > /tmp/memoria_metadata.txt
echo "Sistema: $(uname -a)" >> /tmp/memoria_metadata.txt
echo "Hash SHA-256: $(sha256sum /tmp/memory.lime | cut -d' ' -f1)" >> /tmp/memoria_metadata.txt

Primera inspección con Volatility 3 VERIFICACIÓN

Antes de analizar en profundidad, comprueba que Volatility 3 reconoce el volcado y obtén información básica del sistema.

BASH — Inspección inicial del volcado

# Identificar el banner del kernel en el volcado
# Esto muestra la versión del kernel Linux de la imagen
python3 vol.py -f /tmp/memory.lime banners.Banners

# Ejemplo de salida esperada:
# Offset   Banner
# 0x3c1000 Linux version 5.15.0-91-generic (buildd@...) ...

# Ver información del boot
python3 vol.py -f /tmp/memory.lime linux.boottime

❓ Pregunta de comprensión

Tras ejecutar banners.Banners, obtienes múltiples líneas con diferentes versiones de kernel. ¿Por qué puede aparecer más de una versión de kernel en un mismo volcado de memoria?

💡 Pista: Piensa en lo que puede haber en la RAM además del kernel actual en ejecución.

Ver respuesta

La RAM puede contener residuos de sesiones anteriores (memoria no sobreescrita), datos del bootloader, información de kernels anteriores que quedaron en caché, o en sistemas con hibernación habilitada, páginas de memoria de boots anteriores. Volatility muestra todos los banners que encuentra, y hay que usar el más repetido/reciente.

⚙️

Ejercicio 2 — Análisis de Procesos en Ejecución

Objetivo: identificar y analizar todos los procesos activos en el momento del volcado

Los procesos son el punto de partida de cualquier análisis forense de memoria. Volatility 3 ofrece varios plugins para listarlos desde diferentes perspectivas, lo que nos permite detectar inconsistencias que podrían indicar actividad maliciosa.

Listar todos los procesos con linux.pslist LISTA DE PROCESOS

linux.pslist recorre la lista enlazada de procesos del kernel (task_struct) y muestra todos los procesos activos en el momento del volcado. Es el equivalente a ejecutar ps aux en el sistema.

BASH — Listar procesos

# Listar todos los procesos activos
python3 vol.py -f /tmp/memory.lime linux.pslist

# Guardar la salida para análisis posterior
python3 vol.py -f /tmp/memory.lime linux.pslist > /tmp/pslist_output.txt

# Columnas de salida: OFFSET, PID, TID, PPID, COMM, UID, GID, EUID, EGID, CREATION TIME
# COMM: nombre del proceso (truncado a 15 caracteres)
# PPID: PID del proceso padre (clave para detectar anomalías)

Ver árbol de procesos con linux.pstree JERARQUÍA

linux.pstree muestra los procesos con su relación padre-hijo en formato árbol. Esto es fundamental para detectar procesos legítimos que tienen hijos inesperados (técnica common en inyección de procesos y living-off-the-land).

BASH — Árbol de procesos

# Ver jerarquía de procesos
python3 vol.py -f /tmp/memory.lime linux.pstree

# Buscar procesos específicos en el árbol
python3 vol.py -f /tmp/memory.lime linux.pstree 2>/dev/null | grep -E 'bash|sh|python|perl|nc|ncat'

💡 QUÉ BUSCAR EN EL ÁRBOLRelaciones sospechosas de padre-hijo: apache2 o nginx generando un bash (posible webshell), cron ejecutando scripts anómalos, procesos con nombres que imitan servicios legítimos pero con PPID incorrecto.

Ver argumentos de línea de comandos con linux.cmdline ARGUMENTOS

linux.cmdline muestra la línea de comandos completa con la que fue lanzado cada proceso, incluyendo todos los argumentos. Los procesos maliciosos suelen tener argumentos reveladores.

BASH — Ver línea de comandos de procesos

# Ver comandos con los que se lanzó cada proceso
python3 vol.py -f /tmp/memory.lime linux.cmdline

# Filtrar por PID específico (si encontraste algo sospechoso en pslist)
python3 vol.py -f /tmp/memory.lime linux.cmdline --pid 1337

# Buscar patrones sospechosos
python3 vol.py -f /tmp/memory.lime linux.cmdline 2>/dev/null | \
  grep -Ei 'wget|curl|base64|python|perl|nc|/tmp|/dev/shm'

Listar archivos abiertos por un proceso con linux.lsof ARCHIVOS ABIERTOS

Equivalente al comando lsof en vivo. Muestra todos los descriptores de fichero abiertos: archivos, sockets, pipes. Útil para saber qué archivos estaba usando un proceso sospechoso.

BASH — Archivos abiertos por proceso

# Listar archivos abiertos por todos los procesos
python3 vol.py -f /tmp/memory.lime linux.lsof

# Filtrar por un proceso concreto (reemplaza 1337 por el PID real)
python3 vol.py -f /tmp/memory.lime linux.lsof --pid 1337

# Buscar procesos con archivos abiertos en /tmp o /dev/shm
# (ubicaciones típicas de malware)
python3 vol.py -f /tmp/memory.lime linux.lsof 2>/dev/null | \
  grep -E '/tmp|/dev/shm|/var/tmp'

💡 SEÑALES DE ALERTA EN ANÁLISIS DE PROCESOSBusca estas anomalías:
• Procesos con nombres similares a servicios legítimos pero con variaciones (sshd → sshdd, cron → crond)
• Procesos en /tmp, /dev/shm o /var/tmp (zonas de escritura sin noexec frecuente)
• Procesos con UID=0 (root) que no deberían serlo
• Procesos bash o sh hijos de servicios web (apache, nginx, php-fpm)
• Procesos con PPID=1 (init/systemd) que no son servicios configurados

❓ Pregunta de comprensión

Ejecutas linux.pslist y linux.pstree y ves un proceso llamado python3 con PID 4242 siendo hijo de apache2. ¿Qué podría significar esto y cómo investigarías más?

💡 Pista: Combina linux.cmdline y linux.lsof para obtener más información.

Ver respuesta

Un proceso python3 hijo de apache2 es una señal de alarma clásica de webshell o exploitación de aplicación web. Para investigar: (1) linux.cmdline --pid 4242 para ver qué script Python se está ejecutando, (2) linux.lsof --pid 4242 para ver si tiene conexiones de red abiertas, (3) linux.maps --pid 4242 para ver las regiones de memoria cargadas.

🌐

Ejercicio 3 — Investigación de Conexiones de Red

Objetivo: extraer y analizar las conexiones de red activas en el momento del volcado

📌 NOTA SOBRE ANÁLISIS DE RED EN VOLATILITY 3Los plugins de red de Linux en Volatility 3 son más limitados que los de Windows. Para análisis de red avanzado en Linux se recomienda combinar Volatility 3 con otras técnicas como extracción de strings de la imagen de memoria.

Listar conexiones de red activas con linux.netstat CONEXIONES ACTIVAS

Equivalente al comando netstat -antp en el sistema en vivo. Muestra conexiones TCP/UDP con sus estados, puertos y el proceso propietario.

BASH — Ver conexiones de red

# Listar todas las conexiones de red
python3 vol.py -f /tmp/memory.lime linux.netstat

# Guardar para análisis
python3 vol.py -f /tmp/memory.lime linux.netstat > /tmp/netstat_output.txt

# Columnas: NETNS, PROTO, SOURCE ADDR, SRC PORT, DEST ADDR, DEST PORT, STATE, PID, COMM

Analizar la tabla ARP y configuración de interfaces CONFIGURACIÓN DE RED

La tabla ARP muestra qué hosts estaba comunicando el sistema, lo que puede revelar hosts en la red local con los que el malware o el atacante interactuó.

BASH — Tabla ARP e interfaces

# Ver tabla ARP (resolución IP → MAC)
python3 vol.py -f /tmp/memory.lime linux.arp

# Ver configuración de interfaces de red
python3 vol.py -f /tmp/memory.lime linux.ifconfig

Buscar IPs y puertos sospechosos en el volcado con strings BÚSQUEDA DE ARTEFACTOS DE RED

Una técnica complementaria muy efectiva es buscar patrones de IP y puertos directamente en el volcado de memoria, capturando conexiones que pueden no aparecer en las estructuras de red del kernel.

BASH — Búsqueda manual de IPs en memoria

# Extraer strings del volcado de memoria (todas las cadenas ASCII)
strings /tmp/memory.lime > /tmp/all_strings.txt

# Buscar patrones de IP privadas (192.168.x.x, 10.x.x.x, 172.16-31.x.x)
grep -E '([0-9]{1,3}\.){3}[0-9]{1,3}' /tmp/all_strings.txt | \
  grep -E '^(192\.168|10\.|172\.(1[6-9]|2[0-9]|3[0-1]))' | sort -u

# Buscar URLs y dominios
grep -Eo 'https?://[^[:space:]"]+' /tmp/all_strings.txt | sort -u

# Con Volatility 3 directamente:
python3 vol.py -f /tmp/memory.lime linux.strings --pid <PID_SOSPECHOSO>

💡 PUERTOS QUE DEBERÍAN LLAMAR TU ATENCIÓNPuertos no estándar en LISTEN: 4444 (Metasploit default), 1234, 31337 (leet, backdoor clásico), 9001, 8888, 4455. También conexiones salientes en puertos altos (>1024) hacia IPs externas desconocidas. Un proceso como python3 o nc con conexión ESTABLISHED hacia una IP pública es crítico.

❓ Pregunta de comprensión

En la salida de linux.netstat ves una conexión ESTABLISHED desde el sistema hacia 203.0.113.42:4444 originada por un proceso con COMM='bash'. ¿Qué tipo de ataque indica esto y cuáles serían tus próximos pasos?

💡 Pista: 4444 es el puerto por defecto de Metasploit. Una shell bash con conexión saliente hacia ese puerto tiene un nombre específico.

Ver respuesta

Esto indica con alta probabilidad una reverse shell (shell inversa). El proceso bash está enviando su stdin/stdout a través de una conexión TCP al host del atacante (203.0.113.42). Próximos pasos: (1) linux.cmdline --pid <PID> para ver cómo se lanzó la shell, (2) linux.pstree para ver qué proceso la invocó, (3) aislar el sistema de la red inmediatamente, (4) preservar evidencia completa.

🧩

Ejercicio 4 — Módulos del Kernel y Artefactos

Objetivo: examinar módulos del kernel cargados en busca de rootkits

Los rootkits a nivel de kernel son una de las amenazas más sofisticadas y difíciles de detectar. Modifican las estructuras internas del kernel para ocultar procesos, conexiones y archivos. El análisis de módulos del kernel es esencial para detectarlos.

Listar módulos del kernel cargados ENUMERACIÓN

linux.lsmod recorre la lista enlazada de módulos del kernel (struct module) y muestra todos los que están cargados. Un módulo desconocido o con nombre sospechoso puede ser un rootkit.

BASH — Listar módulos del kernel

# Listar todos los módulos cargados
python3 vol.py -f /tmp/memory.lime linux.lsmod

# Columnas: OFFSET, NAME, SIZE, USED_BY, SECTIONS, CORE_SIZE
# Guardar para análisis y comparar con el sistema limpio
python3 vol.py -f /tmp/memory.lime linux.lsmod > /tmp/lsmod_output.txt

# Comparar con un sistema limpio de referencia:
lsmod > /tmp/lsmod_reference.txt  # en el sistema limpio
diff /tmp/lsmod_reference.txt /tmp/lsmod_output.txt

Comparar módulos del kernel con el sistema de referencia DETECCIÓN DE ANOMALÍAS

⚠ SEÑALES DE ALARMA EN MÓDULOS DEL KERNELBusca: (1) Módulos con nombres muy cortos o genéricos, (2) Módulos que no están en /lib/modules/, (3) Módulos con SIZE=0 o valores anómalos, (4) Módulos listados en la lista del kernel pero no en el sistema de archivos, (5) Módulos que aparecen en el sistema de archivos pero NO en lsmod (pueden estar ocultos por rootkit).

BASH — Verificar integridad de módulos

# Listar módulos con información extendida
python3 vol.py -f /tmp/memory.lime linux.lsmod --tree

# Buscar módulos cargados desde rutas inusuales
python3 vol.py -f /tmp/memory.lime linux.lsmod 2>/dev/null | \
  grep -v 'kernel/drivers\|kernel/net\|kernel/fs\|kernel/block'

Examinar la tabla de llamadas al sistema (syscall table) DETECCIÓN DE HOOKING

⚠ TÉCNICA AVANZADA — SYSCALL HOOKINGLos rootkits avanzados modifican la syscall table (tabla de llamadas al sistema) para interceptar y modificar el comportamiento del kernel. Por ejemplo, modifican sys_getdents para ocultar archivos, o sys_kill para recibir comandos del atacante.

BASH — Detectar hooks en syscall table

# Verificar la integridad de la syscall table
python3 vol.py -f /tmp/memory.lime linux.check_syscall

# Buscar modificaciones en los manejadores de interrupciones
python3 vol.py -f /tmp/memory.lime linux.check_idt

# Verificar que las funciones del kernel no han sido modificadas
python3 vol.py -f /tmp/memory.lime linux.check_afinfo

❓ Pregunta de comprensión

Ejecutas linux.lsmod y encuentras un módulo llamado hiding con SIZE=0. Acto seguido ejecutas lsmod en el sistema en vivo y ese módulo NO aparece. ¿Qué indica esto?

💡 Pista: Volatility lee directamente de la memoria, mientras que lsmod usa las llamadas al sistema del kernel.

Ver respuesta

Que la lista de módulos del kernel ha sido manipulada. Un rootkit de módulo de kernel puede alterar la lista enlazada de struct module que utiliza lsmod para ocultarse de las herramientas del sistema, pero Volatility lee directamente la memoria RAM sin pasar por las syscalls comprometidas, por lo que puede ver el módulo malicioso que está activo pero oculto. Esto es una demostración perfecta del valor del forense de memoria offline.

🕵️

Ejercicio 5 — Descubrimiento de Procesos Ocultos

Objetivo: detectar procesos que han sido ocultados por técnicas de rootkit

Los rootkits de Linux a nivel de kernel pueden manipular las estructuras internas del OS para ocultar procesos a las herramientas convencionales. Volatility 3, al analizar la memoria directamente, puede detectar estas ocultaciones comparando diferentes vistas de los procesos.

Escanear memoria buscando estructuras task_struct ESCANEO DIRECTO

linux.psscan no recorre la lista enlazada (que puede haber sido manipulada) sino que escanea toda la memoria buscando el patrón de una estructura task_struct. Los procesos que aparecen aquí pero no en linux.pslist son potencialmente ocultos por rootkit.

BASH — Escanear estructuras de proceso en memoria

# Escanear memoria en busca de task_struct
# (no depende de la lista enlazada del kernel)
python3 vol.py -f /tmp/memory.lime linux.psscan

# Guardar resultado
python3 vol.py -f /tmp/memory.lime linux.psscan > /tmp/psscan_output.txt

Comparar pslist vs psscan para detectar DKOM COMPARACIÓN

DKOM (Direct Kernel Object Manipulation) es la técnica que usan los rootkits para ocultar procesos: desvinculan el task_struct de la lista doblemente enlazada del kernel, haciéndolo invisible para ps, top y pslist. Pero psscan lo encuentra porque busca el patrón en memoria.

BASH — Detectar procesos ocultos por DKOM

# Comparar las dos listas
python3 vol.py -f /tmp/memory.lime linux.pslist > /tmp/pslist.txt
python3 vol.py -f /tmp/memory.lime linux.psscan > /tmp/psscan.txt

# Extraer solo los PIDs de cada lista
grep -oP 'PID\s+\K[0-9]+' /tmp/pslist.txt | sort -n > /tmp/pids_list.txt
grep -oP 'PID\s+\K[0-9]+' /tmp/psscan.txt | sort -n > /tmp/pids_scan.txt

# Ver qué PIDs aparecen en psscan pero no en pslist (= ocultos por rootkit)
comm -23 /tmp/pids_scan.txt /tmp/pids_list.txt

Extraer historial de comandos bash HISTORIAL

linux.bash extrae el historial de comandos de bash desde la memoria de los procesos. Esto puede revelar comandos que el atacante ejecutó, incluso si eliminó el archivo ~/.bash_history.

BASH — Recuperar historial de bash desde memoria

# Extraer historial de bash de todos los procesos bash activos
python3 vol.py -f /tmp/memory.lime linux.bash

# Guardar para análisis
python3 vol.py -f /tmp/memory.lime linux.bash > /tmp/bash_history.txt

# Columnas: PID, PROCESS, COMMAND_TIME, COMMAND
# Ordenar por tiempo para reconstruir la línea de tiempo
sort -k3 /tmp/bash_history.txt

✅ VALOR FORENSE DEL HISTORIAL EN MEMORIAEl historial de bash en memoria puede contener comandos que el atacante ejecutó y luego intentó borrar con history -c o eliminando ~/.bash_history. La memoria RAM conserva el búfer de historial del proceso bash hasta que se sobrescribe.

❓ Pregunta de comprensión

Al comparar linux.pslist y linux.psscan, encuentras que el PID 2222 aparece en psscan pero no en pslist. El nombre del proceso es kworker/1:1. ¿Esto es definitivamente malicioso?

💡 Pista: Mira el nombre del proceso. ¿Es un nombre legítimo del kernel? ¿Y si el PID es muy alto para ser un thread del kernel?

Ver respuesta

No necesariamente. kworker es un thread legítimo del kernel Linux. Sin embargo, hay que investigar: (1) Los PIDs de kworker genuinos suelen ser bajos (por debajo de 200 normalmente), un kworker con PID alto es sospechoso. (2) Examinar el UID — un kworker debe ejecutarse con UID 0. (3) Usar linux.cmdline para ver los argumentos. (4) Comparar la dirección de memoria del task_struct para ver si tiene sentido. Los rootkits frecuentemente usan nombres de procesos del kernel para camuflar sus procesos maliciosos.

🦠

Ejercicio 6 — Detección y Análisis de Malware

Objetivo: localizar artefactos de malware en el volcado usando análisis heurístico y reglas YARA

Escanear regiones de memoria ejecutable anómalas con linux.malfind DETECCIÓN HEURÍSTICA

linux.malfind busca regiones de memoria que sean ejecutables y no estén respaldadas por ningún archivo en disco (lo que indica inyección de código o shellcode en memoria). Es una de las técnicas más efectivas para detectar malware fileless.

BASH — Detectar código malicioso inyectado

# Buscar regiones de memoria anómalas (ejecutables sin respaldo en disco)
python3 vol.py -f /tmp/memory.lime linux.malfind

# Filtrar por proceso específico
python3 vol.py -f /tmp/memory.lime linux.malfind --pid <PID_SOSPECHOSO>

# Guardar resultados incluyendo hexdump
python3 vol.py -f /tmp/memory.lime linux.malfind > /tmp/malfind_output.txt

# Columnas: PID, PROCESS, START, END, PROTECTION, REASON

Escanear con reglas YARA DETECCIÓN POR FIRMA

YARA es el estándar para detectar malware por patrones. Volatility 3 integra YARA para escanear la memoria en busca de firmas conocidas de malware, shellcodes, herramientas de post-explotación, etc.

📌 INSTALAR REGLAS YARADescarga reglas actualizadas: git clone https://github.com/Yara-Rules/rules.git o usa las reglas de CAPE, Elastic o ReversingLabs. También puedes escribir tus propias reglas para IoCs específicos.

BASH — Escanear memoria con YARA

# Instalar yara-python si no está instalado
pip3 install yara-python

# Descargar un set de reglas (ejemplo con Yara-Rules)
git clone https://github.com/Yara-Rules/rules.git /tmp/yara-rules

# Escanear la memoria con las reglas
python3 vol.py -f /tmp/memory.lime \
  yarascan.YaraScan \
  --yara-rules /tmp/yara-rules/malware/MALWARE_Meterpreter.yar

# Escanear con una regla YARA personalizada
# (crea el archivo primero)
cat > /tmp/custom_rule.yar << 'EOF'
rule ReverseShell {
    strings:
        $s1 = "/bin/bash" fullword
        $s2 = "/dev/tcp/"
        $s3 = "nc -e /bin/bash"
    condition:
        any of them
}
EOF

python3 vol.py -f /tmp/memory.lime \
  yarascan.YaraScan --yara-file /tmp/custom_rule.yar

Volcar páginas de memoria de un proceso sospechoso EXTRACCIÓN PARA ANÁLISIS

Si encontramos un proceso sospechoso, podemos volcar toda su memoria a disco para analizarla con otras herramientas (strings, análisis estático, sandboxing).

BASH — Volcar memoria de proceso sospechoso

# Volcar el ejecutable del proceso a disco
python3 vol.py -f /tmp/memory.lime \
  -o /tmp/process_dumps/ \
  linux.proc.Maps --pid <PID_SOSPECHOSO> --dump

# Analizar el volcado con strings
strings /tmp/process_dumps/*.dmp | grep -Ei 'http|ftp|tcp|ip|pass|user|cmd'

# Calcular hash para comparar con bases de datos de malware (VirusTotal, MalwareBazaar)
md5sum /tmp/process_dumps/*.dmp
sha256sum /tmp/process_dumps/*.dmp

💡 CÓMO INTERPRETAR MALFINDUna región de memoria marcada por malfind NO es automáticamente maliciosa. Los falsos positivos son comunes (JIT compilers como Java/V8 generan código ejecutable en memoria). Criterios para considerar sospechoso: (1) proceso inesperado, (2) los bytes iniciales parecen shellcode (MZ header indica PE inyectado, NOP sleds, etc.), (3) el proceso no debería tener código ejecutable fuera de sus módulos cargados.

❓ Pregunta de comprensión

Ejecutas linux.malfind y encuentras en el proceso python3 (PID 4242) una región de memoria con protección rwx (lectura/escritura/ejecución). Los primeros bytes son 4d 5a 90 00. ¿Qué significa esto?

💡 Pista: Los primeros dos bytes de cualquier ejecutable PE de Windows son MZ. ¿Qué hace un ejecutable PE dentro de un proceso python3 en Linux?

Ver respuesta

Los bytes 0x4D 0x5A corresponden a 'MZ', la firma mágica de ejecutables Portable Executable (PE/EXE de Windows). Encontrar un PE dentro de la memoria de un proceso Python en Linux indica casi con certeza que hay un ejecutable malicioso inyectado en memoria, posiblemente un payload de Metasploit/Cobalt Strike o similar. El proceso Python puede haber sido comprometido vía explotación o puede ser el propio vector de ataque que cargó el shellcode.

🌍

Ejercicio 7 — Extracción de Artefactos de Navegador

Objetivo: recuperar actividad del navegador y artefactos de sesión desde la memoria

Identificar procesos de navegador en el volcado IDENTIFICACIÓN

El primer paso es localizar los procesos del navegador (Firefox, Chrome, Chromium) en el listado de procesos del volcado.

BASH — Encontrar procesos de navegador

# Buscar Firefox, Chrome o Chromium en la lista de procesos
python3 vol.py -f /tmp/memory.lime linux.pslist 2>/dev/null | \
  grep -Ei 'firefox|chrome|chromium|brave|opera'

# Ver los argumentos con los que se lanzó el navegador
python3 vol.py -f /tmp/memory.lime linux.cmdline 2>/dev/null | \
  grep -Ei 'firefox|chrome|chromium'

Recuperar historial de bash con comandos del navegador HISTORIAL

El historial de bash puede contener URLs que se abrieron directamente desde la terminal, así como comandos de descarga con wget o curl que revelan actividad del usuario o del atacante.

BASH — Buscar URLs en historial de bash y memoria

# Ver historial de bash que puede contener URLs
python3 vol.py -f /tmp/memory.lime linux.bash 2>/dev/null | \
  grep -E 'wget|curl|http|https|ftp'

# Buscar URLs en toda la memoria del proceso del navegador
# Primero obtén el PID del proceso firefox
FIREFOX_PID=$(python3 vol.py -f /tmp/memory.lime linux.pslist 2>/dev/null | \
  grep -i firefox | head -1 | awk '{print $2}')

# Luego extrae strings de su memoria
python3 vol.py -f /tmp/memory.lime \
  linux.strings --pid $FIREFOX_PID 2>/dev/null | \
  grep -Eo 'https?://[^[:space:]]+' | sort -u | head -50

Extraer cookies y tokens de sesión CREDENCIALES

Los navegadores mantienen en memoria las cookies activas de las sesiones web. Esto puede incluir tokens de autenticación, session IDs y otros artefactos de alto valor forense.

BASH — Buscar cookies y tokens en memoria del navegador

# Extraer strings del proceso del navegador y buscar cookies
python3 vol.py -f /tmp/memory.lime \
  linux.strings --pid $FIREFOX_PID 2>/dev/null | \
  grep -E 'session|cookie|token|auth|Bearer|PHPSESSID|JSESSIONID' | \
  sort -u > /tmp/browser_tokens.txt

cat /tmp/browser_tokens.txt | head -30

# Buscar credenciales en texto plano
python3 vol.py -f /tmp/memory.lime \
  linux.strings --pid $FIREFOX_PID 2>/dev/null | \
  grep -Ei 'password=|passwd=|user=|login=' | sort -u

Recuperar historial de búsquedas y URLs visitadas ACTIVIDAD WEB

Firefox guarda el historial en una base de datos SQLite en disco, pero en memoria pueden quedar fragmentos de las URLs visitadas durante la sesión activa.

BASH — Recuperar URLs visitadas y búsquedas

# Buscar URLs del motor de búsqueda en memoria
python3 vol.py -f /tmp/memory.lime \
  linux.strings --pid $FIREFOX_PID 2>/dev/null | \
  grep -Eo 'https?://www\.(google|bing|duckduckgo)\.[^[:space:]]+' | \
  python3 -c 'import sys,urllib.parse; [print(urllib.parse.unquote(l)) for l in sys.stdin]'

# Buscar cualquier URL con query string (posible búsqueda)
python3 vol.py -f /tmp/memory.lime \
  linux.strings --pid $FIREFOX_PID 2>/dev/null | \
  grep -E 'https?://[^[:space:]]+\?[^[:space:]]+' | sort -u | head -20

📌 LIMITACIONES DEL ANÁLISIS DE ARTEFACTOS DE NAVEGADORLos navegadores modernos con sandboxing (Chrome, Firefox con e10s) tienen múltiples procesos con memoria separada. Puede ser necesario analizar varios PIDs. Además, el cifrado de memoria de Firefox (con --no-sandbox desactivado) puede hacer que algunos artefactos sean más difíciles de recuperar en texto plano.

❓ Pregunta de comprensión

Al analizar la memoria de un proceso Firefox encuentras el string Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiYWRtaW4ifQ.xxxxx. ¿Qué es esto y qué impacto podría tener si un atacante lo obtiene?

💡 Pista: Fíjate en el formato: tres segmentos separados por puntos. ¿Reconoces este formato de token?

Ver respuesta

Es un JWT (JSON Web Token), el formato de autenticación más común en aplicaciones web modernas. La parte central (eyJ1c2VyIjoiYWRtaW4ifQ) es Base64 y decodificada revela: {user: admin}. Si un atacante obtiene este token activo, puede suplantar la sesión del administrador en la aplicación web sin necesitar contraseña, hasta que el token expire. Esto ilustra perfectamente por qué el análisis de memoria puede revelar credenciales de sesión críticas.

📚

Referencia Rápida de Plugins Linux en Volatility 3

Los plugins más útiles y sus equivalentes en Volatility 2

Plugin Volatility 3	Equivalente V2	Descripción
`linux.pslist`	`linux_pslist`	Lista procesos activos (recorre la lista del kernel)
`linux.psscan`	`linux_pslist_cache`	Escanea memoria en busca de task_struct (detecta ocultos)
`linux.pstree`	`linux_pstree`	Árbol de procesos padre-hijo
`linux.cmdline`	`linux_psaux`	Argumentos de línea de comandos de cada proceso
`linux.lsof`	`linux_lsof`	Archivos y sockets abiertos por proceso
`linux.netstat`	`linux_netstat`	Conexiones TCP/UDP y su estado
`linux.ifconfig`	`linux_ifconfig`	Configuración de interfaces de red
`linux.arp`	`linux_arp`	Tabla ARP (resolución IP/MAC)
`linux.lsmod`	`linux_lsmod`	Módulos del kernel cargados
`linux.check_syscall`	`linux_check_syscall`	Detecta hooks en la syscall table
`linux.bash`	`linux_bash`	Historial de comandos bash en memoria
`linux.malfind`	`linux_malfind`	Detecta regiones de memoria ejecutables anómalas
`linux.strings`	`linux_strings`	Strings de la memoria de un proceso
`linux.maps`	`linux_proc_maps`	Mapa de memoria de un proceso
`linux.proc.Maps`	`linux_dump_map`	Vuelca páginas de memoria a disco
`yarascan.YaraScan`	`linux_yarascan`	Escanea memoria con reglas YARA
`banners.Banners`	`linux_banner`	Detecta la versión del kernel en el volcado
`linux.boottime`	N/A	Tiempo de arranque del sistema (solo V3)
`linux.check_idt`	`linux_check_idt`	Verifica la tabla de interrupciones
`linux.check_afinfo`	`linux_check_afinfo`	Verifica hooks en el subsistema de red

🗺️

Flujo de Trabajo Forense Recomendado

Metodología estructurada para un análisis completo

Un análisis forense de memoria debe seguir un proceso estructurado y reproducible. El siguiente flujo de trabajo cubre desde la captura inicial hasta el informe de hallazgos.

BASH — SCRIPT — Flujo completo de análisis con Volatility 3 en Linux

#!/bin/bash
# ============================================================
# FLUJO DE ANÁLISIS FORENSE DE MEMORIA - Volatility 3
# GhostAcademy - unfantasmaenelsistema.com
# ============================================================

IMAGEN="/tmp/memory.lime"
SALIDA="/tmp/vol3_analysis"
VOL="python3 /opt/volatility3/vol.py"

mkdir -p $SALIDA

echo "[*] FASE 1 - Identificación del sistema"
$VOL -f $IMAGEN banners.Banners   > $SALIDA/01_banners.txt
$VOL -f $IMAGEN linux.boottime    > $SALIDA/02_boottime.txt

echo "[*] FASE 2 - Análisis de procesos"
$VOL -f $IMAGEN linux.pslist      > $SALIDA/03_pslist.txt
$VOL -f $IMAGEN linux.psscan      > $SALIDA/04_psscan.txt
$VOL -f $IMAGEN linux.pstree      > $SALIDA/05_pstree.txt
$VOL -f $IMAGEN linux.cmdline     > $SALIDA/06_cmdline.txt

echo "[*] FASE 3 - Red"
$VOL -f $IMAGEN linux.netstat     > $SALIDA/07_netstat.txt
$VOL -f $IMAGEN linux.ifconfig    > $SALIDA/08_ifconfig.txt
$VOL -f $IMAGEN linux.arp         > $SALIDA/09_arp.txt

echo "[*] FASE 4 - Módulos del kernel"
$VOL -f $IMAGEN linux.lsmod       > $SALIDA/10_lsmod.txt
$VOL -f $IMAGEN linux.check_syscall > $SALIDA/11_syscall.txt

echo "[*] FASE 5 - Detección de malware"
$VOL -f $IMAGEN linux.malfind     > $SALIDA/12_malfind.txt
$VOL -f $IMAGEN linux.bash        > $SALIDA/13_bash_history.txt

echo "[*] FASE 6 - Comparar pslist vs psscan (procesos ocultos)"
awk 'NR>1 {print $2}' $SALIDA/03_pslist.txt | sort -n > /tmp/pids_list.txt
awk 'NR>1 {print $2}' $SALIDA/04_psscan.txt | sort -n > /tmp/pids_scan.txt
echo "PIDs en psscan pero NO en pslist (posibles OCULTOS):" > $SALIDA/14_hidden_procs.txt
comm -23 /tmp/pids_scan.txt /tmp/pids_list.txt        >> $SALIDA/14_hidden_procs.txt

echo "[+] Análisis completado. Resultados en: $SALIDA"
ls -la $SALIDA

🔗

Recursos Adicionales y Práctica

Dónde continuar aprendiendo y practicar con imágenes reales

🎓IMÁGENES DE MEMORIA PARA PRÁCTICA

MemLabs: github.com/stuxnet999/MemLabs — 6 challenges de análisis forense de memoria con volcados de Windows y Linux.
CyberDefenders: cyberdefenders.org — Plataforma BlueTeam con labs de DFIR que incluyen análisis de memoria.
BlueTeamLabs Online: blueteamlabs.online — Retos de análisis forense.
Volatility Foundation Samples: El repositorio oficial de Volatility incluye imágenes de muestra para testing de plugins.
CTF Archives: Muchos CTFs incluyen challenges de memoria (busca "volatility CTF writeup" para aprender de otros).

📖DOCUMENTACIÓN Y HERRAMIENTAS COMPLEMENTARIAS

Volatility 3 Docs: volatility3.readthedocs.io — Documentación oficial, actualizada.
ISF Server: isf-server.techanarchy.net — Tablas de símbolos precompiladas para Volatility 3.
LiME: github.com/504ensicsLabs/LiME — Herramienta de captura de memoria para Linux.
dwarf2json: github.com/volatilityfoundation/dwarf2json — Genera tablas ISF desde símbolos de debug del kernel.
YARA Rules: github.com/Yara-Rules/rules — Colección de reglas YARA para malware.
Volatility3-symbols: github.com/volatilityfoundation/volatility3-symbols — Repo oficial de tablas ISF.

✅ CONCLUSIÓN DEL LABORATORIOHas completado los 7 ejercicios de este laboratorio de forense de memoria. Ahora tienes los fundamentos para: capturar memoria con LiME, configurar Volatility 3 con tablas de símbolos ISF, analizar procesos y detectar ocultaciones DKOM, investigar conexiones de red, examinar módulos del kernel en busca de rootkits, detectar malware con malfind y YARA, y recuperar artefactos de navegador y historial de bash.

El siguiente paso recomendado es practicar con los labs de MemLabs o CyberDefenders para consolidar los conocimientos en escenarios reales.