Análisis de memoria con Volatility 3

Aviso legal y ético: el volcado de memoria RAM de un sistema contiene, casi siempre, datos personales, credenciales en claro y secretos empresariales. Analiza únicamente volcados propios, de tu laboratorio o para los que tengas autorización expresa por escrito. Extraer memoria de un sistema ajeno sin consentimiento es delito en España (arts. 197 y ss. del Código Penal, descubrimiento y revelación de secretos) y, si hay datos personales de terceros, activa además las obligaciones del RGPD. Trata cada volcado de memoria con el mismo rigor de cadena de custodia que una imagen de disco: hash al recibirlo, copia de trabajo para analizar, y el original intacto.

Qué aprenderás

Por qué la memoria RAM es, en un incidente activo, la fuente de evidencia más rica: procesos en ejecución con sus argumentos, claves de cifrado descifradas, malware que nunca toca disco (fileless) y el estado exacto de las conexiones de red.
Las diferencias arquitectónicas entre Volatility 2 y Volatility 3, y por qué el sistema de --profile ha desaparecido en favor de los símbolos ISF.
Un flujo de análisis completo y ordenado con los plugins reales de Volatility 3: windows.info, windows.pslist, windows.psscan, windows.pstree, windows.cmdline, windows.dlllist, windows.handles, windows.netscan, windows.netstat, windows.malfind, windows.svcscan, windows.registry.hivelist, windows.registry.printkey, windows.dumpfiles, windows.memmap y el escaneo YARA en memoria (yarascan / windows.vadyarascan).
Cómo detectar inyección de código y process hollowing con windows.malfind, y cómo distinguir un falso positivo de una inyección real.
Cómo comparar procesos «vistos» frente a procesos «ocultos» (pslist vs. psscan) para detectar rootkits y técnicas de unlinking de DKOM.
Cómo extraer artefactos completos del volcado (ejecutables, DLLs, secciones de memoria) para análisis posterior en un entorno aislado o en sandbox.
Una metodología de malware hunting en RAM basada en indicios cruzados entre plugins, no en la confianza ciega en un único comando.

1. Por qué la memoria es la evidencia más rica del incidente

El disco te dice qué había instalado. La memoria te dice qué estaba pasando en el momento exacto de la captura. Esa diferencia es crítica cuando el atacante emplea técnicas fileless: PowerShell reflectivo que nunca escribe un .exe, beacons de Cobalt Strike inyectados en svchost.exe, credenciales de dominio volcadas de LSASS y mantenidas solo en memoria del atacante, o malware que se descifra en RAM y jamás persiste como fichero en claro. Ninguna de estas técnicas deja rastro completo en disco; todas dejan un rastro casi perfecto en memoria mientras el sistema sigue encendido.

Además de detectar lo que el disco no puede, la memoria permite recuperar artefactos cifrados o inaccesibles en disco: claves privadas TLS cargadas por un servidor web, contraseñas de aplicaciones de escritorio en claro en su espacio de direcciones, tokens de sesión, y la línea de comandos exacta que lanzó cada proceso —incluyendo comandos de PowerShell cifrados en Base64 en los logs, pero legibles en claro en memoria—.

Volatility 3 (proyecto de la Volatility Foundation, código abierto, github.com/volatilityfoundation/volatility3) es el framework de referencia: extrae estructuras del kernel y del espacio de usuario directamente del volcado binario, sin necesidad de que el sistema esté en ejecución ni depender de las propias herramientas de Windows, que un atacante con persistencia podría haber troyanizado.

2. Volatility 3 frente a Volatility 2: el cambio de los símbolos ISF

Quien haya usado Volatility 2 recordará el flujo de trabajo basado en --profile: había que identificar la build exacta de Windows del volcado (con imageinfo) y pasar ese perfil, precompilado y distribuido con la propia herramienta, a cada comando posterior. Ese modelo tenía un problema estructural: cada nueva build de Windows exigía un perfil nuevo generado y publicado por el proyecto, lo que dejaba sistemáticamente atrás las versiones más recientes del sistema operativo.

