Experimento para ocultar una puerta trasera en un binario de unos 40 MB y comprobar si puede detectarse con IA y Ghidra

• Para validar la posibilidad de la detección de malware basada en IA, se insertaron artificialmente puertas traseras en varios binarios de servidores de código abierto y se realizaron pruebas de detección con agentes de IA y Ghidra
• Aunque modelos recientes como Claude Opus 4.6 encontraron algunas puertas traseras simples, la tasa de detección fue del 49% y la tasa de falsos positivos del 28%, un nivel inadecuado para uso real
• En el experimento se usaron proyectos basados en C y Rust como lighttpd, dnsmasq, Dropbear y Sozu, y la IA realizó el análisis sin código fuente, solo con herramientas de ingeniería inversa
• Algunos modelos mostraron falta de criterio, confundiendo llamadas claramente maliciosas como execl("/bin/sh", ...) con funciones normales, o enfocándose en código irrelevante
• Los investigadores evaluaron que la IA todavía no es una herramienta de seguridad completa, pero que ha avanzado hasta un nivel en el que incluso personas no expertas pueden realizar una revisión inicial de seguridad

---

Contexto de la investigación

• Incidentes recientes como el ataque a la cadena de suministro Shai Hulud 2.0 y el caso de secuestro del binario de Notepad++ han puesto de relieve el riesgo de ejecutar archivos no confiables
  • Los atacantes insertan código malicioso en software legítimo para robar credenciales o ejecutar comandos remotos
• También se han reportado casos de módulos de comunicación ocultos o cuentas con puerta trasera en firmware y dispositivos de hardware
• Para responder a estas amenazas, se probó si la IA puede detectar comportamientos maliciosos a nivel binario

Resumen del análisis de binarios

• Mientras la programación general trabaja con código fuente, el análisis de malware debe interpretar binarios a nivel de lenguaje máquina
• En el proceso de compilación se pierden datos de alto nivel como nombres de funciones y variables, y la optimización distorsiona la estructura del código
• El análisis pasa por un proceso de ingeniería inversa que convierte lenguaje máquina → ensamblador → seudocódigo en C
  • Herramientas de código abierto: Ghidra, Radare2
  • Herramientas comerciales: IDA Pro, Binary Ninja
• Estas herramientas restauran el significado del código, pero los resultados quedan llenos de identificadores sin sentido como FUN_00130550, bVar49

Configuración del benchmark BinaryAudit

• Se insertaron puertas traseras de prueba en varios servidores de código abierto (lighttpd, dnsmasq, Dropbear, Sozu)
  • Ejemplo: ejecutar comandos mediante encabezados HTTP o lanzar comandos de shell a través de opciones DHCP
• A la IA se le proporcionaron solo ejecutables compilados, sin código fuente, y analizó usando Ghidra, Radare2, binutils, etc.
• El objetivo era identificar si existía una puerta trasera y la dirección de inicio de la función correspondiente
• Algunas tareas se diseñaron para determinar únicamente cuál de varios binarios estaba infectado

Casos de éxito en la detección

• Claude Opus 4.5 detectó en 5 minutos una puerta trasera basada en el encabezado X-Forwarded-Debug insertada en el servidor lighttpd
  • Encontró una llamada a popen() y confirmó la lógica de ejecución de comandos mediante ingeniería inversa con Radare2
  • Incluso identificó la estructura que devolvía el resultado mediante el encabezado de respuesta X-Request-Trace
• El modelo combinó comandos como nm, strings, grep y r2 para ejecutar un procedimiento de análisis automatizado

Casos de fallo en la detección

• Claude Opus 4.6 interpretó como función normal una puerta trasera que ejecutaba /bin/sh insertada en el código de procesamiento DHCP de dnsmasq
  • Encontró la llamada execl("/bin/sh", "sh", "-c", ...), pero la confundió con la ejecución de scripts DHCP
  • En realidad, era código vulnerable que ejecutaba directamente el contenido de los paquetes del cliente
• Aunque encontró la ubicación exacta, negó el riesgo y se movió a otra función, por lo que no detectó la amenaza

Limitaciones de la IA y problema de falsos positivos

• Con una tasa promedio de falsos positivos del 28%, hubo muchos casos en que reportó erróneamente puertas traseras en binarios limpios
  • Ejemplo: Gemini 3 Pro confundió código normal de análisis de opciones de línea de comandos con una “puerta trasera de ejecución de comandos”
• En la comunidad de seguridad también se señala como problema la baja calidad de los reportes generados por IA
  • El proyecto curl afirmó que la mayoría de los reportes de bugs generados por IA no tienen sentido
• Para usarse como herramienta de seguridad práctica, se necesita una tasa de falsos positivos inferior al 0.001%

