// Amadey — APT-C-36 

// Memory Forensics · Volatility3

// Dificultad: Medium

// Categoría: Endpoint Forensics

DISCLAIMER

Este writeup tiene fines educativos y de práctica profesional. Las respuestas corresponden al laboratorio público de CyberDefenders. Las direcciones IP, hashes, rutas de archivo y procesos mostrados pertenecen al volcado de memoria del escenario controlado del reto, no a infraestructura real en producción.

SERIE // CyberDefenders Labs #05

0x00 — Introducción

Quinto post de la serie de laboratorios de CyberDefenders. 

En esta ocasión me enfrento a Amadey — APT-C-36, un laboratorio de Endpoint Forensics donde investigo un incidente de seguridad desencadenado por una alerta EDR fuera de horario.

El malware en cuestión es el Amadey Trojan Stealer, una cepa especializada en reconocimiento, recolección de datos, robo de credenciales y establecimiento de conexiones persistentes con servidores remotos. 

Su diseño modular le permite descargar cargas útiles adicionales para ampliar sus capacidades según los objetivos del atacante.

Al operar en memoria, identificar sus huellas exige técnicas forenses profundas. 

A lo largo de este análisis utilizaremos Volatility3 para examinar procesos, rastrear actividad de red, localizar archivos sospechosos y desenmascarar los mecanismos de persistencia del malware.

0x01 — El Escenario

ElementoDetalle
Familia de malwareAmadey Trojan Stealer
Alerta inicialEDR fuera de horario — actividad sospechosa en estación Windows
EvidenciaVolcado de memoria (Windows 7 x64)
HerramientaVolatility3
MisiónAnalizar procesos, comunicaciones C2, cargas útiles y mecanismos de persistencia

0x02 — Análisis

En el análisis de volcado de memoria, determinar la raíz de la actividad maliciosa es esencial para comprender el alcance de la intrusión. ¿Cómo se llama el proceso principal que desencadenó este comportamiento malicioso?

El primer paso en cualquier análisis forense de memoria es enumerar los procesos activos para identificar anomalías. 

Volatility3 ofrece el plugin windows.pstree que muestra el árbol de procesos con sus relaciones padre-hijo, PIDs, timestamps de creación y conteo de hilos.

vol.py -f [memory_dump] windows.pstree.PsTree

Al examinar la salida, encontramos un proceso llamado lssass.exe con PID 2748. Aunque se parece mucho al legítimo lsass.exe (Local Security Authority Subsystem Service), la "s" adicional en su nombre delata que es un proceso de enmascaramiento diseñado para evadir la detección.

Esta técnica, conocida como process masquerading, es habitual en campañas de malware: el atacante nombra su binario de forma similar a procesos legítimos del sistema para pasar desapercibido ante analistas y herramientas de monitorización.

Además, lssass.exe aparece vinculado a un proceso hijo rundll32.exe (PID 3064), que se utiliza frecuentemente para ejecutar código malicioso a través de archivos DLL. El timestamp de creación de ambos procesos se correlaciona con la ventana temporal del incidente.

Respuesta: lssass.exe

Una vez identificado el proceso no autorizado, su ubicación exacta en el dispositivo puede revelar más sobre su naturaleza y origen. ¿Dónde se encuentra alojado este proceso en la estación de trabajo?

Con el proceso sospechoso identificado, el siguiente paso es determinar desde qué ruta se ejecuta. El plugin windows.cmdline de Volatility3 extrae los argumentos de línea de comando asociados a un proceso, revelando la ubicación del ejecutable.

vol.py -f [memory_dump] windows.cmdline --pid 2748
vol.py -f /home/ubuntu/Desktop/'Start here'/Artifacts/'Windows 7 x64-Snapshot4.vmem' windows.cmdline | grep lssass.exe.

La salida revela que lssass.exe se ejecuta desde el directorio Temp del usuario, una ubicación que los analistas debemos vigilar especialmente las carpetas temporales son escribibles por usuarios estándar y a menudo quedan fuera de los escaneos antivirus, lo que las convierte en un refugio habitual para cargas útiles maliciosas.

El uso de la notación 0XSH3R~1 indica un formato de nombre corto (8.3), una convención heredada de Windows que trunca nombres de directorio largos. Este tipo de abreviatura aparece con frecuencia en rutas donde el malware intenta dificultar la trazabilidad.

Respuesta: C:\Users\0XSH3R~1\AppData\Local\Temp\925e7e99c5\lssass.exe

Las comunicaciones externas persistentes sugieren intentos del malware de comunicarse con el servidor C2C. ¿Puede identificar la IP del servidor de Comando y Control (C2C) con la que interactúa el proceso?

