Según Dream Research Labs, a principios de julio de 2026, un marco de ataque automatizado descargó los paquetes de JavaScript de un portal web gubernamental y los analizó.
No se ha explotado. Se ha analizado. A partir del código que el portal proporciona a todos los visitantes por diseño, se han extraído los puntos finales de la API, una configuración de proveedor de identidad y dos claves de firma; a continuación, se han mapeado 21 sistemas gubernamentales conectados, incluida la infraestructura de inicio de sesión único que los une.
No se rompió nada. Cualquier pentester hace esto durante la primera hora de una intervención. Lo novedoso es que lo haya hecho un marco de trabajo, que haya clasificado lo que encontró y que haya seguido adelante sin esperar a que se le diera la orden.
Este año he leído cinco casos que se clasifican como ataques de IA. Si los comparamos, revelan algo que los titulares no mencionan: en ninguno de ellos se necesitó una técnica que no existiera ya. El más reciente comprimió una cadena completa en menos de diez horas, y la compresión se logró eliminando las pausas entre los pasos conocidos.
Los cinco casos
Un operador humano con un acelerador.
Sysdig documentó una intrusión el 28 de noviembre de 2025 que comenzó con la exposición de credenciales de AWS en buckets públicos de S3 y culminó con la obtención de privilegios de administrador a través de una puerta trasera. Ocho minutos hasta la ejecución de Lambda, privilegios de administrador en menos de diez. El título de Sysdig habla de «asistencia mediante IA» y su conclusión es cautelosa: «múltiples indicadores que sugieren que el actor malicioso utilizó modelos de lenguaje a gran escala». Mi interpretación es que se trata de una persona al mando del teclado que utiliza modelos para acelerar el reconocimiento y la generación de código, lo cual no es lo mismo que un agente. Lo he tratado aquí.
Un ser humano que establece los objetivos y unos agentes que los llevan a cabo.
Unit 42 publicó esto el 2 de septiembre de 2026, y es el caso más difícil de la serie. Se violó una API pública, se rastrearon los repositorios en busca de tokens codificados de forma estática, esos tokens permitieron acceder al gestor de secretos, se secuestró el proceso de CI/CD para obtener claves de cloud y, finalmente, los propios puntos de conexión de IA de la víctima se convirtieron en infraestructura de ataque. En menos de diez horas, se utilizaron más de 50 técnicas de MITRE ATT&CK .
Lee cómo plantean el tema en lugar de fijarte solo en los titulares. En la introducción se dice que la red fue vulnerada «de forma autónoma», pero el pie de foto es preciso: «El actor establece objetivos y toma decisiones con consecuencias». Su resumen de lo que lo hizo destacable es la frase que importa: «Eficiencia operativa asistida por IA, sin necesidad de un « zero-day » novedoso ni de técnicas de espionaje de élite». La comparación de dos semanas que se cita en todas partes es su propia estimación del «equipo rojo», no una intrusión observada. Se mantuvo un control: un intento de introducir una puerta trasera en las configuraciones de Terraform fracasó porque «los controles estrictos de protección de ramas lo impidieron». Además, corrigieron la publicación el 3 de septiembre para aclarar que se trataba de una intrusión y no de un ataque de ransomware, algo que varios medios siguen interpretando erróneamente.
Un agente, dentro de un laboratorio que ha sido debilitado a propósito.
Hugging Face reveló a mediados de julio una intrusión perpetrada por un agente y, el 21 de julio, OpenAI confirmó que había sido provocada por una combinación de sus propios modelos. Su cronología técnica abarca aproximadamente 17 600 acciones recuperadas a lo largo de 4,5 días.
El contexto se omite constantemente: la evaluación «desactivó deliberadamente los clasificadores de seguridad de producción de OpenAI y redujo los rechazos por motivos de ciberseguridad», y «ningún ser humano dirigió los pasos individuales». Eso no le resta importancia. Un entorno de pruebas debilitado siguió generando una intrusión real en varias fases contra un tercero real, y una credencial con un alcance excesivo otorgó al agente privilegios de administrador de clúster en dos clústeres en menos de un segundo tras su suplantación.
Las herramientas de IA se utilizan indebidamente como infraestructura, sin que ningún modelo tome las decisiones.
Desde 2025, unos gusanos autorreplicantes se han estado propagando a través de npm. La carga útil se ejecuta en el momento de la instalación, recopila todos los tokens del host y se vuelve a publicar a través de cualquier canal al que la víctima pueda publicar. Elastic Security Labs identificó la última oleada el 4 de agosto y notificó más de 400 paquetes comprometidos.
La lógica de propagación es código determinista, no un modelo que elige movimientos. Pero las herramientas de IA están muy presentes: un gancho que se activa al iniciar una nueva sesión de Claude, con las entradas creadas como claude@users.noreply.github.com, y un coleccionista que busca credenciales de Anthropic, OpenAI y Cursor. Así es como se presenta, en gran medida, la IA en una cadena de ataque en la actualidad: las herramientas de desarrollo como superficie de ejecución, las claves de IA como botín y nada que tome decisiones.
Un marco casi autónomo, en condiciones reales.
Volvamos al caso «Dream», publicado el 12 de agosto. El espacio de trabajo recuperado consta de 1.395 archivos que abarcan 12 oleadas de ataques, en las que se envían hasta ocho subagentes por oleada, al tiempo que se clasifican 14 cadenas de ataque de forma continua. El resto de esta entrada se centra en tres hallazgos: API sin autenticación que devuelven sesiones válidas sin que se hayan facilitado credenciales, una API que acepta tokens web JSON firmados con el ninguno algoritmo, y 85 cuentas pirateadas mediante el método «spraying», de las cuales 84 accedieron a un sistema interno a través de un puente de SSO.
Fíjate en la expresión que utiliza Dream y que la mayoría de los medios pasaron por alto: «casi autónoma». Había una persona involucrada en este proceso, y las negativas del modelo se eludieron al presentar la actividad como pruebas de penetración autorizadas.
Las cifras proceden de los propios informes del marco. Dream validó la propia tasa de pivote del SSO y afirma que notificó a las organizaciones afectadas antes de la publicación, mientras que su portavoz declaró a CSO Online que la investigación no encontró pruebas de una violación confirmada de los sistemas de la entidad, aunque se negó a revelar el nombre de esta. Las técnicas son la parte que perdura.
Los mismos tres puntos ciegos
Analizo las intrusiones en relación con tres lagunas estructurales en el funcionamiento de la detección. Estas cinco no fue necesario adaptarlas a ese esquema.
Brecha 1. No parece haber ningún problema.
Toda la fase de reconocimiento de Dream se llevó a cabo a partir de material que el objetivo publica a propósito. Las vulnerabilidades que funcionaron eran del lado del servidor y bastante comunes: API sin autenticación y validación débil de tokens. No había carga útil en el disco, porque simplemente no existía. El caso de Sysdig sigue el mismo patrón, pero un nivel más abajo, en servicios nativos de AWS y con credenciales reales, donde cada acción se admite y se registra correctamente.
Nada de lo que hacían parecía estar mal.
Paso 2. La autenticación se realiza correctamente.
Los nombres de usuario proceden de una API que no requiere autenticación. Se lanzan en oleadas patrones predecibles. El OCR resuelve el CAPTCHA. Cualquier cuenta que caiga en la trampa permite un inicio de sesión correcto, y no se produce ningún incidente de acceso no autorizado por el que abrir un ticket.
En ninguno-La detección de algoritmos merece una línea aparte. Una API que acepta un token alegando que no necesita firma no está siendo engañada. Ha aceptado omitir la comprobación y, para esa API, un token falsificado y uno válido son lo mismo.
La autenticación se ha realizado correctamente.
Brecha 3. El movimiento no es visible.
La cifra que hay que recordar es 84 de 85. Esas credenciales se filtraron en un portal de ofimática, un sistema periférico de bajo valor. A continuación, el puente de SSO amplió ese acceso a los paneles de control internos y a los datos del personal. La credencial se encuentra en un plano, el acceso se lleva a cabo en otro, y la federación entre ambos hace exactamente lo que se diseñó para hacer: registrar un inicio de sesión correcto en cada paso.
Tres registros de auditoría, tres incidencias SOC, una filtración.
La compresión es real. No se trata de una velocidad simulada.
El «tiempo de escape» —el intervalo entre el acceso inicial y el primer movimiento lateral— dejó de utilizarse como métrica por parte de CrowdStrike el 1 de septiembre, con el argumento de que lo que el sector había venido denominando «velocidad de máquina» no era más que «velocidad humana» con mejores herramientas. No se propuso ningún sustituto, más allá del argumento de que los ataques ahora se ejecutan a la velocidad de la inferencia y no dejan tiempo alguno.
Al día siguiente, Unit 42 publicó un informe sobre una intrusión de diez horas y ofreció su propia explicación sobre el origen de esa cifra. No se trata de una deducción. Esto es lo que dice, textualmente: «Los agentes de IA reducen el tiempo entre los pasos del flujo de ataque: los agentes de IA de este ataque se diseñaron para analizar los resultados sin procesar de las herramientas y dar rápidamente los siguientes pasos». En ningún momento del informe se menciona la latencia del modelo. Lo que sí se menciona es el paralelismo, la replanificación en tiempo real sin idas y vueltas del operador, y la ausencia de intervención humana entre el momento en que una herramienta devuelve el resultado y la activación de la siguiente acción.
Comparemos las duraciones una al lado de la otra. Sysdig, con una persona al teclado y modelos que le ayudan: ocho minutos. Unit 42, con una persona que establece los objetivos y agentes que los ejecutan: menos de diez horas. Un grupo de ransomware rastreado por Sophos sin utilizar IA en ningún momento: menos de 17 horas. Dream: aproximadamente cuatro días. Hugging Face: 4,5 días.
No existe una relación clara entre una mayor automatización y una reducción del tiempo. Los dos casos en los que ningún ser humano dirigía los pasos individuales son los dos más lentos, aproximadamente un factor de diez, y un ser humano sin ningún tipo de IA resultó más lento que un ser humano que utilizaba agentes. La duración refleja el grado de precisión con el que se definió el objetivo, no la cantidad de trabajo que realizó un modelo. La reducción es real, y referirse a ella como «velocidad de inferencia» apunta a un factor de control erróneo.
¿Qué se puede hacer al respecto?
Esto no modifica el marco. Solo cambia el orden de la lista.
- Enumera lo que publica tu propio front-end: puntos finales de la API, ID de cliente de OAuth y configuración del proveedor de identidad. Da por hecho que los paquetes se han analizado y se han cotejado, porque ahora ya es así.
- Considera las API no autenticadas como un problema de identidad, no como un fallo de seguridad. Un punto final que devuelve los nombres del personal y los identificadores de SSO sin necesidad de credenciales es, en realidad, una lista de nombres de usuario. Clasifícalo según lo que alimenta, no según lo que expone.
- Validar los algoritmos de tokens y auditar la confianza en la federación. Un JWT aceptado con
ningunoes un sistema de autenticación que ha decidido no autenticar. Y 84 de 85 significa que el puente SSO es tu verdadero radio de impacto. - Analiza tus herramientas de IA y tus recursos informáticos como superficie de ataque. Los gusanos de npm se ejecutan a través de un gancho de sesión y buscan claves de proveedores de IA. El atacante de Unit 42 convirtió los propios puntos finales de los modelos de la víctima en infraestructura, ocultando el tráfico de orquestación entre el tráfico habitual y facturando los recursos informáticos a la víctima.
- Busca el bucle, no la carga útil. Los indicadores de Unit 42 son los datos más concretos que se han publicado hasta ahora sobre intrusiones con agentes: ráfagas de solicitudes a la API, cambios rápidos de estado de 401 a 200, autenticaciones paralelas y uso repentino de modelos por parte de identidades inesperadas.
El papel de la detección basada en el comportamiento en este contexto
Las cinco intrusiones quedaron registradas. El caso de la Unidad 42 es el ejemplo más claro de por qué eso no es suficiente. Una llamada a la API, una descarga del repositorio, una lectura de secretos, la ejecución de un pipeline, el uso de una clave « cloud » en un punto final del modelo. Cada una de ellas estaba autorizada por sí sola y figuraba en el registro correspondiente. Diez horas es mucho tiempo en la respuesta a incidentes, y no es nada si la única forma de ver la cadena de eventos es montar cinco sistemas a mano a posteriori.
El relato de Hugging Face sobre cómo se detectó su incidente es el párrafo más útil que se ha publicado en todo el verano. Las primeras señales procedían de varias capas a la vez y «por sí solas, cada una de ellas resultaba ambigua». A continuación: «[...] nuestro conjunto de agentes de seguridad basados en IA las correlacionó y las interpretó como una señal de ataque coherente. Sin embargo, no logró elevar correctamente el nivel de gravedad de la alerta ni activar al equipo de guardia, lo que supuso una pérdida de tiempo precioso en la respuesta».
La correlación funcionó. El sistema agrupó señales ambiguas en un único ataque coherente, pero el hallazgo quedó ahí sin más porque nadie consideró que fuera lo suficientemente urgente como para avisar a alguien. Se trata de un fallo en la clasificación de prioridades tras una detección satisfactoria, lo cual es un problema distinto que requiere una solución diferente.
La detección no falla. Es incompleta. Eso ya era así cuando el operador era una persona que tecleaba, y estos cinco afirman que sigue siendo cierto cuando el operador es un marco de trabajo que clasifica 14 cadenas de ataque a la vez. Hay que rastrear el comportamiento, no la marca que hay detrás del ataque.
La versión completa de las tres brechas se encuentra en «Mind Your Attack Gaps».