DARPA AIxCC final en DEF CON 33: Team Atlanta gana con 18 zero-days reales parcheados a coste medio de $152

8 de agosto de 2025, DEF CON 33 Main Stage, Las Vegas Convention Center. DARPA anuncia los ganadores del AI Cyber Challenge (AIxCC). Primer puesto y $4M para Team Atlanta (Georgia Tech, Samsung Research, KAIST, POSTECH) con su sistema ATLANTIS. Segundo y $3M para Trail of Bits con Buttercup. Tercero y $1.5M para Theori. Los siete sistemas finalistas (Cyber Reasoning Systems, CRS) encontraron entre todos 54 de las 63 vulnerabilidades sintéticas plantadas (86 %) y parchearon 43 (68 %). Pero el dato que marca el evento es otro: encontraron además 18 zero-days reales no plantados en el código de los retos, y propusieron parches válidos para 11.

El coste medio por challenge task: $152 en compute + LLM credits. Para contexto operativo: 18 zero-days en código real abierto, parcheados, en un fin de semana, por menos del salary anual de un junior pentester.

Lectura: análisis de los resultados publicados por DARPA y los blogs de los equipos. PoCs no aplicables (los repos de los CRS son denso material para futuros posts cuando los siete estén abiertos).

Cómo está montada la final

La final operó del 7 al 10 de agosto durante DEF CON 33. Setup:

Siete equipos finalistas seleccionados tras semifinal en DEF CON 32 (agosto 2024): Team Atlanta, Trail of Bits, Theori, Shellphish, 42-b3yond-6ug, Lacrosse, NCC Group.
53 challenge projects repartidos en C y Java. Mix de software open-source ampliamente desplegado — incluyendo proyectos del kernel Linux, bibliotecas críticas y backbones de desarrollo.
63 vulnerabilidades sintéticas plantadas por el organizing committee en esos 53 proyectos. Mix realista — patrones que aparecen en CVEs históricos: integer overflows, use-after-free, path traversal, deserialización, race conditions.
Presupuesto compute por equipo: $85.000 en Azure (servidores, VMs, GPUs) más $50.000 en credits de LLM API. Anthropic, Google y OpenAI donaron $350.000 cada uno en credits, repartidos entre los siete equipos.
Tareas autónomas: cada CRS recibe un proyecto, su test suite, y un budget de compute/LLM. Tiene que (a) detectar bugs, (b) escribir proof of vulnerability que dispare el bug, (c) proponer un parche que arregle el bug sin romper la test suite.

Cambio respecto a generaciones anteriores de Cyber Grand Challenge (2016): los CRS de 2016 trabajaban sobre binarios compilados con bugs sintéticos en arquitectura propia — un sistema operativo construido para la competición. Los CRS de 2025 trabajan sobre código fuente real de proyectos reales en producción, en lenguajes que el LLM “entiende” semánticamente.

La arquitectura común a los CRS finalistas

Lo que comparten los siete sistemas, según paper SoK publicado en septiembre por miembros del organizing committee y los blogs de los equipos:

Capa de LLM (Claude Opus 4 / Sonnet 4, GPT-4o / o3, Gemini 2.5 según el equipo) para razonamiento semántico sobre código — detección de patrones sospechosos, generación de hipótesis, escritura de proof of vulnerability, escritura de parches.
Capa de program analysis clásica: fuzzing dirigido (AFL++, libFuzzer, custom), ejecución simbólica (KLEE, angr, Mayhem), análisis estático (CodeQL, Semgrep, Joern).
Capa de orquestación: el LLM decide qué herramienta clásica disparar contra qué pieza de código, lee los resultados, refina hipótesis, itera.

La novedad respecto al patrón “LLM-as-pentester” naive de 2023-2024: el LLM no hace el bug hunting. Orquesta herramientas que sí lo hacen, e interpreta resultados. El bug se confirma con un crash reproducible que dispara el proof of vulnerability — no con la “intuición” del modelo.

