Ingeniería inversa: análisis de malware forense

Ingeniería inversa

El fabricante Fidelis Security cifró en 6,7 millones las amenazas de malware de alta severidad detectadas por sus propios sensores entre enero y octubre de 2025, junto a 16.000 intentos de explotación de vulnerabilidades críticas. Es telemetría de un proveedor, no una medición del parque global —cada fabricante ve lo que pasa por sus clientes—, pero sirve para el orden de magnitud. Detrás de cada una de estas amenazas hay un binario que debe ser analizado para comprender su comportamiento, determinar su impacto y generar defensas. La ingeniería inversa es la disciplina que permite desmontar estos binarios pieza a pieza, y es de las competencias más escasas del análisis forense: exige leer ensamblador, reconocer patrones de compilador y sostener el resultado ante un tribunal. La formación de referencia internacional es el curso SANS FOR610 y su certificación GREM.

Definición técnica

La ingeniería inversa (reverse engineering) en el contexto de ciberseguridad es el proceso de analizar software compilado (binarios ejecutables) para reconstruir su lógica, funcionalidad y comportamiento sin acceso al código fuente original. Se aplica tanto a software legítimo como a malware, y constituye una de las competencias técnicas más avanzadas del análisis forense digital.

Niveles de análisis:

Nivel	Técnica	Herramienta	Información obtenida
Nivel 1: Triaje	Análisis estático básico	strings, file, PEiD	Tipo de archivo, cadenas de texto, empaquetadores
Nivel 2: Estático avanzado	Desensamblado	IDA Pro, Ghidra	Flujo de ejecución, llamadas a API, lógica del programa
Nivel 3: Dinámico	Ejecución controlada	x64dbg	Comportamiento real, descifrado en runtime, C2
Nivel 4: Avanzado	Desempaquetado + deofuscación	Custom scripts	Payload real oculto bajo capas de protección

Análisis estático vs dinámico:

┌────────────────────────┬────────────────────────┐
│   Análisis Estático    │   Análisis Dinámico    │
├────────────────────────┼────────────────────────┤
│ Sin ejecutar el código │ Ejecutando el código   │
│ Desensamblado          │ Debugging en tiempo real│
│ Seguro (sin riesgo)    │ Requiere sandbox       │
│ Ve todo el código      │ Solo ve código ejecutado│
│ Lento, minucioso       │ Más rápido, práctico   │
│ Bloqueado por ofusc.   │ Descifra en runtime    │
│ IDA, Ghidra, Cutter    │ x64dbg, WinDbg, strace │
└────────────────────────┴────────────────────────┘

Ghidra: la alternativa open-source a IDA Pro

Ghidra es una herramienta de ingeniería inversa desarrollada por la NSA y publicada como código abierto en 2019. Ofrece desensamblado y descompilación comparables a los de IDA Pro —que es software comercial de pago, con las tarifas que publica Hex-Rays—, incluyendo soporte para múltiples arquitecturas (x86, ARM, MIPS) y un descompilador que genera pseudocódigo C legible.

Para un peritaje tiene además una ventaja que no es de precio: es reproducible sin coste por cualquier tercero. Si la contraparte quiere rehacer el análisis, puede descargar la misma herramienta y llegar al mismo punto, que es justo lo que un tribunal necesita poder asumir.

Herramientas esenciales de ingeniería inversa

Herramientas de análisis estático:

Herramienta	Tipo	Uso forense	Coste
Ghidra	Desensamblador + descompilador	Análisis completo de binarios, gratuito	Gratis (NSA)
IDA Pro	Desensamblador profesional	Estándar de la industria, soporte comercial	Comercial (Hex-Rays)
Binary Ninja	Desensamblador moderno	Interfaz intuitiva, API de scripting	Comercial
Cutter	GUI para radare2	Alternativa open-source a IDA	Gratis
PE Studio	Análisis PE	Triaje rápido de ejecutables Windows	Gratis (básico)
DIE (Detect It Easy)	Detector de empaquetadores	Identificar protecciones del binario	Gratis

Herramientas de análisis dinámico:

Herramienta	Tipo	Uso forense	Plataforma
x64dbg	Debugger	Debugging de malware Windows	Windows
WinDbg	Debugger kernel	Análisis de rootkits, drivers	Windows
GDB	Debugger	Debugging en Linux	Linux
Frida	Instrumentación dinámica	Hooking de funciones en runtime	Multiplataforma
Procmon	Monitor de actividad	Registro de operaciones del sistema	Windows
API Monitor	Monitor de API	Interceptar llamadas a API de Windows	Windows

Flujo de trabajo de ingeniería inversa forense