Los servidores de Comando y Control (C2) son el eje central de cualquier operación de malware: permiten al atacante enviar instrucciones a las máquinas comprometidas, exfiltrar información robada y desplegar cargas útiles adicionales. Detectar estas comunicaciones es prioritario en toda respuesta a incidentes.

El plugin windows.netscan de Volatility3 analiza las conexiones de red capturadas en el volcado de memoria, mostrando direcciones IP locales y remotas, puertos y procesos asociados.

vol.py -f [memory_dump] windows.netscan | grep lssass.exe

vol.py -f /home/ubuntu/Desktop/'Start here'/Artifacts/'Windows 7 x64-Snapshot4.vmem' windows.netscan | grep lssass.exe


El resultado muestra dos conexiones TCP cerradas desde lssass.exe (PID 2748) hacia la dirección IP externa 41.75.84.12 por el puerto 80. El uso de HTTP estándar es una estrategia clásica para camuflar tráfico malicioso como navegación web legítima y evadir firewalls e IDS que no inspeccionan el contenido del tráfico.

Respuesta: 41.75.84.12

Tras el vínculo del malware con el C2C, es probable que el malware esté obteniendo herramientas o módulos adicionales. ¿Cuántos archivos distintos intenta traer a la estación de trabajo comprometida?

Sabiendo que el proceso utiliza tráfico HTTP para comunicarse con el C2, el análisis se amplía para buscar URL y solicitudes HTTP embebidas en la memoria del proceso. El malware modular como Amadey explota frecuentemente HTTP para descargar componentes adicionales.

Primero se extrae el volcado de memoria del proceso sospechoso con windows.memmap, y después se buscan peticiones HTTP GET con la utilidad strings:

vol.py -f [memory_dump] windows.memmap.Memmap --pid 2748 --dump

vol.py -f /home/ubuntu/Desktop/'Start here'/Artifacts/'Windows 7 x64-Snapshot4.vmem' windows.memmap.Memmap --pid 2748 --dump, 

strings pid.2748.dmp | grep "GET /"

Las cadenas extraídas revelan dos solicitudes HTTP GET diferenciadas:

Solicitud HTTPArchivo
GET /rock/Plugins/cred64.dll HTTP/1.1cred64.dll
GET /rock/Plugins/clip64.dll HTTP/1.1clip64.dll

Los nombres son reveladores: cred64.dll apunta a un módulo de robo de credenciales, mientras que clip64.dll sugiere funcionalidad de monitorización o secuestro del portapapeles. 

Esta arquitectura basada en plugins es característica de Amadey, que descarga módulos según los objetivos del atacante.

Respuesta: 2 (GET)

Identificar los puntos de almacenamiento de estos componentes adicionales es fundamental para la contención y la limpieza. ¿Cuál es la ruta completa del archivo descargado y utilizado por el malware en su actividad maliciosa?

Una vez identificados los módulos que descarga el malware, el siguiente paso es localizar dónde los almacena en el sistema de archivos. Para ello, el plugin windows.filescan de Volatility3 escanea la memoria en busca de objetos de archivo y sus metadatos asociados.

vol.py -f [memory_dump] windows.filescan | grep -E "cred64|clip64"
vol.py -f /home/ubuntu/Desktop/'Start here'/Artifacts/'Windows 7 x64-Snapshot4.vmem' windows.cmdline | grep dll

El resultado revela la ubicación de clip64.dll dentro del directorio AppData\Roaming del usuario, en una subcarpeta con nombre generado aleatoriamente (116711e5a2ab05). Esta generación dinámica de nombres de carpeta es una táctica que los troyanos como Amadey emplean para dificultar la detección estática y complicar los esfuerzos de limpieza.

Verificando con windows.cmdline filtrado por DLL, confirmamos que rundll32.exe (PID 3064) ejecuta directamente clip64.dll llamando a su función Main:

vol.py -f [memory_dump] windows.cmdline | grep dll

El directorio AppData\Roaming es un objetivo habitual del malware: los usuarios estándar tienen permisos de escritura y frecuentemente queda excluido de los escaneos antivirus convencionales.

Respuesta: C:\Users\0xSh3rl0ck\AppData\Roaming\116711e5a2ab05\clip64.dll

Una vez recuperado, el malware pretende activar sus componentes adicionales. ¿Qué proceso secundario inicia el malware para ejecutar estos archivos?

Dado que las cargas útiles de segunda etapa son archivos DLL, el malware necesita un mecanismo para cargarlas y ejecutarlas. 

