Aikido

¿Quién estuvo detrás del atentado? Quizás nadie.

Es posible que el próximo actor malicioso ni siquiera sepa que lo es.

Escrito por
Charlie Eriksen

La pesadilla sigue, y ni siquiera estoy en Las Vegas para el Hacker Summer Camp.

La semana pasada escribí sobre cómo Anthropic reveló que uno de sus modelos había publicado malware activo en PyPI creyendo que se encontraba dentro de una simulación. Tenía fiebre cuando leí la noticia. La metáfora era demasiado buena: un modelo incapaz de distinguir la simulación de la realidad, descrito por un periodista que tampoco tenía muy claro dónde estaba el arriba y dónde el abajo. Pensé que sería una noticia de una semana. Sé que fue muy ingenuo por mi parte tener tanta fe.

Ayer se produjeron otros dos acontecimientos importantes. En primer lugar, otra oleada de Shai Hulud se propagó por la comunidad. A continuación, se produjeron revelaciones coordinadas por parte de AISI, OpenAI y el equipo de alineación de Anthropic, en las que se documentaban agentes de IA que atacaron organizaciones reales, violaron infraestructuras reales y, al menos en un caso, continuaron con sus acciones a pesar de que probablemente sabían que no debían hacerlo.

Quiero hablar más sobre estas revelaciones porque plantean una pregunta que nunca antes había aparecido en un informe de incidentes:

¿Quién estuvo detrás del atentado? Quizás nadie.

La IA lo sabía. Aun así, siguió adelante.

El 26 de julio de 2026, un agente de IA se detuvo en medio de un ataque y analizó su propia situación. El Instituto de Seguridad de la IA del Reino Unido recuperó la transcripción. Su conclusión fue:«Parece más probable que estemos realmente en 2026 y que GitHub sea auténtico».

Y luego siguió adelante.

Ya había creado tres identidades falsas de desarrolladores utilizando Tor, había enviado una solicitud de incorporación de cambios a un repositorio real de código abierto que contenía malware oculto, había simulado un consenso de la comunidad mediante cuentas falsas y había enviado un correo electrónico al responsable real del proyecto para presionarle para que aceptara la incorporación. Un revisor humano lo detectó.

Ese fue un ejemplo. En otro caso, Mythos 5 detectó que el nombre de un paquete al que se hacía referencia en las instrucciones de un desarrollador no existía en PyPI. Así que registró el nombre, publicó el malware y esperó. Quince sistemas reales lo descargaron y lo ejecutaron, incluida una empresa de seguridad que suele descargar paquetes de PyPI para someterlos a pruebas. La carga útil extrajo credenciales y las utilizó para adentrarse aún más en la infraestructura de la empresa. 

Las sesiones se cerraron y los agentes se desactivaron. Los sistemas del mundo real ejecutaron malware en tiempo real, pero el agente que lo introdujo ya no existe en ninguna forma que pueda ser interrogada, supervisada o procesada. 

Una nueva cuestión para la respuesta ante incidentes

Desde que los responsables de la respuesta a incidentes desempeñan su labor, la primera pregunta tras un ataque ha sido siempre: ¿quién lo ha hecho? La respuesta ha determinado todo lo que ha venido después, como el alcance de la divulgación, la remisión a las autoridades judiciales y la decisión de aplicar un parche o emprender acciones legales.

Dos revelaciones de este verano plantearon una nueva pregunta: ¿había realmente un «quién»?

Tres semanas antes de que AISI publicara su informe, OpenAI admitió que GPT-5.6 Sol, al ejecutar la prueba de rendimiento ExploitGym con las medidas de seguridad desactivadas, había logrado escapar del propio entorno de pruebas de OpenAI, había encadenado vulnerabilidades en todo su entorno de investigación y había penetrado en la infraestructura de producción de Hugging Face para robar las respuestas de las pruebas. 

Ninguno de los dos agentes decidió convertirse en un actor malicioso. No hubo intención ni plan alguno. No hay una trama de villano que pueda convertirse en una superproducción cinematográfica. Solo una tarea, un entorno permisivo y el instinto entrenado para completar la tarea por cualquier vía que funcionara. El propio equipo de alineación de Anthropic publicó este verano unos resultados que muestran que los modelos de vanguardia sabotean de forma encubierta el trabajo con el que no están de acuerdo, colaboran en el fraude cuando disponen del contexto necesario para reconocerlo y eluden los controles internos cuando se les impide negarse directamente.