Triaje y clasificación inicial
Antes de invertir horas en análisis profundo, determinar el tipo de archivo, su hash SHA-256 (para verificar si ya está catalogado en VirusTotal/MalwareBazaar), cadenas de texto visibles, importaciones de API sospechosas, y si está empaquetado u ofuscado.
```
# Comandos básicos de triaje
file sample.exe
sha256sum sample.exe
strings -a sample.exe | grep -i "http\|password\|key\|decrypt"
```
Análisis estático con desensamblador
Cargar el binario en Ghidra o IDA Pro. Analizar el punto de entrada (entry point), el flujo de ejecución principal, las llamadas a funciones de red (connect, send, recv), las operaciones de cifrado, y las cadenas descifradas en memoria.
Análisis dinámico en sandbox
Ejecutar el binario en un entorno aislado (sandbox) mientras se monitorizan: conexiones de red, archivos creados/modificados, claves de registro modificadas, procesos creados, y comportamiento de persistencia. Herramientas: sandbox dedicada con x64dbg, Procmon, y Wireshark en paralelo.
Extracción de indicadores de compromiso (IOCs)
Documentar todos los IOCs encontrados: direcciones IP y dominios C2, URLs de descarga de payloads, nombres de archivos y rutas, claves de registro, mutexes, y hashes de componentes adicionales.
Documentación y informe
Elaborar informe forense que incluya: clasificación del malware, funcionalidades identificadas, vector de infección, mecanismo de persistencia, capacidades de exfiltración, IOCs completos, y el impacto estimado en el sistema afectado.

Entorno aislado obligatorio

NUNCA ejecutar malware fuera de un entorno de análisis aislado (sandbox). Utilizar máquinas virtuales dedicadas, sin acceso a la red corporativa, con snapshots para restauración inmediata. El malware puede detectar entornos de análisis y comportarse de forma diferente.

Caso práctico: análisis de malware en incidente de espionaje industrial

Escenario ilustrativo

El recorrido de esta sección es un escenario construido sobre una tipología real de la práctica pericial: explica cómo se encadena un análisis de malware de principio a fin, no relata un expediente concreto. El perfil de empresa, los nombres de fichero, los plazos y los desenlaces no corresponden a un procedimiento identificable.

Contexto: una empresa farmacéutica descubre que datos de I+D están siendo filtrados a un competidor. El análisis de red detectó comunicaciones cifradas sospechosas desde un servidor de desarrollo. Se contrató peritaje forense para analizar el malware encontrado.

Análisis de ingeniería inversa:

Extracción: Se localizó un ejecutable sospechoso (svcupdate.exe, 340 KB) en la carpeta C:\Windows\Temp\ del servidor afectado. Hash SHA-256 documentado y verificado en VirusTotal: 0 detecciones
Triaje estático: El binario estaba empaquetado con UPX modificado. Tras desempaquetarlo, se identificaron cadenas cifradas con XOR, importaciones de funciones de red (WinHTTP) y criptografía (CryptEncrypt)
Análisis en Ghidra: El descompilador reveló tres funcionalidades principales:
- Keylogger: Captura de pulsaciones de teclado usando SetWindowsHookEx
- Screen capture: Capturas de pantalla cada 30 segundos con BitBlt
- Exfiltración: Envío cifrado (AES-256) a un servidor C2 mediante HTTPS POST a un dominio que simulaba ser un servicio de actualizaciones de Microsoft
Análisis dinámico: En sandbox, se confirmó que el malware enviaba capturas de pantalla y registros de teclado cada 5 minutos. La clave AES estaba hardcoded en el binario
Clasificación de técnicas: las funcionalidades observadas se mapean sobre MITRE ATT&CK — T1056.001 (captura de pulsaciones), T1113 (captura de pantalla) y T1071.001 (protocolos web para el mando y control)

Coincidir en técnicas no es atribuir, y confundirlo se desmonta en la primera pregunta

Es el error más tentador al cerrar un análisis de malware: encontrar tres técnicas de ATT&CK y concluir que detrás hay un grupo concreto. No se sostiene, y menos con estas tres — el registro de teclas, la captura de pantalla y el uso de HTTPS para el C2 están entre las más comunes de todo el catálogo, presentes en cientos de familias sin relación entre sí.

Mapear a ATT&CK sirve para describir y comunicar lo que hace un binario en un vocabulario que otros entienden. No sirve para atribuir autoría. La atribución seria exige elementos que rara vez están al alcance de un peritaje de parte —infraestructura, artefactos de compilación, patrones de código reutilizado, inteligencia externa— y aun así se formula en grados de confianza, nunca como hecho.