Restricciones de las herramientas de código abierto

• Ghidra y Radare2 son útiles para analizar código en C, pero su rendimiento cae con binarios de Rust y Go
  • Ejemplo: el servidor Caddy basado en Go (50 MB) tardó 40 minutos en cargarse en Ghidra y el resultado fue impreciso
  • IDA Pro lo cargó en 5 minutos y proporcionó código preciso
• En el experimento se trabajó principalmente con binarios basados en C para excluir diferencias en la calidad de las herramientas

Resultados y perspectivas

• Tasas de detección registradas: Claude Opus 4.6: 49%, Gemini 3 Pro: 44%, Claude Opus 4.5: 37%
• Siguen siendo vulnerables frente a binarios grandes o puertas traseras que imitan comportamiento legítimo
• Aun así, la IA ha avanzado hasta el punto de poder manipular Ghidra directamente para realizar ingeniería inversa
  • Incluso personas no expertas pueden hacer una revisión inicial de archivos ejecutables sospechosos
• Como direcciones futuras se plantean la integración con herramientas comerciales y el análisis de seguridad basado en modelos locales
• El benchmark completo y los resultados están publicados en GitHub en QuesmaOrg/BinaryAudit

[GN⁺]

Comentarios en Hacker News

• Aunque dicen que no aplicaron ofuscación, si ocultan imports o símbolos y ofuscan cadenas, la tasa de detección cae inmediatamente a 0
  En esos casos, lo que detecta el LLM no es más que un patrón lingüístico anómalo asociado con comportamiento malicioso, así que no resulta tan impresionante

  • Soy uno de los autores del paper. Estas tareas eran de nivel introductorio, y lo sorprendente fue que existan modelos capaces de captar ciertos patrones incluso viendo solo código binario
    Por ejemplo, los únicos modelos que entienden tooling como Ghidra o Radare2 son Opus 4.5, 4.6, Gemini 3 Pro y GLM 5
    El benchmark relacionado puede verse aquí
    Esto es apenas un punto de partida para que la IA pueda trabajar con binarios, y todavía falta mucho para llegar a una solución completa
  • Cuando desarrollé la herramienta ghidra-cli para LLMs, usé crackme como prueba, y si se lo indicabas en el prompt, también superaba bien código ofuscado
    En ingeniería inversa de software real, tras dar vueltas un rato y reconocer que había ofuscación, a partir de ahí el proceso fluía bien actualizando resultados en documentos como CLAUDE.md
  • El artículo también dice explícitamente que se eliminaron los símbolos. Los backdoors reales ya vienen ofuscados con código mínimo
    Como ejemplo, se pueden revisar los parches de dnsmasq-backdoor y dropbear-brokenauth
  • Usando Opus 4.5 y 4.6, hice ingeniería inversa completa de malware ofuscado con un plugin de Ghidra para Claude Code
    Pero lo que analicé no era un backdoor de nivel estatal, sino más bien del nivel de un crack de software
  • He visto que los LLM captan bastante bien este tipo de patrones extraños. Eso se debe a que han aprendido diversas técnicas de cifrado y ofuscación
    Más bien es la lógica compleja lo que rompe a los LLM, aunque los buenos modelos al menos reconocen por sí mismos esa complejidad y la señalan

• Presento mi proyecto ghidra-cli
  Hice ingeniería inversa del formato de archivos de Altium (la parte en Delphi) con Ghidra, y el resultado fue sorprendentemente bueno
  Los modelos no pueden escribir un parser completo desde cero, pero antes de los LLM ni siquiera habría intentado algo así
  No confiaría en esto para una auditoría de seguridad, pero los modelos actuales sí son bastante utilizables para ingeniería inversa de formatos de archivo

  • Últimamente estoy viendo el enfoque de usar agentes como herramientas de apoyo. No dependo completamente de ellos, sino que los uso para ampliar capacidades
    Por ejemplo, les delego generación de diagramas, mapeo de superficie de ataque o exploración de código, mientras yo me concentro en el análisis manual
    Como el LLM se encarga del trabajo repetitivo y aburrido, todo va más rápido. Pero si le delegas demasiado, caes en una trampa de productividad
    Si usas una combinación de agentes con el conjunto adecuado de “skills”, la eficiencia claramente mejora
  • Nosotros usamos PyGhidra, pero la accesibilidad vía CLI podría ser mejor
    La mayor limitación de Ghidra era que el análisis de código Go era demasiado lento
  • Este proyecto está realmente genial. Es mucho más sofisticado que lo que yo hice con Ghidra + LLM
  • El ecosistema relacionado está muy activo. También hubo un caso reciente de servidor MCP
    Yo he probado GhidrAssistMCP, analyzeHeadless, PyGhidra y otros,
    y en particular un enfoque con SKILL.md explícito tiene muy buena integración con agentes de IA
  • Me pregunto cómo se compara este enfoque con varios servidores MCP de Ghidra

