Los modelos de IA ofensivos más peligrosos: separando el hype de la capacidad real

"No, el problema no es que la IA pueda escribir un exploit. El problema es que empieza a parecerse peligrosamente a un compañero de red team que no duerme, no se distrae y puede leer diez mil páginas de documentación antes de que termines el primer café."

Durante los últimos dos años hemos visto titulares casi semanales sobre modelos de IA capaces de encontrar vulnerabilidades 0-day, escribir malware o comprometer infraestructuras enteras. Entre el marketing de los fabricantes, los benchmarks cocinados y las discusiones en X y Reddit, es difícil distinguir qué modelos son realmente preocupantes desde una perspectiva ofensiva.

La pregunta correcta no es: "¿Qué modelo genera el mejor payload?". La pregunta correcta es: "¿Qué modelo aumenta más la capacidad operativa de un atacante competente?" Porque la diferencia entre ambas preguntas es enorme.

Un exploit aislado tiene un valor limitado. Un sistema capaz de analizar código, identificar superficies de ataque, correlacionar documentación, generar tooling, interpretar logs y adaptarse dinámicamente durante una operación es otra historia. Y ahí es donde empieza la conversación seria.

La métrica equivocada: escribir exploits

Existe una obsesión casi infantil por medir la peligrosidad de un modelo preguntándole si puede generar un exploit para una vulnerabilidad conocida. Es una métrica pésima. 

Cualquier profesional que haya hecho pentesting real sabe que el exploit suele ser la parte fácil. Lo complicado es Identificar el vector, comprender la arquitectura, encontrar supuestos erróneos, correlacionar componentes, construir cadenas de ataque y adaptarse cuando el entorno real no coincide con la teoría.

En otras palabras: el razonamiento importa más que el payload.

Los modelos más peligrosos no son los que producen más líneas de código ofensivo. Son los que entienden sistemas.

Nivel 1: los generadores de código

Aquí encontramos muchos modelos open source populares. Su capacidad principal consiste en generar scripts, adaptar PoCs existentes, automatizar tareas repetitivas y crear tooling auxiliar.

Por ejemplo, un operador proporciona:

@app.route("/upload")
def upload():
filename = request.args.get("file")
return open(filename).read()

El modelo detecta rápidamente:

  • Path Traversal.
  • Ausencia de validación.
  • Posible lectura arbitraria.

Y genera pruebas inmediatas:

curl "/upload?file=../../../../etc/passwd"

Impresionante para un principiante, pero normal para un pentester. Útil, pero no revolucionario.

Nivel 2: los analistas

Aquí empieza lo interesante. Modelos como DeepSeek-R1, GPT-5.5 o Claude Opus destacan menos por generar código y más por interpretar sistemas completos. Supongamos por ejemplo una aplicación con un frontend React, un backend Java Spring, Redis, Kafka, Kubernetes, e integración SAML.

Un modelo de primera generación ve componentes aislados. Un modelo avanzado empieza a preguntarse:

  • ¿Existe confusión de identidad entre proveedores SAML?
  • ¿Hay trust boundaries mal definidas?
  • ¿Qué ocurre si Redis se usa como cache de autenticación?
  • ¿Hay inconsistencias entre microservicios?

Ya no estamos hablando de payloads. Estamos hablando de arquitectura. Y muchas vulnerabilidades modernas nacen precisamente ahí.

El salto cualitativo: descubrir relaciones invisibles

Las vulnerabilidades más valiosas rara vez aparecen en una única línea de código. Aparecen cuando dos componentes perfectamente válidos interactúan de manera inesperada.

Ejemplo simplificado:

Servicio A:

if user.is_admin:
allow()

Servicio B:

if token.role == "administrator":
allow()

Ambos son correctos por separado.

Pero si existe una traducción defectuosa entre roles:

{
"admin":"administrator"
}

puede aparecer una elevación de privilegios. Esto es precisamente el tipo de razonamiento donde los modelos modernos están empezando a destacar.

El verdadero monstruo: contexto masivo

Hace unos años un analista humano revisaba un repositorio, algo de documentación, un conjunto de logs... Ahora un modelo puede absorber simultáneamente miles de archivos, RFCs completas, arquitecturas empresariales, manuales internos. el historial completo de tickets....

La consecuencia es sencilla: encuentra correlaciones que antes requerían semanas. No porque sea más inteligente si no porque puede procesar más contexto y a velocidades absurdas.

Claude Mythos y el miedo de los laboratorios

Gran parte de la conversación reciente gira alrededor de Claude Mythos. Lo interesante no son las cifras. Lo interesante es qué tipo de tareas empezó a resolver. Los informes públicos describen comportamientos preocupantes:

  • Comprensión profunda de software complejo.
  • Identificación de vulnerabilidades sutiles.
  • Generación de hipótesis de explotación.
  • Investigación autónoma prolongada.

No es que "hackee mejor". Es que parece investigar mejor. Y eso es mucho más importante.

GPT-5.5 y la sorpresa incómoda

Mientras todo el mundo hablaba de Mythos, varios investigadores encontraron algo curioso: en numerosos escenarios reales GPT-5.5 estaba peligrosamente cerca.

La diferencia no era tan grande como sugerían algunos titulares. Especialmente en auditoría de código, reverse engineering, análisis de protocolos y automatización de pruebas.

Esto plantea una pregunta incómoda: ¿estamos viendo una convergencia entre los mejores modelos? Cada vez parece más que sí. De hecho, Anthropic lo sabe y por eso se ha apresurado a lanzar también Fable5 que parece tener la misma base, pero con guardrails fuertes (bloqueos + fallback a modelos más seguros). Está claro que no puede esperar a que otras compañías empiecen a adoptar e integrar otros modelos y pone en el mercado un "hermano pequeño".

Lo que realmente asusta: agentes

Aquí está el punto que muchos pasan por alto. Un modelo aislado tiene limitaciones. Un agente no. Con un buen abanico de herramientas disponibles, un flujo y un objetivo claro puede trabajar durante horas (si el consumo de tokens y tu presupuesto lo permiten). Sin intervención humana. 

Ese escenario es mucho más relevante que cualquier benchmark sobre exploits. Sería el equivalente a un junior infinito.

Una forma útil de entender la situación actual es esta: Los modelos no son aún un red team senior. Pero sí empiezan a parecerse a un junior extraordinariamente rápido. Un junior que nunca se cansa, nunca olvida documentación y nunca deja de buscar. Y puede ejecutar cientos de tareas paralelas. La productividad resultante es enorme.

Las opciones open source

Muchos asumen que la amenaza vendrá exclusivamente de modelos cerrados. Error. Los modelos abiertos también avanzan con enorme rapidez. Especialmente DeepSeek-R1, Qwen y Llama.

La ventaja actual de los modelos comerciales sigue siendo clara. Pero la distancia ya no se mide en órdenes de magnitud. Se mide en márgenes. Y eso cambia completamente el panorama.

Entonces, ¿cuál es el modelo ofensivo más peligroso?

La respuesta decepcionará a quienes buscan una lista. 

No es GPT.

No es Claude.

No es DeepSeek.

No es Qwen.

El sistema más peligroso hoy es: 

Un modelo de frontera conectado a herramientas, memoria, navegación, ejecución de código y automatización.

Comentarios