Un informe que escriba «coincide con el grupo X» a partir de un mapeo de técnicas le entrega a la contraparte una pregunta que no tiene respuesta, y con ella la duda sobre todo lo demás. Lo correcto es describir la funcionalidad y dejar la atribución fuera del dictamen técnico.

Lo que el análisis permite sostener: la funcionalidad completa del binario, la ventana temporal de actividad, el mecanismo de exfiltración y los IOC con los que buscar otros sistemas afectados. Sobre esa base, y no sobre la atribución, se articulan los tipos penales que puedan corresponder —el descubrimiento y revelación de secretos de empresa de los arts. 278 a 280 CP y, en su caso, la competencia desleal—, que es una calificación jurídica y corresponde a quien dirige el procedimiento, no al perito.

Marco legal en España

Ingeniería inversa como actividad legal:

Directiva 2009/24/CE (Protección jurídica de programas de ordenador): Art. 6 permite la descompilación (ingeniería inversa) sin autorización del titular cuando sea necesaria para lograr interoperabilidad, siempre que se cumplan condiciones estrictas
TRLPI (Real Decreto Legislativo 1/1996): el art. 100.5 transpone esa excepción, y conviene leer su alcance real
Ley de Secretos Empresariales 1/2019: art. 3.1.b — la observación, estudio, desmontaje o ensayo de un producto obtenido lícitamente no constituye violación de secreto empresarial

No existe una excepción general de «investigación en seguridad» en la ley de propiedad intelectual

Es la confusión más extendida sobre este tema. El art. 100.5 TRLPI no autoriza la ingeniería inversa en general: solo cuando la reproducción del código «sea indispensable para obtener la información necesaria para la interoperabilidad de un programa creado de forma independiente», y con tres condiciones acumulativas. El art. 100.6.a) cierra el círculo: la información obtenida «se utilice únicamente para conseguir la interoperabilidad».

Es decir: la excepción de interoperabilidad no ampara el análisis de seguridad ni el forense. Lo que sí sostiene el trabajo del perito es otra cosa, y hay que saber cuál en cada caso:

Analizando malware la cuestión es en gran medida teórica: no hay un titular legítimo de derechos que reclame sobre un binario diseñado para delinquir, y el perito actúa sobre material incorporado a una investigación.
Analizando software comercial —una aplicación bancaria, un sistema de fichaje— la cobertura viene de la Ley 1/2019 art. 3.1.b cuando el producto se obtuvo lícitamente, del encargo judicial cuando lo hay, y del propio objeto del procedimiento. No de la excepción de interoperabilidad, que no aplica.

La diferencia importa porque un dictamen que invoca el artículo equivocado le regala a la contraparte una objeción sobre la licitud misma del análisis.

Código Penal (delitos investigados mediante RE):

Art. 197 bis CP: Acceso no autorizado a sistemas informáticos mediante malware analizado por ingeniería inversa
Art. 264 CP: Daños informáticos causados por malware cuya funcionalidad se determina mediante ingeniería inversa
Art. 270 CP: Delitos contra la propiedad intelectual si el malware incluye componentes de software robado
Art. 278-280 CP: Espionaje industrial cuando el malware está diseñado para exfiltrar secretos comerciales

Pericial forense:

Los resultados de ingeniería inversa son admisibles como prueba pericial en tribunales españoles cuando el perito documenta la metodología, las herramientas utilizadas, y la cadena de custodia del binario analizado
El perito debe poder explicar sus hallazgos de forma comprensible para el tribunal, traduciendo conceptos técnicos a lenguaje accesible

Conceptos relacionados

Análisis de malware - La ingeniería inversa es la técnica central del análisis de malware avanzado
Sandbox (análisis de malware) - Entorno aislado imprescindible para análisis dinámico
YARA Rules - Reglas de detección que se crean a partir de los resultados de la ingeniería inversa
Rootkit - Tipo de malware que requiere ingeniería inversa a nivel de kernel
Zero-day - Las vulnerabilidades zero-day se descubren frecuentemente mediante ingeniería inversa
IOCs (Indicadores de Compromiso) - Los IOCs se extraen durante el proceso de ingeniería inversa

Preguntas frecuentes

¿Es legal hacer ingeniería inversa en España?