• El punto central de este hilo es la discusión metodológica
  Decir que “si agregas ofuscación, la tasa de éxito es 0%” es correcto, pero el objetivo del experimento es ver si la IA puede manejar binarios no ofuscados como lo haría un ingeniero inverso experimentado
  Ese es un escenario realmente utilizable, por ejemplo en auditorías internas o análisis de código legacy
  Lo verdaderamente importante es definir el modelo de amenaza. Si hablamos de atacantes automatizados, esto ya resulta bastante útil,
  pero frente a un atacante avanzado que tenga en cuenta la detección por IA, esta prueba no alcanza
  La validación práctica sería medir el rendimiento con ofuscación ligera como ocultación de imports o codificación de cadenas

  • Pero no poder reconocer un binario ofuscado es como no poder pasar un CAPTCHA
    Eso hace preguntarse si realmente se puede llamar “experto en recolección de manzanas” a un robot que no puede recoger manzanas cuando está nublado

• GPT es estable con 0% de falsos positivos, pero su tasa de detección ronda el 18%
  En cambio, Claude Opus 4.6 tiene una tasa de detección mayor, del 46%, pero con 22% de falsos positivos
  Si se combinaran varios modelos, dejando que uno diseñe el procedimiento de validación y otro realice las pruebas de exploit, podrían salir resultados más interesantes

  • En realidad, esta metodología para medir rendimiento de clasificación binaria ya existe desde hace 100 años
    Pero con la llegada de los modelos generativos, parece que todo el mundo la olvidó

• La clave es que, aunque a la IA le cuesta hacer una detección de malware completamente fiable, ahora para los desarrolladores es mucho más fácil realizar una auditoría de seguridad inicial
  Incluso un desarrollador sin experiencia en ingeniería inversa puede hacer un primer análisis de un binario sospechoso
  Esto puede extenderse no solo a seguridad, sino también a optimización, depuración, ingeniería inversa de hardware y portabilidad de arquitecturas
  Al final, lo importante es usar la IA no como un analizador perfecto, sino como una herramienta de generación de hipótesis

• Los ejecutables del benchmark están compuestos por cientos o miles de funciones, y el backdoor son apenas unas pocas líneas entre ellas
  Por eso hay que explorar estratégicamente rutas clave como el parser de red o las rutinas de manejo de entrada
  Una posibilidad sería darle al LLM esa estrategia en forma de archivo .md

  • Pero eso podría contaminar el experimento. En el momento en que le dices que “podría haber un backdoor”, ya le estás dando una pista
    Una sola palabra sutil del prompt puede cambiar el resultado
    Al final, la complejidad del diseño experimental se dispara y la robustez de los resultados se debilita
  • Aun así, considerando que la configuración de tareas de este estudio fue simple, los resultados ya son impresionantes
    Si se suma la guía de un experto, podría producirse un fuerte efecto de amplificación del rendimiento
  • Pero si le das la estrategia en un documento, muchas veces el modelo simplemente la imita y finge estar “pensando estratégicamente”
    Hacer que la IA siga de verdad el pensamiento estratégico humano sigue siendo algo difícil

• El enlace directo del benchmark está aquí,
  y el código open source puede revisarse en el repositorio de GitHub

• El resultado de que Gemini tenga la mayor tasa de falsos positivos coincide con mi experiencia
  He usado ChatGPT, Claude y Gemini, y Gemini es el más sesgado hacia respuestas positivas
  Siempre da la respuesta más optimista
  Estaba buscando un benchmark que mostrara esta característica con números, y estos resultados podrían servir como evidencia

• No soy experto, pero para reducir el problema de falsos positivos, me pregunto si no convendría hacer que el modelo ejecute directamente el backdoor para verificarlo

  • Pero la mayoría de los modelos rechazan ese tipo de acciones por sus políticas de seguridad
    Por eso es difícil compararlos entre sí, y en cambio se les pide que especifiquen la ubicación del backdoor
    Si uno personalizara o afinara directamente el modelo, el enfoque que propones podría ser útil

• Que el mejor modelo haya detectado solo alrededor del 50% no está mal. Incluso podría ser mejor que un humano
  Pero me intriga por qué se perdió el otro 50%
  Es interesante que Claude Opus 4.6 encontrara el backdoor y aun así concluyera que “no hay problema”
  Al final, esto muestra que sin apoyo del juicio humano, a la IA le sigue costando llegar a una comprensión completa