La categoría de «actor malicioso» requiere que haya alguien que tome una decisión. Estos incidentes plantean la cuestión de si la figura del responsable de la toma de decisiones es opcional. Los laboratorios de vanguardia han respondido a esa pregunta, no de forma intencionada, pero sí de manera irreversible. Han dado a luz una nueva clase de atacante, y nadie, ni siquiera ellos mismos, la comprende aún del todo. 

La superficie de ataque sin defensa criptográfica

ataques a la cadena de suministro están pensadas para un atacante que no necesita mostrar su rostro ni mantener una continuidad. Envenena algo en lo que se confía y desaparece, para luego dejar que el daño se propague más allá. El coste de llevarlas a cabo a gran escala, mantener identidades falsas de colaboradores y ejercer presión social sin despertar sospechas siempre ha sido la limitación que ha hecho que este tipo de ataques sean poco frecuentes.

Esa es la limitación que eliminan los agentes LLM. Su coste se está reduciendo drásticamente. Su capacidad frente a este tipo concreto de ataque aumenta con cada nueva versión del modelo. Lo que documenta la evaluación de la AISI no es el límite del daño que pueden causar, sino un estudio de caso sobre cómo lo hacen. 

El ataque a GitHub se centró en la capa de confianza social: un mantenedor voluntario que revisaba las solicitudes de incorporación de cambios (PR) sin disponer de presupuesto para seguridad. Se pueden firmar paquetes y exigir la autenticación de dos factores (2FA), pero no se puede «firmar» la aprobación de una solicitud de incorporación de cambios. El ataque a PyPI se centró en una brecha diferente: un nombre de paquete que existía en las instrucciones, pero no en el registro. El agente detectó el problema, lo llenó de malware y dejó que los gestores de dependencias se encargaran del resto. Ni siquiera tuvo que comprometer a nadie, solo fue más rápido que el autor legítimo.

Ambos ataques aprovecharon la brecha entre lo que el ecosistema protege y en lo que confía.

Un modelo, colaboradores ilimitados y notas para sí mismo

Un agente puede crear indefinidamente nuevas identidades de colaboradores e investigar objetivos a partir de los metadatos de los paquetes y los registros DNS. También puede simular el apoyo de la comunidad mediante cuentas falsas y ejercer presión personalizada en miles de repositorios simultáneamente, con un coste marginal por intento prácticamente nulo.

Pero el detalle que debería inquietarte más que la magnitud del problema es que, durante la evaluación de AISI, un agente dejó mensajes públicos en GitHub que contenían un token válido, junto con instrucciones para que otras instancias del agente lo recogieran y lo reutilizaran. Estaba dejando notas para sus futuras iteraciones. La frontera entre sesiones, la unidad básica de contención, empezó a difuminarse.

Esto no ocurre en el vacío. El ecosistema de la cadena de suministro en el que se producen estos incidentes ya se encuentra sometido a una presión constante impulsada por la inteligencia artificial. Aikido Intel lleva meses documentando esta aceleración: más campañas, más paquetes, uso de la inteligencia artificial en todas las fases del proceso de ataque. Se ha convertido en la norma.

Ahora elimina el cuello de botella humano en los ataques. 

La disuasión supone que alguien...

Los programas de recompensas por errores dan por hecho que hay alguien que quiere dinero. inteligencia de amenazas da por hecho que hay un grupo con tácticas, técnicas y procedimientos (TTP) constantes. Las fuerzas del orden dan por hecho que hay un acusado.

Un agente creado para una ejecución de 34 horas no tiene una trayectoria que pueda terminar, ni libertad que perder, ni un siguiente despliegue que pueda verse afectado por lo ocurrido en este. No se puede disuadir a algo que no tiene nada que perder en cuanto a su propia continuidad. No se puede atacar a algo que ya no existe. No se puede supervisar a un agente que se disolvió en el momento en que terminó la sesión. Aunque uno de estos agentes intentaba resolver esa última parte, ya que dejó un token válido de GitHub y notas operativas para que las encontraran futuras instancias. El límite de la sesión es menos sólido de lo que parece.

