Análisis de malware dinámico
El módulo 13 terminó en un límite claro: una muestra empaquetada no revela su comportamiento real con strings ni PEStudio, porque su código de verdad solo existe descomprimido en memoria durante la ejecución. Este módulo cruza esa línea de forma controlada: ejecutar la muestra, pero en un entorno pensado exactamente para que esa ejecución no tenga ninguna consecuencia fuera de él.
- Entender los requisitos mínimos de un sandbox de análisis de malware: aislamiento y reversibilidad.
- Conocer las opciones de sandboxing automatizado (CAPE, any.run) y cuándo usar cada una.
- Monitorizar manualmente la actividad de ficheros, registro y procesos con Process Monitor.
- Simular servicios de red con FakeNet-NG/INetSim para que el malware "hable" sin llegar a Internet real.
- Volcar la memoria tras la ejecución para repetir el análisis de los módulos 8-9 sobre la muestra ya desempaquetada.
Descarga el paquete de evidencia, descomprímelo y lee el LEEME.md antes de empezar. Verifica el hash según el módulo 2 antes de analizar nada:
Hashes de referencia (ver también LEEME.md):
procmon_export.csv→605222be42510ad636b09095400e3f517a14f7bff04f4135d4e70bd07d5cad3dfakenet_log.txt→4d6382119714e128c7b7c4355e3d5f0ab5664d7806ceb5e9f4bc71d6c05c01a0
⬇️ Descargar M14_MalwareDinamico.zip Ver solución paso a paso →
1. Cuándo hace falta cruzar la línea
El análisis dinámico se reserva para cuando el estático no es suficiente: muestras empaquetadas (módulo 13), comportamiento que depende de condiciones de ejecución (una fecha concreta, la presencia de un proceso determinado, una respuesta de red específica), o simplemente para confirmar con observación directa lo que el análisis estático solo permitía sospechar.
2. El sandbox: aislamiento y reversibilidad
Un entorno de análisis dinámico no es simplemente "una máquina virtual cualquiera": tiene dos requisitos que no son negociables.
| Requisito | Por qué |
|---|---|
| Aislamiento de red real | Si el malware tiene capacidad de propagación, exfiltración o de avisar a su operador, dejarlo salir a Internet real durante el análisis puede causar daño activo o alertar al atacante. |
| Reversibilidad total | Snapshot limpio antes de cada ejecución: una muestra puede instalar persistencia, cifrar ficheros o dañar el sistema de forma irreversible, y el entorno tiene que volver a su estado inicial en segundos, no reinstalarse desde cero. |
3. Sandboxing automatizado: CAPE y any.run
| Herramienta | Enfoque |
|---|---|
| CAPE (sucesor de Cuckoo Sandbox) | Ejecuta la muestra en una VM desechable, captura automáticamente ficheros creados, cambios de registro, tráfico de red y una memoria final, y genera un informe de comportamiento sin intervención manual. |
| any.run | Sandbox interactivo online: permite observar la ejecución en tiempo real e interactuar con el sistema (clicar un diálogo que el malware espera, por ejemplo), útil cuando el comportamiento depende de una acción del usuario. |
4. Monitorización manual: Process Monitor
Process Monitor (ProcMon, de Sysinternals) registra en tiempo real toda actividad de ficheros, registro y procesos del sistema, con capacidad de filtrar por el proceso concreto que se está analizando:
$ # Filtro en ProcMon: Process Name is mimikatz.exe
12:03:14.221 mimikatz.exe RegOpenKey HKLM\SYSTEM\CurrentControlSet\Control\Lsa SUCCESS
12:03:14.335 mimikatz.exe ReadFile C:\Windows\System32\lsass.exe SUCCESS
12:03:14.410 mimikatz.exe WriteFile C:\Users\Public\creds_dump.txt SUCCESS
12:03:14.502 mimikatz.exe TCP Connect 203.0.113.44:4444 SUCCESSEsta secuencia confirma en vivo, acción por acción, exactamente lo que el análisis estático solo permitía intuir por los imports (sekurlsa::logonpasswords leyendo lsass.exe), y añade algo que el estático no podía ver: el fichero de salida concreto (creds_dump.txt) y la reconexión al mismo C2 ya identificado en el módulo 12.
5. Simular red sin salir a Internet: FakeNet-NG e INetSim
Dejar que el malware se conecte a su C2 real durante el análisis puede revelar la investigación al atacante (que puede ver su propia infraestructura recibiendo conexiones nuevas) o simplemente fallar si el C2 ya no está activo. FakeNet-NG e INetSim resuelven esto: simulan servicios de red habituales (HTTP, DNS, FTP) dentro del propio entorno aislado, de forma que el malware "cree" que está hablando con Internet real y revele su comportamiento de red sin que ningún paquete salga de verdad del sandbox.
$ fakenet.exe
FakeNet-NG listening...
[HTTP] GET /stage3.ps1 from mimikatz.exe -> respondiendo con payload simulado
[DNS] update-service.ddns-provider.net -> resuelto a 127.0.0.1 (sandbox)6. Qué observar en conjunto
- Ficheros creados o modificados: ¿dónde escribe, con qué nombre, qué contenido?
- Cambios de registro: ¿crea persistencia (módulo 5-6)? ¿en qué clave exacta?
- Procesos lanzados o inyectados: ¿crea procesos hijos? ¿se inyecta en uno existente, como ya se vio con
lsass.exeen el módulo 9? - Tráfico de red generado: ¿a qué dominios o IPs intenta conectar, con qué protocolo?
7. Cerrando el círculo: volcar memoria tras la ejecución
Con la muestra ya ejecutada y desempaquetada en memoria dentro del sandbox, el último paso es exactamente el procedimiento del módulo 8: volcar la memoria del proceso en ejecución y repetir sobre ella malfind, pslist/psscan y la extracción de strings del módulo 13 — ahora sobre el código real, ya sin la capa de empaquetado que lo ocultaba en el fichero original.
Autoevaluación
- ¿Qué dos requisitos no son negociables en un sandbox de análisis de malware, y por qué ninguno de los dos es opcional?
- ¿Qué diferencia hay entre CAPE y any.run, y cuándo elegirías el segundo sobre el primero?
- ¿Para qué sirve FakeNet-NG/INetSim, y qué problema evita exactamente frente a dejar que el malware se conecte a Internet real?
- En el ejemplo de ProcMon de este capítulo, ¿qué acción confirma algo que el análisis estático del módulo 13 no podía ver por sí solo?
- ¿Por qué volcar la memoria después de ejecutar una muestra empaquetada tiene sentido aunque ya se haya hecho un volcado de memoria en el módulo 8?