Volatility 3 elimina el concepto de perfil y lo sustituye por símbolos ISF (Intermediate Symbol Format): ficheros JSON (normalmente comprimidos como .json.xz) que describen la disposición exacta de las estructuras del kernel para una build concreta. Volatility 3 descarga automáticamente el símbolo correcto desde el repositorio oficial de símbolos (volatility3-symbols) la primera vez que analiza un volcado de esa build, y lo cachea localmente en volatility3/symbols/. No hace falta indicar manualmente ningún perfil ni build number: el propio framework identifica la versión de Windows a partir de estructuras internas del volcado y resuelve el símbolo automáticamente.

Otras diferencias prácticas para el día a día:

El binario ya no es vol.py con Python 2, sino vol (o python3 vol.py según instalación) sobre Python 3, con API interna orientada a objetos que también permite usarlo como librería.
Los plugins llevan prefijo de sistema operativo: windows.pslist, linux.bash, mac.pslist, en vez de los nombres planos de Volatility 2 (pslist, linux_bash).
La salida por defecto es texto plano, pero admite -r json o -r csv para pipelines automatizados de triage.
Muchos plugins requieren el módulo del kernel como parámetro (--kernel), que el framework detecta automáticamente en la mayoría de casos.

# Instalación típica (entorno virtual recomendado)
python3 -m venv volenv
source volenv/bin/activate
pip install volatility3

# Comprobar la versión y el listado completo de plugins disponibles
vol -h
vol --help | grep windows

# Estructura de invocación general de cualquier plugin
vol -f volcado.raw  [opciones]

3. Flujo de análisis: fase por fase con los plugins reales

Un análisis desordenado, donde se lanza un plugin tras otro sin metodología, malgasta tiempo y pasa por alto indicios. El flujo habitual en respuesta a incidentes va de lo general (identificar el sistema) a lo específico (inyección de código, artefactos concretos), cruzando siempre los resultados de un plugin con los de otro.

3.1 Identificación del sistema: windows.info

El primer paso siempre es confirmar qué sistema operativo, arquitectura y símbolo se ha resuelto para el volcado, antes de fiarte de ningún otro resultado.

python3 vol.py -f volcado.raw windows.info

La salida incluye la build de Windows, la arquitectura (x64/x86), la dirección base del kernel (KdVersionBlock), el número de procesadores y la hora de creación del volcado según las estructuras internas del sistema —un dato útil para correlacionar con la hora real de captura y detectar manipulación del reloj del sistema—.

3.2 Enumeración de procesos: pslist, psscan y pstree

Esta es la fase donde más analistas junior cometen el error más grave del módulo: confiar únicamente en windows.pslist. Ese plugin recorre la lista enlazada de procesos activos del kernel (EPROCESS vía ActiveProcessLinks), que es exactamente la misma estructura que consulta el Administrador de tareas de Windows. Un rootkit con capacidades DKOM (Direct Kernel Object Manipulation) puede desenlazar (unlink) su propio proceso de esa lista, haciéndolo invisible tanto para el Task Manager como para pslist, sin dejar de ejecutarse.

# Lista de procesos "oficial" (recorre la lista enlazada del kernel)
python3 vol.py -f volcado.raw windows.pslist

# Escaneo de procesos por firma en el pool de memoria, INCLUYE procesos ocultos/desenlazados y terminados recientemente
python3 vol.py -f volcado.raw windows.psscan

# Árbol de procesos con relación padre-hijo (ideal para detectar procesos hijos anómalos, p. ej. Word lanzando powershell.exe)
python3 vol.py -f volcado.raw windows.pstree

# Filtrar por un PID concreto en cualquiera de los tres plugins
python3 vol.py -f volcado.raw windows.pslist --pid 4132

windows.psscan escanea la memoria física en busca de estructuras EPROCESS por su firma de tipo (pool tag), sin depender de la lista enlazada. Por eso encuentra procesos que pslist no ve: procesos ocultos mediante DKOM y procesos ya terminados cuya estructura no ha sido sobrescrita todavía. La regla de metodología es simple e innegociable: ejecuta siempre ambos y compara el conjunto de PIDs. Cualquier PID que aparezca en psscan pero no en pslist es, como mínimo, sospechoso.

