Introducción

Este ejercicio parte de un volcado de memoria RAM (memdump.mem) de un servidor Windows comprometido, con un enunciado sencillo: reconstruir qué hizo el atacante a partir únicamente de lo que quedó en memoria, sin tocar el disco. La herramienta principal es Volatility, y el entorno de análisis, Kali Linux.

Preparar la evidencia

El volcado llega comprimido en .7z:

7z x memdump.7z
ls
# memdump.mem

Para el análisis usé Volatility 2 en vez de la versión 3 — la 3 no resolvía correctamente los símbolos para esta imagen concreta:

git clone https://github.com/volatilityfoundation/volatility.git
cd volatility
sudo python2 setup.py install

Identificar el sistema operativo

Antes de poder usar la mayoría de plugins de Volatility 2 hace falta saber qué perfil de sistema operativo aplicar. El plugin imageinfo analiza las estructuras internas de la RAM y lo sugiere:

python2 vol.py -f memdump.mem imageinfo

Salida de imageinfo: perfil sugerido VistaSP1x86, fecha del volcado 2015-09-03

Windows Vista SP1 / Server 2008 SP1, arquitectura x86 con PAE, un único procesador, y la fecha del volcado: 3 de septiembre de 2015. Con el perfil (VistaSP1x86) ya se puede pasar a inspeccionar el resto de la memoria.

Procesos en ejecución

python2 vol.py -f memdump.mem --profile=VistaSP1x86 pslist

Lista de procesos activos en el volcado, incluyendo XAMPP, dos instancias de cmd.exe y FTK Imager

Entre los procesos del propio sistema aparecen los interesantes: un XAMPP completo (xampp-control.exe, httpd.exe, mysqld.exe, FileZillaServer.exe) activo desde el 23 de agosto, dos instancias de cmd.exe abiertas en momentos distintos (23 de agosto y 2 de septiembre, ambas con el mismo PPID — explorer.exe, PID 816, lo que indica que se abrieron desde el escritorio del propio servidor), y FTK Imager.exe, la herramienta que capturó esta misma memoria el 3 de septiembre.

Reconstruyendo lo que hizo el atacante

Por qué capturar la RAM antes de apagar

La RAM es la fuente de evidencia más volátil de un sistema: su contenido solo existe mientras hay alimentación eléctrica constante, y desaparece de forma inmediata e irrecuperable al apagar o reiniciar. El orden de volatilidad, de mayor a menor, es: caché de CPU y registros del procesador → RAM, tabla ARP y tabla de procesos → disco → configuración de red → medios externos.

Si el servidor se hubiera apagado antes de capturar la memoria, se habría perdido para siempre: los procesos activos del atacante, el historial de comandos, las conexiones de red establecidas, credenciales y tokens de sesión en memoria, cualquier malware residente solo en RAM, y la evidencia del propio usuario creado antes de que persistiera en disco. Capturar la RAM primero fue la decisión correcta.

El historial de comandos

Con el perfil identificado, el plugin cmdscan recupera el historial completo de las sesiones de cmd.exe:

python2 vol.py -f memdump.mem --profile=VistaSP1x86 cmdscan

Historial de comandos recuperado de la memoria: ipconfig, creación de usuario, grupo Remote Desktop Users y reglas de firewall

El historial se agrupa en tres fases claras:

Fase Comandos Objetivo
Reconocimiento ipconfig (x2) Obtener información de la red del servidor
Creación de usuario net user user1 ... /add (3 intentos) Crear un usuario persistente — los dos primeros intentos fallaron por política de contraseñas, hasta usar Root@psut
Escalada de privilegios net localgroup "Remote Desktop Users" user1 /add Añadir el usuario nuevo al grupo de acceso remoto
Apertura del firewall netsh firewall set service type=remotedesktop mode=enable scope=subnet Permitir conexiones RDP (puerto 3389) desde toda la subred

El propio historial delata el nivel del atacante: aparecen varias consultas de ayuda (net /?, netsh firewall /?) antes de los comandos reales, como quien no se sabe la sintaxis de memoria y va probando.

Cómo se introdujeron: a mano, no con un script

El plugin consoles va un paso más allá que cmdscan — no solo recupera los comandos, sino la pantalla completa de la consola, con las respuestas del sistema incluidas:

python2 vol.py -f memdump.mem --profile=VistaSP1x86 consoles

Salida de consoles mostrando el error tipográfico “fireall” corregido a “firewall” en el siguiente comando

Esto confirma varias cosas a la vez: la consola se abrió con privilegios de Administrador (el título de la ventana es literalmente “Administrator: Command Prompt”), el proceso padre es explorer.exe, es decir que se abrió desde el escritorio del propio sistema. Pero el detalle que más me gusta es el error tipográfico: el atacante escribió netsh fireall set service..., Windows respondió que el comando no existía, y en la siguiente línea lo corrigió a firewall. Eso descarta de raíz que fuera un script automatizado — un script no comete erratas y las corrige sobre la marcha. Fue una persona, escribiendo en tiempo real.

La actividad maliciosa

Uniendo todo: el atacante creó un usuario local (user1 / Root@psut) sin autorización, lo añadió al grupo Remote Desktop Users, y modificó el firewall para permitir RDP desde toda la subred. El resultado es una puerta trasera persistente — puede volver a entrar por escritorio remoto en cualquier momento, sin necesidad de explotar nada de nuevo.

El perfil que se desprende del historial (reconocimiento superficial, sin destruir datos ni instalar ransomware, simplemente asegurando una vía de entrada futura) encaja con alguien curioso más que con un atacante con motivación económica — pero sigue siendo una intrusión grave: crear un usuario no autorizado con acceso remoto completo es exactamente el tipo de backdoor que un forense tiene que documentar con precisión, motivación aparte.

Línea de tiempo reconstruida

Fecha Evento
23/08/2015 10:30 Se abre una consola CMD como Administrador (PID 612)
23/08/2015 10:30 ipconfig — reconocimiento de red
23/08/2015 10:30 Creación del usuario user1 tras varios intentos fallidos
23/08/2015 10:30 user1 añadido al grupo Remote Desktop Users
23/08/2015 10:30 Firewall abierto para permitir RDP desde la subred
02/09/2015 09:28 Segunda sesión de cmd.exe (PID 1972) — confirma la configuración RDP
03/09/2015 10:03 Se captura la imagen de memoria con FTK Imager

Conclusión

Lo que hace interesante este ejercicio no es la sofisticación del ataque —crear un usuario y abrir el firewall es de lo más básico que existe—, sino cuánto se puede reconstruir sin tocar el disco: quién entró, qué escribió, cuándo, con qué privilegios, y hasta que se equivocó al teclear. La RAM guarda muchísimo más de lo que uno esperaría, y por eso capturarla antes de apagar cualquier máquina comprometida no es opcional.