Forense de memoria RAM I: adquisición y estructuras

Todo lo visto hasta ahora vive en disco: sobrevive al apagado, por eso se adquiere después. La memoria RAM es justo lo contrario — el artefacto más valioso y el más efímero de todos, en lo más alto del orden de volatilidad del módulo 1. Este módulo cubre cómo capturarla sin destruirla en el proceso, y cómo una herramienta como Volatility3 consigue interpretar un volcado de bytes aparentemente aleatorio como una estructura con sentido.

1. Por qué la memoria importa

Hay categorías enteras de evidencia que solo existen en RAM mientras el equipo está encendido, y que ningún artefacto de disco sustituye del todo:

• Procesos en ejecución en el momento exacto de la captura, incluidos los que ya terminaron de escribirse en disco (o que nunca llegaron a escribirse).
• Malware fileless: código que se ejecuta directamente en memoria (inyectado en un proceso legítimo, o cargado reflexivamente) sin dejar nunca un ejecutable en disco — invisible para Prefetch, Shimcache y Amcache (módulo 5).
• Claves de cifrado y contraseñas en texto claro: mientras un programa las usa, suelen estar descifradas en algún punto de la memoria del proceso.
• Conexiones de red activas en el instante de la captura, incluidas las que un rootkit puede estar ocultando a nivel de sistema operativo pero no a nivel de estructuras internas del kernel.
• Comandos tecleados en una consola que aún no se han guardado (o nunca se guardarán) en el historial de disco.

2. Herramientas de adquisición de memoria

3. Adquisición en Windows con WinPmem

$ winpmem_mini_x64.exe dump_caso08.aff4
Driver written to C:\Windows\Temp\pmem.sys
Imaging memory...  [####################] 100%
Output: dump_caso08.aff4  (16.0 GB)

WinPmem instala un controlador temporal en modo kernel que le permite leer la memoria física directamente, saltándose las restricciones que el propio Windows impone al espacio de usuario. Al terminar, el controlador se descarga; el único rastro que deja en disco es el propio fichero de volcado si no se elimina.

4. Adquisición en Linux con LiME

LiME se compila como módulo de kernel específico para la versión exacta del kernel objetivo — no hay un binario universal, porque las estructuras internas del kernel cambian entre versiones (lo que conecta directamente con el punto 5).

$ sudo insmod lime-5.15.0-91-generic.ko "path=dump_caso08.lime format=lime"
[  812.441205] lime: module loaded, dumping to dump_caso08.lime
[  819.883012] lime: dump complete (17179869184 bytes)

5. Cómo Volatility interpreta bytes en bruto

Un volcado de memoria es, a simple vista, una secuencia enorme de bytes sin estructura visible. Volatility la interpreta localizando en esos bytes las estructuras internas del kernel que el propio sistema operativo usa para gestionar procesos y memoria: en Windows, cada proceso tiene una estructura EPROCESS; en Linux, un task_struct. Encontrar esas estructuras y saber interpretar sus campos exige conocer el diseño exacto de esa versión concreta del sistema operativo — el mismo campo puede estar en un offset distinto entre dos builds de Windows, o entre dos versiones de kernel de Linux.

Volatility3 resuelve esto con symbol packs: tablas que describen, para cada versión de sistema operativo, dónde está cada campo de cada estructura relevante. Sin el symbol pack correcto, Volatility3 no puede interpretar la memoria con fiabilidad.

$ pip install volatility3
vol.py -f dump_caso08.aff4 windows.info
Kernel Base            0xf80612a00000
NTBuildLab             22621.1.amd64fre.ni_release.220506-1250
Symbols                https://downloads.volatilityfoundation.org/volatility3/symbols/windows/ntkrnlmp.pdb/...json.xz

El propio plugin windows.info identifica la versión exacta y, si hace falta, descarga automáticamente el symbol pack correspondiente la primera vez que se analiza esa versión de sistema.

6. Primeros plugins de reconocimiento

Con la versión ya identificada, el primer paso de cualquier análisis es listar los procesos en ejecución en el momento de la captura:

$ vol.py -f dump_caso08.aff4 windows.pslist
PID    PPID   ImageFileName       CreateTime
612    4      lsass.exe           2026-03-14 02:01:10
4821   612    svc_update.exe      2026-03-14 02:08:55
4902   4821   powershell.exe      2026-03-14 02:09:12

Ya en esta primera lista hay una anomalía digna de investigar: svc_update.exe con PID 4821 tiene como padre a lsass.exe (PID 612) — un proceso de usuario normal nunca debería colgar directamente del proceso de autenticación de Windows. Esto se trabaja a fondo en el módulo 9 (procesos maliciosos, inyección, rootkits), que retoma exactamente este volcado.

Autoevaluación

1. Nombra tres tipos de evidencia que solo existen en memoria y no en ningún artefacto de disco visto hasta ahora.
2. ¿Por qué LiME necesita compilarse para la versión exacta del kernel, en lugar de usar un binario universal como WinPmem en Windows?
3. ¿Qué es un symbol pack en Volatility3 y qué pasa si se usa el equivocado para la versión del sistema analizado?
4. ¿Por qué cargar un módulo de kernel para capturar memoria es, en cierto sentido, contradictorio con el principio de no alterar la evidencia, y por qué se acepta igualmente como procedimiento estándar?
5. En la salida de windows.pslist de este capítulo, ¿qué detalle concreto de la relación padre-hijo entre procesos debería llamar la atención de un analista?