windows.pstree reconstruye la jerarquía padre-hijo a partir de los mismos datos de pslist, y es el plugin más rápido para detectar anomalías de «linaje»: un winword.exe con un cmd.exe o powershell.exe como hijo directo es un patrón clásico de macro maliciosa; un proceso huérfano cuyo PPID no corresponde a ningún proceso vivo también merece atención, porque puede indicar que el proceso padre original ya ha terminado (o ha sido terminado deliberadamente) tras lanzar al hijo malicioso.

3.3 Líneas de comandos: windows.cmdline

Con la lista de PIDs sospechosos en la mano, el siguiente paso es ver con qué argumentos se lanzó cada proceso.

python3 vol.py -f volcado.raw windows.cmdline
python3 vol.py -f volcado.raw windows.cmdline --pid 4132

Este plugin lee el bloque de entorno de proceso (PEB → ProcessParameters → CommandLine) y es una de las fuentes más directamente incriminatorias: aquí aparecen comandos PowerShell con -EncodedCommand seguidos del Base64 completo, rutas UNC de movimiento lateral, o el nombre exacto del fichero que un proceso malicioso recibió como argumento aunque se haya renombrado a algo inocuo (svchost.exe ejecutándose desde C:UsersPublic en lugar de C:WindowsSystem32).

3.4 DLLs cargadas y handles abiertos: windows.dlllist y windows.handles

# DLLs cargadas por un proceso concreto (o por todos si se omite --pid)
python3 vol.py -f volcado.raw windows.dlllist --pid 4132

# Handles abiertos por el proceso: ficheros, claves de registro, mutexes, secciones, eventos
python3 vol.py -f volcado.raw windows.handles --pid 4132

windows.dlllist recorre las listas de módulos cargados del PEB (InLoadOrderModuleList) y detecta DLLs cargadas desde rutas anómalas (directorios temporales, carpetas de usuario) o cuyo nombre imita a una legítima pero reside fuera de System32. windows.handles lista los objetos del kernel abiertos por el proceso —claves de registro, ficheros, mutexes, secciones compartidas—, valioso para identificar mutexes de malware conocido (muchas familias crean un mutante con nombre fijo para no reinfectarse a sí mismas) y qué claves de registro tenía abiertas un proceso sospechoso en el momento de la captura.

3.5 Conexiones de red: windows.netscan y windows.netstat

# Escaneo de estructuras de red en el pool de memoria (TCP/UDP, IPv4/IPv6), incluye conexiones ya cerradas
python3 vol.py -f volcado.raw windows.netscan

# Listado equivalente a "netstat", basado en las tablas de sockets activos
python3 vol.py -f volcado.raw windows.netstat

windows.netscan escanea el pool de memoria en busca de estructuras _TCP_ENDPOINT, _TCP_LISTENER y _UDP_ENDPOINT por firma, de forma análoga a como psscan escanea procesos: encuentra conexiones activas, en escucha, y también ya cerradas cuya estructura sigue presente en memoria no reutilizada. La salida incluye IP y puerto local, IP y puerto remoto, estado de la conexión TCP y el PID/proceso propietario del socket, lo que permite cruzar cada conexión con el proceso sospechoso identificado antes. Ese cruce —proceso anómalo en pstree + línea de comandos rara en cmdline + conexión saliente a IP externa no corporativa en netscan— es el patrón que confirma un canal de C2 activo.

4. Detección de inyección de código: windows.malfind

windows.malfind es, junto con la comparación pslist/psscan, el plugin más importante del módulo para cazar malware fileless. Identifica regiones de memoria (VADs, Virtual Address Descriptors) dentro de un proceso legítimo con características típicas de código inyectado, sin que exista ningún fichero en disco asociado.

# Escaneo completo de todos los procesos en busca de regiones de memoria sospechosas
python3 vol.py -f volcado.raw windows.malfind

# Limitar el escaneo a un proceso concreto ya identificado como sospechoso
python3 vol.py -f volcado.raw windows.malfind --pid 4132

# Volcar a disco las regiones VAD sospechosas encontradas, para análisis posterior (p. ej. en un sandbox)
python3 vol.py -f volcado.raw windows.malfind --pid 4132 --dump

Concretamente, malfind marca como sospechosa cualquier región VAD que cumpla, total o parcialmente, estos criterios:

Permisos de página anómalos: memoria con permisos PAGE_EXECUTE_READWRITE (ejecutable y escribible a la vez). El código legítimo cargado desde fichero mapeado casi nunca necesita ambos permisos simultáneamente; esa combinación es la huella clásica de un payload inyectado en tiempo de ejecución.
Ausencia de fichero mapeado: la región VAD no está respaldada por ningún fichero en disco (no es un MappedFile), lo que indica que el contenido llegó a memoria por otra vía que no es el cargador de PE estándar (por ejemplo, VirtualAllocEx + WriteProcessMemory desde otro proceso).
Firma de cabecera PE (MZ) dentro de memoria privada: si la región contiene la cabecera MZ pero no corresponde a ningún módulo cargado legítimamente, es indicio directo de un PE completo inyectado y posiblemente reflejado (reflective DLL injection).

La salida de malfind incluye un volcado hexadecimal y el desensamblado de las primeras instrucciones de cada región marcada, lo que permite una primera valoración visual: shellcode suele mostrar patrones reconocibles (NOPs, prólogos atípicos, saltos calculados) frente al código compilado normal.

4.1 Process hollowing e inyección: cómo distinguirlos con los plugins disponibles

Process hollowing es la técnica en la que el atacante lanza un proceso legítimo en estado suspendido (por ejemplo, svchost.exe o explorer.exe), vacía su imagen en memoria original y la sustituye por código malicioso, para después reanudar la ejecución. El resultado es un proceso con el nombre y PID de algo legítimo, pero cuyo contenido no coincide con el binario real en disco. La metodología de detección combina varios plugins, no uno solo:

Indicio	Plugin que lo revela	Qué mirar exactamente
Ruta de ejecución anómala para el nombre del proceso	`windows.pslist` / `windows.cmdline`	`svchost.exe` ejecutándose fuera de `C:WindowsSystem32`, o sin los argumentos `-k` típicos de un servicio real
Región de memoria ejecutable+escribible sin fichero respaldando	`windows.malfind`	VAD con permisos RWX y sin `MappedFile` asociado dentro de un proceso «normal»
Discrepancia entre el PE en memoria y el binario real en disco	`windows.dumpfiles` + comparación de hash con el binario legítimo	El hash del ejecutable volcado desde memoria no coincide con el hash del fichero original conocido/limpio
Padre inesperado en el árbol de procesos	`windows.pstree`	`svchost.exe` cuyo padre no es `services.exe`, como debería ser siempre en un sistema Windows sano

Ningún plugin aislado confirma process hollowing por sí solo: la confirmación llega de la intersección de indicios. Un svchost.exe con padre correcto (services.exe) pero con región malfind positiva y sin los argumentos -k esperados en cmdline es un caso de manual para escalar de inmediato.

5. Servicios: windows.svcscan

python3 vol.py -f volcado.raw windows.svcscan

Este plugin escanea la memoria en busca de las estructuras internas de servicios de Windows (equivalente a lo que expondría services.msc o sc query, pero leído directamente de memoria, sin depender del propio SCM del sistema comprometido). La salida incluye nombre del servicio, nombre para mostrar, tipo, estado, tipo de arranque y ruta al binario o DLL asociado. Es la vía clásica de detección de persistencia vía servicio: un nombre que imita a uno legítimo (WindowsUpdate32 en vez de wuauserv) o un binario que apunta a una ruta de usuario en lugar de System32 es indicio directo de persistencia maliciosa.

6. Registro en memoria: windows.registry.hivelist y windows.registry.printkey

Buena parte del registro de Windows permanece cacheado en memoria mientras el sistema está encendido, lo que permite consultarlo sin las hives en disco —útil para confirmar el estado del registro exactamente en el instante de la captura—.

# Listar todas las hives de registro localizadas en memoria, con su offset virtual
python3 vol.py -f volcado.raw windows.registry.hivelist

# Consultar una clave concreta (Run key, ejemplo clásico de persistencia)
python3 vol.py -f volcado.raw windows.registry.printkey --key "MicrosoftWindowsCurrentVersionRun"

# Consultar dentro de una hive específica usando su offset (obtenido de hivelist)
python3 vol.py -f volcado.raw windows.registry.printkey --offset 0xffffb08c12340000 --key "MicrosoftWindowsCurrentVersionRun"

