Malware dinámico: sandbox, API hooking, debugging y anti-analysis

El análisis dinámico de malware consiste en ejecutar una muestra sospechosa en un entorno aislado y observar qué hace: qué procesos crea, qué archivos escribe, a qué servidores se conecta, qué claves de registro modifica. A diferencia del análisis estático — que examina el binario sin ejecutarlo —, el dinámico revela el comportamiento real del código, incluido el que permanece cifrado u ofuscado hasta el momento de la ejecución.

En un SOC moderno, el análisis dinámico es la pieza que conecta una alerta con un veredicto accionable. Un hash desconocido llega al equipo: ¿es malicioso o benigno? La sandbox lo ejecuta, el analista revisa el reporte de comportamiento, extrae IOCs y alimenta las detecciones del SIEM. Es la novena lección de la Tanda 8.

El análisis de malware es disciplina puramente defensiva. Todo lo que se describe aquí se practica en entornos aislados propios, nunca en sistemas de terceros ni en producción. El objetivo es entender al adversario para proteger mejor la infraestructura.

Análisis estático vs dinámico#

Antes de ejecutar nada, un analista suele hacer un primer pase estático: revisar strings, imports, headers PE, entropía de secciones, y buscar matches de YARA. Pero el análisis estático tiene un límite duro: si el malware está empacado, cifrado o polimórfico, el contenido real permanece oculto hasta que se ejecuta.

El análisis dinámico resuelve esa limitación: deja que el código se desempaque solo, se descifre en memoria, y ejecute sus funciones reales mientras el entorno graba cada acción. Ambos enfoques son complementarios, no excluyentes.

Entornos sandbox#

Una sandbox es una máquina virtual instrumentada que ejecuta la muestra y registra cada interacción con el sistema operativo. Las más usadas en la industria:

• CAPE Sandbox (fork de Cuckoo): open-source, soporta Windows y Linux, extracción automática de configs de malware (Cobalt Strike, Emotet, etc.), integración con YARA y Suricata.
• Any.Run: sandbox interactiva en la nube. El analista puede mover el ratón, hacer clics, abrir archivos — lo cual activa malware que requiere interacción humana.
• Joe Sandbox: análisis profundo con detección de evasión, análisis de tráfico TLS, y reports ejecutivos para equipos de respuesta a incidentes.
• Hybrid Analysis (de CrowdStrike): sandbox gratuita en la nube con comunidad de analistas que comparten reportes.

Montando un lab de análisis aislado#

Para análisis en tu equipo, el setup mínimo es:

Host (Linux/Windows)
├── VM de análisis (Windows 10, snapshots)
│   ├── Herramientas: x64dbg, Process Monitor, Wireshark
│   ├── FakeDNS / INetSim (responde todo)
│   └── Snapshot limpio restaurable
├── VM de red (INetSim + tcpdump)
│   └── Captura todo el tráfico de la VM de análisis
└── Host-only network (sin acceso a Internet real)

La regla cardinal: la VM de análisis nunca toca Internet real. INetSim simula DNS, HTTP, SMTP y otros servicios para que el malware crea que tiene conectividad. Todo el tráfico queda capturado para análisis posterior.

Después de cada ejecución, se restaura el snapshot. Así cada análisis parte de un estado limpio idéntico.

API hooking: la instrumentación de la sandbox#

El mecanismo central de una sandbox es el API hooking: interceptar las llamadas que el malware hace al sistema operativo para registrarlas antes de que se ejecuten. Cuando el malware llama a CreateFileW para escribir un archivo, el hook lo intercepta, graba los argumentos (ruta, flags, contenido), y luego deja que la llamada continúe.

Técnicas de hooking que usan las sandboxes:

CAPE y Cuckoo usan principalmente inline hooking en user mode combinado con un driver kernel para capturar lo que ocurre debajo. Las funciones más monitoreadas:

Procesos:    CreateProcessW, NtCreateProcess, ShellExecuteW
Archivos:    CreateFileW, WriteFile, DeleteFileW, MoveFileW
Registro:    RegSetValueExW, RegCreateKeyExW, RegDeleteKeyW
Red:         connect, send, recv, InternetOpenUrlW, HttpSendRequestW
Memoria:     VirtualAllocEx, WriteProcessMemory, NtMapViewOfSection
Crypto:      CryptEncrypt, CryptDecrypt, BCryptEncrypt

El reporte resultante es un JSON con cada API call, sus argumentos, el proceso que la hizo y el timestamp. Un analista experimentado lee ese log y reconstruye exactamente qué hizo el malware, en qué orden, y con qué propósito.

Indicadores de comportamiento#

Lo que el analista busca en el reporte de sandbox:

Creación de procesos#

El malware lanza procesos hijo para ejecutar comandos, inyectar código, o escalar privilegios. Una cadena winword.exe → cmd.exe → powershell.exe → payload.exe es altamente sospechosa: un documento de Word no debería lanzar PowerShell.

Persistencia#