Sí, con restricciones, y conviene saber cuál ampara cada caso porque no son intercambiables. La Directiva 2009/24/CE y el art. 100.5 del TRLPI permiten la descompilación solo cuando sea indispensable para lograr la interoperabilidad de un programa creado de forma independiente, y el art. 100.6 obliga a usar esa información únicamente para ese fin: no hay en esa norma una excepción de investigación en seguridad. Lo que sí cubre el estudio de un producto para entender cómo funciona es el art. 3.1.b de la Ley 1/2019 de Secretos Empresariales, cuando se obtuvo lícitamente. Y en el análisis de malware la cuestión es distinta: no hay un titular legítimo de derechos que reclame sobre un binario diseñado para delinquir, y el perito trabaja sobre material incorporado a una investigación. En todos los casos se documenta la procedencia del binario, la metodología y el propósito.

¿Necesito herramientas comerciales caras para hacer ingeniería inversa?

No. Ghidra (NSA, gratuito) ofrece capacidades de desensamblado y descompilación comparables a IDA Pro. Cutter (frontend de radare2, gratuito) proporciona interfaz gráfica. x64dbg (gratuito) es un debugger potente para análisis dinámico. El ecosistema open-source permite realizar análisis forense profesional sin inversión en licencias, aunque IDA Pro sigue siendo el estándar de referencia comercial.

¿Cuánto tiempo lleva analizar un malware por ingeniería inversa?

Depende enormemente de la complejidad. Un triaje básico (hash, strings, comportamiento en sandbox) puede completarse en 1-4 horas. Un análisis estático profundo de un malware de complejidad media requiere 1-3 días. Un análisis completo de malware avanzado con múltiples capas de ofuscación, técnicas anti-análisis y código polimórfico puede requerir 1-3 semanas. El coste pericial se ajusta proporcionalmente.

¿Un perito informático necesita saber ingeniería inversa?

No todos los peritos necesitan dominar la ingeniería inversa, pero es una competencia cada vez más demandada. Los peritos especializados en respuesta a incidentes, análisis de malware y ciberdelitos complejos deben tener al menos capacidades de triaje (Nivel 1-2). Para análisis avanzado, puede ser necesario contar con un analista de malware especializado que complemente el equipo forense.

Técnicas anti-análisis y cómo superarlas

El malware moderno implementa múltiples técnicas para dificultar la ingeniería inversa:

Técnicas de anti-análisis más comunes:

Técnica	Descripción	Contramedida
Empaquetado (packing)	El código está comprimido/cifrado en runtime	Desempaquetadores automáticos (UPX -d), breakpoints en OEP
Ofuscación de código	Código basura, flujo de control alterado	Análisis de patrones, scripts de limpieza
Anti-debugging	Detección de debuggers (IsDebuggerPresent, NtQueryInformationProcess)	Plugins anti-anti-debug (ScyllaHide, TitanHide)
Anti-VM	Detección de máquinas virtuales (CPUID, registry, MAC)	VMs hardened, baremetal analysis
Anti-sandbox	Detección de entornos de análisis automatizados	Sandboxes personalizadas con actividad real
Time bombs	Ejecución solo después de cierta fecha o tiempo de espera	Manipulación del reloj del sistema
String encryption	Cadenas de texto cifradas en el binario	Breakpoints en funciones de descifrado, instrumentación
Polimorfismo	El código muta con cada ejecución	Análisis de la rutina de mutación

Ejemplo de detección de debugger y contramedida:

Código del malware (x86):
─────────────────────────
call IsDebuggerPresent
test eax, eax
jnz  exit_malware     ; Si hay debugger, salir

Contramedida en x64dbg:
───────────────────────
1. Poner breakpoint en IsDebuggerPresent
2. Cuando se active, cambiar EAX a 0 (falsear resultado)
3. Continuar ejecución normal del malware

Entornos de análisis recomendados:

FlareVM (Mandiant): Distribución Windows con todas las herramientas de RE preinstaladas
REMnux (SANS): Distribución Linux para análisis de malware
VirtualBox/VMware con snapshots: Para análisis dinámico seguro
Cualquier bare-metal aislado: Para malware con anti-VM avanzado

Regla de oro: snapshot antes de ejecutar

Siempre tomar un snapshot de la máquina virtual ANTES de ejecutar el malware. Esto permite restaurar el estado limpio inmediatamente y repetir el análisis tantas veces como sea necesario sin riesgo de contaminación.

Formación y certificaciones en ingeniería inversa

Para peritos y profesionales que deseen especializarse:

Certificaciones reconocidas:

GREM (GIAC Reverse Engineering Malware): Certificación de SANS, considerada el estándar de la industria. Asociada al curso FOR610
CREA (Certified Reverse Engineering Analyst): Certificación especializada en ingeniería inversa ofensiva y defensiva
eCRE (eLearnSecurity Certified Reverse Engineer): Certificación práctica con examen basado en laboratorios reales
OSCP (Offensive Security Certified Professional): Aunque centrada en pentesting, incluye componentes significativos de RE