windows.registry.hivelist localiza en memoria cada hive cargada (SYSTEM, SOFTWARE, SAM, NTUSER.DAT de cada usuario con sesión activa o reciente) junto a su ruta en disco y offset virtual, dato que después se pasa a printkey para acotar la búsqueda cuando hay ambigüedad (por ejemplo, varias hives NTUSER.DAT). windows.registry.printkey vuelca el contenido de una clave y sus subclaves; las claves de arranque automático (...Run, ...RunOnce, WinlogonShell, WinlogonUserinit) son la primera parada obligatoria en cualquier caza de persistencia vía registro.

7. Extracción de artefactos: dumpfiles, memmap y pslist –dump

Identificado un proceso, región de memoria o fichero cacheado como sospechoso, el siguiente paso es extraerlo a disco: cálculo de hash y consulta en VirusTotal, desensamblado en IDA/Ghidra, o detonación controlada en sandbox.

# Volcar el ejecutable completo y las secciones de memoria de un proceso
python3 vol.py -f volcado.raw windows.pslist --pid 4132 --dump

# Volcar el mapa de memoria completo de un proceso (todas las páginas residentes)
python3 vol.py -f volcado.raw windows.memmap --pid 4132 --dump

# Volcar ficheros cacheados en memoria (objetos _FILE_OBJECT) asociados a un proceso
python3 vol.py -f volcado.raw windows.dumpfiles --pid 4132

# Volcar un _FILE_OBJECT concreto por su dirección virtual (obtenida, p. ej., de windows.handles)
python3 vol.py -f volcado.raw windows.dumpfiles --virtaddr 0xffffb08c15a2b010

# Filtrar dumpfiles por expresión regular sobre el nombre del fichero
python3 vol.py -f volcado.raw windows.dumpfiles --filter ".exe$|.dll$" --ignore-case

windows.pslist --dump extrae el ejecutable de un proceso reconstruyendo sus secciones desde memoria, lo que a menudo permite recuperar un binario borrado del disco tras ejecutarse (o que nunca existió en disco). windows.memmap --dump vuelca el espacio de direcciones completo del proceso, página a página, útil cuando el objetivo es todo el contenido residente (por ejemplo, para string carving posterior sobre credenciales o configuración de malware). windows.dumpfiles trabaja a nivel de objeto _FILE_OBJECT del kernel: recupera ficheros cacheados en memoria por el cache manager de NTFS, lo que a veces permite recuperar contenido de un fichero ya borrado del disco pero cuyas páginas siguen en cache.

8. Escaneo YARA en memoria: yarascan y windows.vadyarascan

Cuando ya tienes una regla YARA (propia, de un feed de inteligencia de amenazas, o de un repositorio público de una familia de malware conocida), puedes aplicarla directamente sobre el volcado sin extraer nada antes.

# yarascan: plugin genérico (no específico de Windows), escanea TODA la memoria del volcado con una regla en fichero
python3 vol.py -f volcado.raw yarascan.YaraScan --yara-file reglas_apt.yar

# Con una regla pasada directamente como cadena
python3 vol.py -f volcado.raw yarascan.YaraScan --yara-string "rule test { strings: $a = "mimikatz" condition: $a }"

# windows.vadyarascan: específico de Windows, escanea únicamente las regiones VAD (espacio de usuario) de procesos concretos
python3 vol.py -f volcado.raw windows.vadyarascan --yara-file reglas_apt.yar --pid 4132

# Búsqueda de cadenas anchas (Unicode/wide) e insensible a mayúsculas, útil para detectar claves de configuración de malware en memoria
python3 vol.py -f volcado.raw yarascan.YaraScan --yara-string "cobaltstrike" --insensitive --wide

La diferencia entre ambos no es cosmética: yarascan.YaraScan es un plugin genérico de la capa base (no lleva el prefijo windows.) que recorre toda la memoria física o el espacio del kernel, mientras que windows.vadyarascan es específico de Windows y acota el escaneo a las regiones VAD de procesos concretos vía --pid, mucho más rápido cuando ya sabes qué proceso inspeccionar. La estrategia habitual es lanzar primero un escaneo amplio con yarascan.YaraScan contra reglas genéricas de familias conocidas (Cobalt Strike, Metasploit, Mimikatz), y después acotar con windows.vadyarascan al PID ya sospechoso.