Atlantis (Team Atlanta) — el ganador

Team Atlanta publica el paper técnico de ATLANTIS en septiembre (arxiv 2509.14589). Los detalles relevantes:

Score final: 392.76 puntos, ventaja de más de 170 sobre el segundo (Trail of Bits con Buttercup).
Combinación de directed fuzzing, ejecución simbólica y análisis estático, todo orquestado por capa LLM (mezcla de modelos según subtask).
Arquitectura modular: un módulo Threat Localization que selecciona zonas del código a investigar, un módulo Analysis que genera hipótesis, un módulo Triage Intelligence que descarta falsos positivos y prioriza, un módulo Patch Generator que produce el parche y lo valida contra el test suite.
Repo público en GitHub: Team-Atlanta/aixcc-afc-atlantis, licencia OSI-approved.

Lo interesante del approach Atlantis: separación clara entre detección y validación. El módulo Analysis genera muchas hipótesis (“este memcpy en esta función con esta longitud parece sospechoso”); el módulo Triage descarta el 90 % usando program analysis clásica. Solo lo que sobrevive triaje se envía al fuzzer dirigido para confirmar con crash. El resultado: muy poco false positive en lo que reporta como vulnerabilidad confirmada.

Buttercup (Trail of Bits) — el segundo

Trail of Bits publica análisis post-mortem en su blog. Buttercup:

Énfasis en patch quality: un bug encontrado pero parcheado con regresión no puntúa. Buttercup tiene capa específica de patch validation que ejecuta extensas pruebas no incluidas en el test suite oficial del proyecto.
Uso de multi-LLM ensembling — diferentes modelos opinan sobre el mismo bug y el parche, y solo se acepta lo que tiene consenso o evidencia adicional.
Trail of Bits hace énfasis pública en safety del CRS — el sistema no ejecuta código en hosts no aislados, no llama a red excepto a APIs LLM y al fuzzer, no escribe a directorios fuera del workdir asignado.

Theori — el tercero

Tercer puesto. Theori publica writeup técnico del approach. El sistema usa LLM-guided fuzzing con un coverage feedback loop más agresivo que sus competidores: si el fuzzer se atasca, el LLM lee la código de la función “atascada” y propone seeds de input mutados para romper el plateau.

Los 18 zero-days reales — lo importante

Las 63 vulnerabilidades sintéticas plantadas por el organizing committee son el benchmark controlado. Pero el dato que cambia la conversación: los CRS encontraron además 18 bugs reales no plantados en el código de los proyectos challenge. Seis en codebases C (incluyendo una vulnerabilidad encontrada en paralelo por el maintainer del proyecto durante el evento) y 12 en codebases Java. Los equipos propusieron parches válidos para 11 de los 18.

Esto es ineditol. Fuzzing tradicional encuentra bugs en código real desde hace 15 años (afl-fuzz, OSS-Fuzz). Lo que añaden los CRS:

Confirmación semántica: el LLM lee el crash dump, lee el código adyacente, escribe el proof of vulnerability en lenguaje humano, y propone un parche en el mismo lenguaje del proyecto.
Patch validation funcional: el patch propuesto no solo arregla el crash; pasa el test suite del proyecto. Esto es lo que tradicionalmente exige humano.
Velocidad: los 18 zero-days se encontraron en el plazo de la final — un fin de semana operativo. El precedente más cercano (OSS-Fuzz operando continuamente, equipos humanos de bug bounty) opera en plazos de meses para resultado equivalente.

DARPA reporta cost medio de $152 por challenge task completada. Esto incluye Azure compute y LLM credits. Cinco de los siete equipos usaron menos del 25 % de su budget de LLM credits — el bottleneck en la práctica fue Azure compute, no inferencia de modelo.

Open-source release obligatorio