Claves de registro como HKCU\Software\Microsoft\Windows\CurrentVersion\Run, scheduled tasks creadas con schtasks.exe, o servicios instalados con sc.exe. Cualquiera indica que el malware quiere sobrevivir al reinicio.

Comunicación de red#

DNS queries a dominios de aspecto aleatorio (DGA), HTTP POST con datos codificados en base64, beaconing regular cada N segundos al mismo servidor. INetSim captura todo esto sin que el malware contacte al C2 real.

Inyección de memoria#

VirtualAllocEx + WriteProcessMemory + CreateRemoteThread en otro proceso es la secuencia clásica de process injection. El malware escribe su código en la memoria de un proceso legítimo (como explorer.exe o svchost.exe) para ocultarse.

Debugging de malware#

Cuando la sandbox no es suficiente — el malware no se activa, o necesitas entender una función específica —, se recurre al debugging manual.

x64dbg#

Debugger open-source para Windows, sucesor de OllyDbg. Uso típico en análisis de malware:

1. Cargar el sample en x64dbg (archivo → abrir)
2. Poner breakpoint en VirtualAlloc (bp VirtualAlloc)
3. Ejecutar (F9) hasta que el malware desempaque
4. En el retorno de VirtualAlloc, inspeccionar el buffer
5. Dump de la memoria desempacada a disco
6. Analizar el payload real con herramientas estáticas

Breakpoints estratégicos para malware analysis:

VirtualAlloc / VirtualAllocEx    → desempacado, shellcode allocation
CreateProcessW                   → lanzamiento de procesos hijo
WriteProcessMemory               → inyección en otro proceso
InternetConnectW / HttpOpenRequestW → comunicación C2
CryptDecrypt / BCryptDecrypt     → descifrado de config o payload
IsDebuggerPresent                → detección de debugger

WinDbg#

Debugger de Microsoft, indispensable para análisis kernel-level. Se usa cuando el malware opera como driver o rootkit. Requiere kernel debugging habilitado en la VM de análisis, con la VM host conectada vía pipe o red.

Técnicas anti-analysis#

El malware moderno intenta detectar si está siendo analizado y, si lo está, se comporta de forma benigna o simplemente no ejecuta su payload. Entender estas técnicas es necesario para saber por qué una muestra puede parecer inofensiva en sandbox pero ser destructiva en un endpoint real.

Detección de máquina virtual#

El malware comprueba indicadores de virtualización: drivers de VirtualBox o VMware en el registro, direcciones MAC con OUI de hipervisor conocido, instrucciones CPUID que revelan la presencia de un hipervisor, o archivos como C:\Windows\System32\VBoxService.exe. Si encuentra cualquiera, asume que está en sandbox y no ejecuta el payload real.

Timing checks#

El malware mide el tiempo entre dos instrucciones con RDTSC o GetTickCount. En una sandbox con aceleración de Sleep, el intervalo medido es inconsistente con hardware real. También puede hacer un Sleep(300000) — cinco minutos — esperando que la sandbox se aburra y corte el análisis antes de que el payload se active.

Detección de interacción humana#

Ciertas muestras no se activan hasta que detectan movimiento del ratón, clics, o escritura de teclado. Una sandbox automatizada que no simula interacción de usuario nunca activa el payload.

Verificación de entorno#

Comprobar si hay documentos recientes, historial del navegador, programas instalados, resolución de pantalla típica de usuario, o si la RAM es inferior a 4 GB. Una VM de sandbox recién instalada con el escritorio vacío es obvia.

Contramedidas del analista#

Para cada técnica anti-analysis hay una respuesta:

CAPE Sandbox incluye varias de estas contramedidas de serie, y permite configurar cuáles activar según la muestra.

De la sandbox al SIEM: extracción de IOCs#

El valor del análisis dinámico no termina en el reporte. Los IOCs extraídos deben llegar al SIEM, al EDR y a las blocklists para proteger al resto de la organización.

Flujo típico:

Sandbox report (JSON)
  → Extraer: hashes, IPs, dominios, URLs, mutex, registry keys
  → Normalizar a formato STIX 2.1
  → Publicar en plataforma de threat intel (MISP, OpenCTI)
  → SIEM consume el feed y crea alertas
  → EDR bloquea los hashes y IPs en todos los endpoints

Regla YARA desde análisis dinámico#

Si la sandbox extrae el payload desempacado, el analista puede escribir una regla YARA contra el contenido real (no el empacado). El siguiente ejemplo es didáctico — muestra la estructura, no es producción:

rule Extracted_Payload_Beacon {
    meta:
        description = "Payload extraído por CAPE, beacon HTTP config"
        author = "SOC interno"
    strings:
        $ua = "Mozilla/5.0" ascii
        $cfg = { 00 02 00 01 00 02 }
        $pipe = "\\\\.\\pipe\\msagent_" ascii
    condition:
        2 of them
}

Esta regla se alimenta al EDR y a la sandbox misma para clasificar automáticamente futuras muestras de la misma familia.

Ejemplo práctico: análisis en CAPE#

Un analista recibe una alerta: un usuario descargó un ejecutable que el antivirus no detectó. Pasos de análisis dinámico:

Paso 1: triage estático rápido#

sha256sum suspicious.exe
file suspicious.exe
strings suspicious.exe | grep -i "http\|cmd\|powershell\|reg"

El hash no aparece en VirusTotal. Las strings revelan poca información — probablemente empacado. Se requiere análisis dinámico.

Paso 2: envío a CAPE#

# Enviar muestra a CAPE vía API (IP_DEL_LAB es la sandbox interna)
curl -F "[email protected]" http://IP_DEL_LAB:8000/apiv2/tasks/create/file/

CAPE asigna un task ID y ejecuta la muestra en la VM Windows durante 120 segundos con instrumentación completa.

Paso 3: revisión del reporte#

El reporte muestra:

• El sample se desempaca en memoria y lanza un segundo proceso.
• Crea una clave en HKCU\Software\Microsoft\Windows\CurrentVersion\Run para persistencia.
• Resuelve un dominio DGA y hace HTTP POST cada 60 segundos con datos codificados.
• Intenta leer HKLM\SOFTWARE\VMware, Inc. — técnica anti-VM que CAPE esquivó con su golden image.

Paso 4: extraer IOCs y proteger#

Hash SHA256: a1b2c3...   → Blocklist en EDR
Dominio C2: xk4m9.example  → Bloqueo en proxy y DNS sinkhole
Registry key: HKCU\...\Run\svcagent  → Regla Sigma de persistencia
Mutex: Global\SvcMutex8829  → Indicador de familia

Cada IOC se publica en MISP en formato STIX y llega automáticamente al SIEM.

Errores comunes en análisis dinámico#

• Ejecutar sin aislamiento: la muestra contacta al C2 real y el adversario sabe que lo están analizando. O infecta la red del analista.
• No restaurar snapshots: el entorno acumula artefactos de ejecuciones anteriores que contaminan el análisis.
• Confiar solo en la sandbox: si la muestra tiene anti-analysis efectivo, la sandbox no verá el payload real. Combinar con debugging manual.
• Ignorar el contexto de red: los DNS queries y patrones de beaconing son tan valiosos como las acciones en el filesystem.
• No compartir IOCs: un analista que extrae IOCs y no los distribuye al SIEM protege solo a sí mismo, no a la organización.
• Analizar en tu máquina host: grave error de principiante. Siempre VM aislada, siempre snapshot, siempre red host-only.

Preguntas frecuentes#

¿Puedo hacer análisis dinámico sin sandbox dedicada?#

Sí, con un setup mínimo: una VM Windows en VirtualBox con snapshot, INetSim en otra VM Linux para simular servicios de red, y herramientas gratuitas como Process Monitor, Wireshark y x64dbg. No es tan automatizado como CAPE, pero es funcional para aprender.

¿Cuánto tiempo debe ejecutarse la muestra?#

La mayoría del comportamiento relevante ocurre en los primeros 2-3 minutos. Pero malware con sleep largo o que espera condiciones específicas puede requerir 10 minutos o más. CAPE permite configurar el timeout por análisis.

¿Qué hago si la muestra detecta la sandbox?#

Primero, intentar con la golden image más realista disponible. Si persiste, pasar a debugging manual con x64dbg y plugins anti-anti-debug como ScyllaHide. En último caso, análisis en bare-metal con reset por PXE.

¿Es legal analizar malware?#

Analizar malware en tu propia infraestructura con fines defensivos es legal en la mayoría de jurisdicciones. Lo que no es legal es distribuir malware, usarlo contra terceros, o publicar herramientas de ataque sin contexto defensivo. Consulta la legislación de tu país para los detalles.

¿Dónde consigo muestras para practicar?#

Repositorios dedicados como MalwareBazaar (abuse.ch), VirusTotal (con cuenta), y theZoo (GitHub, con advertencias claras). Nunca descargues muestras en tu equipo host — siempre directamente en la VM de análisis aislada.

Resumen#

• Análisis dinámico ejecuta el malware en sandbox aislada para observar comportamiento real, complementando el análisis estático.
• API hooking intercepta llamadas al sistema operativo y genera un log detallado de cada acción del malware.
• CAPE, Any.Run, Joe Sandbox son las herramientas principales; un lab casero con VMs y INetSim también funciona.
• Anti-analysis intenta detectar el entorno de análisis; el analista responde con golden images, timing patches y simulación de usuario.
• IOCs extraídos deben llegar al SIEM, EDR y blocklists vía STIX/MISP para proteger toda la organización.
• Debugging manual con x64dbg resuelve los casos donde la sandbox no es suficiente.
• Aislamiento estricto es obligatorio: VM con snapshot, red host-only, sin acceso a Internet real.

Fuentes y lecturas recomendadas#

• CAPE Sandbox
• Any.Run Interactive Sandbox
• MalwareBazaar
• MITRE ATT&CK T1497 Virtualization/Sandbox Evasion
• MITRE ATT&CK T1055 Process Injection
• x64dbg Debugger
• INetSim
• Practical Malware Analysis — Sikorski & Honig (No Starch Press)