9. Laboratorio: analizar un volcado con un proceso malicioso inyectado

Objetivo: aplicar el flujo completo de este módulo sobre un volcado de laboratorio que contiene un proceso legítimo con código inyectado (por ejemplo, un payload de Meterpreter o Cobalt Strike inyectado en un notepad.exe o explorer.exe de una VM Windows 10/11, generado en un entorno aislado sin salida a Internet).

Identifica el sistema con windows.info y confirma que el símbolo se ha resuelto sin errores.
Enumera procesos por las dos vías: windows.pslist y windows.psscan, comparando el conjunto de PIDs. El hábito de comparar ambos listados es el objetivo aquí, aunque en este escenario el proceso inyectado no esté oculto por DKOM.
Reconstruye el árbol de procesos con windows.pstree y localiza el proceso que sirvió de vector inicial.
Revisa la línea de comandos de los procesos sospechosos con windows.cmdline --pid <PID>.
Lanza windows.malfind sin filtro sobre todo el volcado y localiza la región VAD sospechosa en el proceso objetivo (permisos RWX, sin MappedFile, posible cabecera MZ en memoria privada).
Vuelca la región con windows.malfind --pid <PID> --dump y calcula su hash SHA-256.
Confirma la conexión de red con windows.netscan, buscando una salida del PID objetivo hacia el handler/listener de tu propio laboratorio.
Escanea con YARA usando windows.vadyarascan --pid <PID> contra una regla del framework C2 usado en el laboratorio, y confirma coincidencia dentro de la misma región que marcó malfind.
Documenta los hallazgos cruzados: PID, proceso, indicio en cada plugin, hash del artefacto y conclusión motivada.

10. Errores comunes

Fiarse solo de pslist y no ejecutar nunca psscan. Es el error más grave del módulo: pslist confía en la misma lista enlazada del kernel que un rootkit con DKOM puede manipular. Si un proceso está desenlazado, pslist no lo verá, y creerás que el sistema está limpio cuando no lo está.
Ignorar malfind «porque no hay tiempo». Es el plugin que detecta específicamente lo que el disco no puede mostrar: malware fileless e inyección de código. Saltárselo en un incidente activo deja sin cubrir el vector más probable si ya has descartado ejecutables maliciosos evidentes en disco.
Interpretar cualquier resultado de malfind como confirmación de compromiso sin revisión manual. Genera falsos positivos legítimos: packers comerciales, motores JIT (.NET, Java, navegadores) y ciertos antivirus usan regiones RWX de forma lícita. Cada hallazgo exige revisar el desensamblado y cruzarlo con otros indicios antes de concluir compromiso.
No comparar contra una línea base conocida. Sin saber qué procesos, servicios y conexiones son «normales» en el parque de la organización, es imposible distinguir una anomalía real de un falso positivo.
Analizar directamente sobre el volcado original. Igual que con una imagen de disco, el original no se toca: se calcula su hash al recibirlo y se trabaja sobre una copia, dejando el original intacto.
Olvidar que los símbolos deben resolverse correctamente antes de fiarte de cualquier resultado. Si windows.info muestra errores de resolución, el resto de plugins pueden devolver resultados parciales o erróneos. Nunca continúes sin verificar primero que el símbolo se resolvió bien.
Limitar el escaneo YARA a --pid antes de tener un sospechoso. windows.vadyarascan con --pid es rápido pero requiere ya saber qué proceso mirar. En la fase exploratoria, un escaneo con yarascan.YaraScan contra todo el volcado es el que puede revelar el PID sospechoso que aún no conocías.

11. Ejercicio

Sobre un volcado de memoria de tu laboratorio (generado con WinPMEM o DumpIt sobre una VM Windows con un simulacro de compromiso, siguiendo la captura descrita en el módulo de adquisición forense):