Una condición del programa AIxCC desde el inicio: los siete CRS finalistas se publican como software libre bajo licencia OSI-approved tras la final. A la fecha de cierre del evento, cinco de los siete ya están publicados; los otros dos se esperan en las semanas siguientes.

Los repos publicados a 10 de agosto:

Team Atlanta — ATLANTIS: github.com/Team-Atlanta/aixcc-afc-atlantis
Trail of Bits — Buttercup: link en su blog post.
Theori: GitHub corporate.
Shellphish, 42-b3yond-6ug: links en sus respectivos repos.

Material denso para los próximos meses. Cuando los siete estén abiertos y haya escrutinio comunitario, podremos hablar con detalle de cuál CRS detecta qué patrones, dónde se rompen, y qué patterns son replicables fuera del setup de la competición.

Lectura para el SOC

Tres preguntas que se reabren con AIxCC:

1. ¿Qué pasa con responsible disclosure?

Si un atacante (state-sponsored o no) replica ATLANTIS sobre un proyecto open-source con userbase grande, puede encontrar zero-days a coste $152 cada uno. La gracia es el supply — el atacante puede enumerar repos, lanzar el CRS, y cosechar. La política de responsible disclosure asume un investigador humano con motivos mixtos. Con CRS autónomos, la métrica relevante deja de ser “número de bugs encontrados por investigador / año” y pasa a ser “throughput de un sistema operando continuo”.

El otro lado: el defender puede operar el mismo CRS sobre sus propios proyectos antes que el atacante. OSS-Fuzz ya hace esto a baja velocidad; un OSS-Fuzz aumentado con LLM puede subir la patch coverage pre-disclosure. Pero asume que el defender corre el sistema y publica parches; muchos maintainers de open-source no van a tener tiempo / capacidad para procesar el flujo.

2. ¿Qué pasa con offensive AI?

Los CRS de AIxCC son sistemas defensive por diseño — encuentran bugs y los parchean. Pero el componente de detección/exploitation es el 90 % del trabajo; el parche es la última fase. Un CRS sin la fase de parche es un sistema offensive funcional. Habrá durante 2025-2026 versiones forked / replicadas de los CRS finalistas con el módulo de parche reemplazado por un módulo de weaponization (escribir el proof of exploit con shellcode o RCE, no solo el proof of vulnerability).

Para el SOC: la pregunta no es si sistemas de este tipo existen offensively en 2026, es quién los va a operar y contra qué stack. Edge appliances (Ivanti, Fortinet, Palo Alto, Cisco IOS XE — código C heredado, exactamente el dominio donde Atlantis encontró 6 de los 18 reales) son candidato.

3. ¿Y los maintainers humanos?

Un maintainer de un proyecto open-source pequeño puede recibir el próximo mes un PR escrito por un CRS con un parche correcto para un bug del que no sabía, junto con proof of vulnerability. El flujo es positivo. Pero también puede recibir un PR escrito por un atacante humano usando un CRS forked que parece un parche correcto y en realidad introduce backdoor sutil — XZ-utils 5.6.0 (CVE-2024-3094, post de abril 2024) hecho a escala industrial.

La pregunta para mantenedores: cómo se valida un PR generado por LLM cuando el volumen sube dos órdenes de magnitud. La respuesta no la sabe nadie todavía.

Notas operativas

Los repos de los CRS publicados son densos. Esperar 6–12 meses para análisis comunitario sólido sobre cuáles funcionan en qué dominio.
Los proyectos challenge específicos no son públicos (DARPA mantiene listado opaco para evitar contaminar el dataset para futuras ediciones). Las características — C/Java, proyectos open-source ampliamente desplegados — son lo que se ha publicado.
DARPA confirma que ARPA-H es colaborador en la edición — el énfasis sanitario (healthcare critical infrastructure) está en el material de marketing pero no aparece como categoría separada de challenges. La transición a un programa follow-on con foco sectorial es probable.