Parte: 6 — Análisis de malware · Fuente: Practical Malware Analysis (Sikorski & Honig) ⏱️ Duración estimada: 130 min · Nivel: Avanzado
Vencer las defensas que el malware usa contra el análisis. El alumno aprenderá a reconocer ofuscación, packing y anti-análisis; a identificar el packer; y a desempacar la muestra (automática y manualmente) para hacer un dump del código real desde memoria, reconstruir la IAT y continuar el análisis.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | Ofuscación vs packing vs virtualización | Enfoques de análisis distintos |
| 2 | Identificación de packers | Define la estrategia de unpacking |
| 3 | Unpacking automático (UPX y otros) | Vía rápida cuando el packer es conocido |
| 4 | OEP (Original Entry Point) | Punto donde termina el stub |
| 5 | Dump de memoria | Extrae el código desempacado |
| 6 | Reconstrucción de IAT | Necesaria para un dump analizable |
| 7 | Anti-debug / anti-VM | Impiden la depuración |
La inmensa mayoría del malware real llega empaquetado (packed): su código real está comprimido o cifrado, y el fichero solo contiene un pequeño desempaquetador (stub) que, al ejecutarse, reconstruye el código en memoria y salta a él (Clase 135). El packing sirve dos propósitos al atacante: evadir la detección por firmas (el antivirus no ve el código malicioso, solo el stub) y dificultar el análisis estático. La consecuencia para el analista es que hasta que no se desempaqueta, el análisis estático ve poco o nada —strings cifradas, IAT mínima, una sola sección de entropía alta—. Desempaquetar (unpacking) es, por tanto, un paso previo obligatorio para la mayoría del análisis de código, y esta clase enseña a hacerlo.
Conviene distinguir tres grados. La ofuscación transforma el código para hacerlo ilegible pero lo mantiene como código (cadenas cifradas, control-flow flattening, nombres sin sentido). El packing va más allá: comprime o cifra el binario entero y lo reconstruye en ejecución —el código real no existe en el fichero, solo aparece en memoria—. La virtualización es el extremo: traduce el código a un bytecode propio que solo un intérprete embebido entiende, la protección más costosa de vencer. La mayoría del malware usa packing; la ofuscación es habitual sobre el código ya desempaquetado; la virtualización se reserva para amenazas avanzadas.
El primer paso es identificar el packer, con herramientas como DIE (Detect It Easy) o PEiD, que
reconocen firmas de packers conocidos. Si es un packer estándar y bien documentado —el ejemplo canónico
es UPX—, el unpacking es trivial: upx -d muestra.exe lo revierte, porque UPX es un compresor
legítimo con desempaquetador oficial. Pero el malware serio usa packers personalizados (a veces
UPX modificado a propósito para que el -d no funcione) o packers comerciales complejos, y ahí hace
falta el unpacking manual o dinámico.
El unpacking genérico se apoya en una idea universal: el malware, para ejecutarse, tiene que
desempaquetarse a sí mismo en memoria, así que si se le deja hacerlo bajo observación y luego se
captura la memoria, se obtiene el código real. El flujo tiene tres pasos clave. Primero, localizar
el OEP (Original Entry Point): el punto donde el stub termina de desempaquetar y salta al código
original —se encuentra ejecutando bajo un depurador (x64dbg) y buscando ese salto característico, o
poniendo un breakpoint en la transición de una sección a otra—. Segundo, el dump de memoria: una vez
que la ejecución está en el OEP con el código ya desempaquetado en memoria, se vuelca ese proceso a
un nuevo fichero. Tercero, y a menudo el más delicado, reconstruir la IAT: el binario volcado tiene
las direcciones de las APIs resueltas en memoria pero le falta una tabla de imports válida, así que hay
que reconstruirla con herramientas como Scylla o ImpREC, que analizan las llamadas y regeneran la
Import Directory. El resultado es un binario desempaquetado y analizable estáticamente. Todo esto se
complica con las defensas anti-debug y anti-VM (clase 135) que el packer añade —comprobaciones de
IsDebuggerPresent, de timing, de dispositivos de VM— que hay que parchear o evadir para que la muestra
llegue a desempaquetarse. La clase 158 muestra cómo automatizar el unpacking con emulación, pero
entender el proceso manual —OEP, dump, IAT— es lo que permite abordar los casos que ninguna herramienta
automática resuelve, que son precisamente los del malware que más importa analizar.
IsDebuggerPresent, timing). Característica clave: frena el análisis dinámico.| Término | Definición concisa |
|---|---|
| Packing | Comprimir/cifrar el binario; un stub lo reconstruye |
| Stub | Desempaquetador que revela el código en ejecución |
| Ofuscación | Hacer el código ilegible manteniéndolo como código |
| Virtualización | Traducir a bytecode propio con intérprete |
| Unpacking | Recuperar el código real del malware empaquetado |
| DIE / PEiD | Herramientas que identifican el packer |
| UPX | Packer estándar; se revierte con upx -d |
| Packer personalizado | Requiere unpacking manual o dinámico |
| OEP | Original Entry Point; donde el stub salta al código real |
| Dump de memoria | Volcar el código ya desempaquetado |
| Reconstrucción de IAT | Regenerar la tabla de imports del binario volcado |
| Scylla / ImpREC | Herramientas de reconstrucción de la IAT |
| x64dbg | Depurador usado para el unpacking manual |
| Anti-debug / anti-VM | Defensas del packer que hay que evadir |
upx -d) para packers conocidos.⚠️ Nota ética y de seguridad: el unpacking implica ejecutar el stub del malware bajo depurador. Hazlo solo en la VM aislada, con snapshot previo y sin red. Aunque paras en el OEP, el proceso ya se ejecuta parcialmente: restaura
base-cleanal terminar.
Caso A — packer conocido (UPX):
upx -d muestra.exe -o muestra_unpacked.exe.Caso B — unpacking manual genérico:
VirtualAlloc, VirtualProtect) para atrapar la escritura del código desempacado.jmp/call a la región recién escrita). Detente ahí.base-clean.Desempaca una muestra empaquetada y entrega el dump reparado con su IAT reconstruida, más un informe con el OEP, el método y evidencia de que el código ya es legible (strings/imports visibles). Criterio de aceptación: el dump abre en Ghidra mostrando imports resueltos y strings que no eran visibles en el binario original, y el informe indica el OEP con su dirección.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| El proceso se cierra al depurar | Anti-debug activo; usa ScyllaHide y evita detección |
| Dump no ejecuta / IAT rota | Falta reparar imports; usa Scylla IAT Autosearch + Fix |
| No encuentro el OEP | Usa breakpoints en VirtualProtect/tension entre secciones |
upx -d falla |
UPX modificado a mano; desempaca manualmente |
| Dump sin strings | Detuviste antes del OEP; avanza hasta que se descifre todo |
❓ ¿Todo malware está empaquetado? No todo, pero es muy común para evadir AV y análisis. La alta entropía y la IAT mínima son las primeras señales.
❓ ¿Puedo evitar ejecutar para desempacar? Para packers simples sí (estático/emulación). Para packers reales suele hacer falta ejecutar el stub bajo control; por eso el aislamiento es crítico.
❓ ¿Qué hago con Themida/VMProtect? Son protecciones de virtualización; el unpacking clásico no basta. Se recurre a emulación, dumping parcial y análisis de comportamiento.
Clase 146 — Análisis con IDA y Ghidra aplicado a malware