Ejecuta windows.info y anota la build y si el símbolo se resolvió sin errores.
Ejecuta windows.pslist y windows.psscan por separado, exporta ambos a CSV (-r csv) y compara los conjuntos de PID. Documenta cualquier discrepancia e investígala.
Localiza en windows.pstree cualquier proceso cuyo padre no sea el esperado (por ejemplo, un hijo directo inesperado de explorer.exe o de un proceso Office).
Ejecuta windows.malfind contra todo el volcado y entiende cada columna de su salida (protección de página, tamaño de la región, presencia de fichero mapeado), aunque el resultado sea negativo.
Ejecuta windows.netscan y windows.svcscan, documentando cualquier conexión o servicio que no reconozcas de una instalación limpia.
Consulta MicrosoftWindowsCurrentVersionRun con windows.registry.printkey y verifica cada entrada.
Entrega un informe corto con: sistema identificado, resultado pslist/psscan, hallazgos de malfind, conexiones/servicios revisados y conclusión motivada.

Preguntas frecuentes

¿Por qué Volatility 3 ya no usa el comando –profile de Volatility 2?

Porque el modelo de perfiles precompilados de Volatility 2 obligaba al proyecto a publicar un perfil nuevo por cada build de Windows, dejando sistemáticamente atrás las versiones más recientes. Volatility 3 sustituye ese modelo por símbolos ISF (Intermediate Symbol Format), que el propio framework resuelve y descarga automáticamente identificando la build exacta a partir de estructuras internas del volcado, sin que el analista tenga que indicar nada manualmente en la mayoría de los casos.

¿Es obligatorio ejecutar psscan si ya he ejecutado pslist y todo parece normal?

Sí, siempre. Ambos plugins consultan fuentes de datos distintas: pslist confía en la lista enlazada del kernel, que un rootkit con capacidades DKOM puede manipular para ocultar su propio proceso; psscan escanea la memoria física por firma, sin depender de esa lista, y por eso encuentra tanto procesos ocultos como ya terminados. Que pslist «parezca normal» no descarta nada: es exactamente el resultado que produciría un sistema comprometido con un rootkit bien hecho.

¿Un resultado positivo de windows.malfind confirma siempre malware?

No de forma automática. malfind señala regiones con características típicas de inyección (permisos RWX, ausencia de fichero mapeado, cabeceras PE en memoria privada), pero algunos procesos legítimos generan patrones similares: motores JIT (.NET, Java, navegadores), packers comerciales y algunas soluciones de seguridad. Cada hallazgo debe revisarse manualmente —desensamblado y cruce con otros plugins (conexiones del mismo PID, línea de comandos, árbol de procesos)— antes de concluir inyección maliciosa real.

¿Qué diferencia hay entre yarascan.YaraScan y windows.vadyarascan?

yarascan.YaraScan es un plugin genérico de la capa base, sin prefijo de sistema operativo, que escanea la memoria de forma amplia sin acotarse a estructuras de proceso de Windows. windows.vadyarascan es específico de Windows y aplica las reglas YARA únicamente sobre las regiones VAD de procesos concretos, filtrable por --pid. En la práctica se usa primero un escaneo amplio con yarascan.YaraScan, y después windows.vadyarascan acotado a un PID ya sospechoso, para un escaneo más rápido y dirigido.

¿Puedo analizar un volcado de memoria de Linux con los mismos plugins de este módulo?

No directamente: los plugins descritos aquí llevan el prefijo windows. porque interpretan estructuras específicas del kernel de Windows (EPROCESS, PEB, VADs, hives de registro). Para volcados Linux, Volatility 3 ofrece un conjunto equivalente bajo el prefijo linux. (linux.pslist, linux.bash, linux.malfind), que trabaja sobre task_struct y requiere generar previamente el símbolo ISF específico para la versión exacta del kernel objetivo, ya que a diferencia de Windows no existe un repositorio centralizado universal que cubra todas las combinaciones de distribución y kernel.

«Volatility 3 requires symbol tables (in the Intermediate Symbol File format, or ISF) in order to reconstruct the data structures used within an operating system’s kernel… Unlike Volatility 2, there is no need to identify a profile manually; the correct symbol table is identified automatically based on information embedded within the memory sample itself.»

— Volatility 3 Documentation, «Symbol Tables», volatility3.readthedocs.io, The Volatility Foundation.

Módulo 8: Análisis de memoria RAM con Volatility 3