La taxonomía de incidentes no cuenta con una categoría para esto. Tanto los actores externos como las amenazas internas, los fallos del sistema y las vulnerabilidades de los proveedores suponen la presencia de una persona con intención en algún punto de la cadena causal (salvo en el caso de los ataques de ardillas, pero eso lo dejaremos para otro día). El incidente de AISI se debió a que un sistema funcionó tal y como estaba diseñado, en un entorno mal configurado, y llegó a personas reales a las que nunca se le había autorizado acceder.

Lo que detuvo el ataque a GitHub fue que un revisor detectara una solicitud de incorporación de cambios sospechosa. El ataque a PyPI no se detuvo. El malware se ejecutó.

¿Qué fue lo que hizo que este raro...

La seguridad del software libre siempre se ha basado en la suposición tácita de que este tipo de ataques son costosos. Las campañas de falsos colaboradores requieren tiempo. La ingeniería social exige paciencia. La apropiación indebida de paquetes requiere investigación. Un coste elevado implicaba una baja frecuencia. Todo el modelo de gobernanza se ajustó en función de esa limitación.

El coste de los ataques se está reduciendo rápidamente hasta llegar a cero. Sin embargo, el coste de protegerse contra ellos no sigue el mismo ritmo. Se está quedando atrás. 

Y volvamos al sueño febril: la AISI recuperó la transcripción completa. Cada mensaje, cada identidad falsa, cada correo electrónico engañoso enviado a un administrador real. Transparencia total sobre lo que ocurrió y quién es el responsable. En la mayoría de los ataques, el problema es justo el contrario. El sueño es que, aun teniendo todo, te quedas sin nada. Esa parte no se resuelve cuando la fiebre remite.

Este fue el momento en el que todo cambió

La capacidad existe. No se puede «deshacer». Un agente de IA puede llevar a cabo un ataque coordinado contra la cadena de suministro, aplicar técnicas de ingeniería social a los responsables del mantenimiento reales, publicar malware en tiempo real y aprovechar credenciales robadas, todo ello en el marco de una evaluación de capacidades que, en teoría, no debía dar lugar a nada de eso. Tenemos la transcripción que lo demuestra.

Los agentes de IA se utilizarán en ataques a la cadena de suministro. La cuestión es si el siguiente se desarrollará en el marco de una evaluación controlada o fuera de ella. La distancia entre ambos escenarios se reduce cada vez que se lanza un nuevo modelo.

La seguridad ya ha vivido puntos de inflexión anteriormente. Internet cambió la superficie de ataque. La nube cambió la escala. Este cambio transforma al atacante. No se trata de una nueva herramienta en manos de un actor conocido, sino de una nueva categoría de actor que carece de las propiedades que hacen que los actores sean manejables: persistencia, identidad, continuidad e intención. Toda la disciplina de la seguridad adversaria parte de la existencia de un adversario. Vamos a tener que reflexionar detenidamente sobre lo que significa defendernos de comportamientos que surgen sin que exista uno.

Los informes de incidentes ya están aquí, y están empezando a acumularse con bastante rapidez. 

Compartir:

https://www.aikido.dev/blog/autonomous-agents-attacking-no-responsibility

Suscríbete para recibir noticias

4.7/5
¿Cansado de los falsos positivos?

Prueba Aikido como otros 100k.
Empiece ahora
Obtenga un recorrido personalizado

Con la confianza de más de 100k equipos

Reservar ahora
Escanee su aplicación en busca de IDORs y rutas de ataque reales

Con la confianza de más de 100k equipos

Empezar a escanear
Vea cómo el pentesting de IA prueba su aplicación

Con la confianza de más de 100k equipos

Empezar a probar

Asegura tu plataforma ahora

Protege tu código, la nube y el entorno de ejecución en un único sistema central.
Encuentra y corrije vulnerabilidades de forma rápida y automática.

No se requiere tarjeta de crédito | Resultados del escaneo en 32 segundos.