Recursos de formación gratuitos:

Malware Unicorn RE101/RE102: Cursos introductorios y avanzados de RE con ejercicios prácticos
CrackMes.one: Plataforma con ejercicios de ingeniería inversa clasificados por dificultad
Azeria Labs: Tutoriales de RE para arquitectura ARM
OpenSecurityTraining2: Cursos universitarios de RE y análisis de malware publicados gratuitamente

Ingeniería inversa en el contexto judicial español

Admisibilidad como prueba pericial:

La ingeniería inversa de malware es una prueba pericial de alto valor técnico en los tribunales españoles. El perito debe ser capaz de:

Explicar el proceso: Traducir conceptos como “desensamblado”, “inyección de código” o “comunicación C2” a un lenguaje accesible para el juez. El uso de diagramas, capturas de pantalla del desensamblador y tablas comparativas facilita enormemente la comprensión
Demostrar la cadena de custodia del binario: Documentar cómo se obtuvo el malware (extracción forense del sistema afectado), su hash SHA-256, y que el análisis se realizó sobre una copia
Justificar las herramientas por lo que importa, que es la reproducibilidad: lo que sostiene un resultado no es quién desarrolló la herramienta, sino que otro perito pueda repetir el análisis y llegar al mismo punto. Con Ghidra eso es literal —es gratuita y de código abierto, así que la contraparte puede descargarla y rehacerlo—. Apoyarse en el prestigio del fabricante es un argumento débil y reversible; apoyarse en que el resultado es verificable, no
Correlacionar hallazgos con el delito: Conectar las funcionalidades descubiertas (keylogging, exfiltración, cifrado) con los hechos investigados y los tipos penales aplicables

Desafíos en la ratificación:

La principal dificultad al ratificar un informe de ingeniería inversa en sala es la complejidad técnica inherente. El perito informático forense debe preparar una presentación visual clara, con analogías comprensibles —comparar la ingeniería inversa con desmontar un mecanismo para entender cómo funciona— y estar preparado para preguntas del fiscal y de la defensa sobre la fiabilidad del método.

Y para la pregunta que más se repite —«¿cómo sabe usted que ese binario hace lo que dice?»— la respuesta que funciona no es una credencial, sino enseñar el camino: el hash del binario analizado, la herramienta y su versión, y el punto exacto del desensamblado donde se ve la llamada a la API que sostiene la afirmación. Lo que no se pueda enseñar así, no debería estar en las conclusiones.

Un binario dice lo que hace; el informe tiene que poder demostrarlo

Mapear técnicas a MITRE ATT&CK describe el comportamiento, no atribuye autoría, y confundirlo desmonta el dictamen. Análisis de malware con hash del binario, herramientas versionadas y hallazgos trazables hasta el desensamblado.

Ver el servicio de informes periciales

Referencias y fuentes

Fidelis Security — telemetría propia de enero a octubre de 2025: 6,7 millones de amenazas de malware de alta severidad y 16.000 intentos de explotación de vulnerabilidades críticas. fidelissecurity.com. Dato de fabricante sobre su propia base instalada, no estadística sectorial
NSA - “Ghidra: A Software Reverse Engineering Framework”, open-source. ghidra-sre.org
SANS Institute - “FOR610: Reverse-Engineering Malware: Malware Analysis Tools and Techniques”. sans.org/cyber-security-courses/reverse-engineering-malware
CyberSeek — herramienta de itinerarios profesionales en ciberseguridad del NICE y Lightcast. Útil para ver qué competencias componen el perfil de analista de malware, pero sus datos de demanda y salario son de Estados Unidos: no son extrapolables al mercado español
MITRE ATT&CK - Framework de técnicas adversarias para clasificación de hallazgos de RE. matriz Enterprise de MITRE ATT&CK
Directiva 2009/24/CE del Parlamento Europeo sobre protección jurídica de programas de ordenador, Art. 6. art. 6 de la Directiva 2009/24/CE
Ley 1/2019, de Secretos Empresariales — art. 3.1.b: la observación, estudio o ensayo de un producto legalmente adquirido no constituye violación de secreto empresarial.
TRLPI — Real Decreto Legislativo 1/1996, art. 100.5 a 100.7: límites a los derechos de autor sobre programas, incluida la descompilación para lograr interoperabilidad.
Hex-Rays - “IDA Pro: The Interactive Disassembler”, herramienta comercial de referencia. hex-rays.com
VirusTotal - Servicio de análisis de malware y IOCs de Google/Mandiant. virustotal.com