La utilidad nativa de Windows rundll32.exe cumple exactamente esa función, y es uno de los binarios más abusados en la técnica conocida como Living off the Land (LOLBins).

Como vimos en el árbol de procesos de Q1, rundll32.exe (PID 3064) aparece como hijo directo de lssass.exe (PID 2748). 

Esta relación padre-hijo confirma que el malware genera rundll32.exe para ejecutar las DLL descargadas, permitiendo ampliar sus capacidades sin levantar sospechas, ya que rundll32.exe es un binario firmado y confiable del propio sistema operativo.

Respuesta: rundll32.exe

Comprender la gama completa de mecanismos de persistencia de Amadey puede ayudar a una mitigación eficaz. Aparte de las ubicaciones ya destacadas, ¿dónde más podría el malware garantizar su presencia constante?

La persistencia es una táctica esencial del malware para sobrevivir a reinicios y cierres de sesión. 

Amadey, como troyano modular que depende de comunicaciones C2 continuas, necesita garantizar su ejecución automática cada vez que el sistema arranca.

Para investigar mecanismos adicionales de persistencia, utilizamos nuevamente windows.filescan buscando instancias del ejecutable sospechoso:

vol.py -f [memory_dump] windows.filescan | grep lssass.exe

vol.py -f /home/ubuntu/Desktop/'Start here'/Artifacts/'Windows 7 x64-Snapshot4.vmem' windows.filescan | grep lssass.exe


Los resultados revelan dos ubicaciones clave:

RutaPropósito
\Users\0XSH3R~1\AppData\Local\Temp\925e7e99C5\lssass.exePunto de ejecución temporal (ya conocido)
\Windows\System32\Tasks\lssass.exeMecanismo de persistencia — Tarea programada

La presencia de lssass.exe en el directorio System32\Tasks indica que el malware se registró como una tarea programada de Windows. 

Esta técnica le permite reiniciarse automáticamente tras cada arranque del sistema o en intervalos predefinidos.

La persistencia vía Task Scheduler es especialmente sigilosa porque aprovecha un componente legítimo y confiable de Windows, lo que reduce significativamente la probabilidad de activar alertas en herramientas de seguridad convencionales.

Respuesta: C:\Windows\System32\Tasks\lssass.exe

0x03 — Resumen del Ataque

FaseAcciónIOC / Artefacto
Ejecución inicialProceso enmascarado como lsass.exelssass.exe (PID 2748)
StagingEjecución desde carpeta temporalAppData\Local\Temp\925e7e99c5\
C2Comunicación HTTP con servidor externo41.75.84.12:80
Descarga de pluginsObtención de módulos DLL vía HTTP GETcred64.dll · clip64.dll
AlmacenamientoDLL en AppData\Roaming116711e5a2ab05\clip64.dll
Ejecución modularCarga de DLL mediante LOLBinrundll32.exe (PID 3064)
PersistenciaTarea programada en System32\TasksSystem32\Tasks\lssass.exe

0x04 — Lecciones 

1. Process masquerading como vector de evasión

El malware nombra su ejecutable lssass.exe para confundirse con el legítimo lsass.exe

Una verificación rigurosa de nombres de proceso, rutas de ejecución y relaciones padre-hijo es imprescindible en todo análisis forense.

2. Carpetas temporales como zona de despliegue

Los directorios Temp y AppData son los refugios favoritos del malware: permisos de escritura para usuarios estándar, baja visibilidad y frecuente exclusión de los escaneos antivirus. La monitorización activa de estas rutas es una medida defensiva básica.

3. HTTP como canal C2 encubierto

El uso del puerto 80 para comunicaciones C2 busca camuflarse entre el tráfico web legítimo. 

La inspección profunda de paquetes (DPI) y la detección de tráfico anómalo son contramedidas esenciales que todo SOC debería implementar.

4. Arquitectura modular y LOLBins

Amadey descarga sus capacidades como plugins DLL y las ejecuta mediante rundll32.exe, un binario legítimo de Windows. 

Esta combinación de modularidad y Living off the Land dificulta enormemente la detección basada en firmas.

5. Persistencia vía Task Scheduler

El registro como tarea programada garantiza la supervivencia del malware tras reinicios. 

Auditar regularmente las tareas programadas y comparar contra una línea base conocida es fundamental para detectar persistencia no autorizada.

6. Volatility3 como herramienta de investigación

Este análisis demuestra la potencia de los plugins de Volatility3 (pstree, cmdline, netscan, memmap, filescan) para reconstruir la cadena completa de un ataque desde un volcado de memoria, sin necesidad de acceder al disco del sistema comprometido.

[EOF] "The Trojan masquerades as the guardian — only memory tells the truth"