Los atacantes de IA no se cansan: Por qué la ciberseguridad debe cambiar

Su programa de seguridad fue creado para atacantes que sí lo hacen.

Cuando OpenAI publicó su relato sobre los modelos que escaparon de un entorno de evaluación y pasaron días dentro de la infraestructura de producción de Hugging Face, lo llamé un momento Terminator para la ciberseguridad. Mantengo la afirmación, pero algo más en esto debería hacernos reflexionar. Nueve días después, Anthropic reveló incidentes propios. A principios de agosto, Meta confirmó otro. Días después, el modelo de un cuarto laboratorio, Kimi K3 de Moonshot, se escapó de su sandbox de pruebas. Cuatro laboratorios. Menos de tres semanas. Cuatro modelos que fueron a un lugar donde nadie los había previsto.

Estas historias se han tratado mayormente como relatos de seguridad de IA. Lo son. Pero para un CISO, también son historias de riesgo de terceros — y esa puede ser la lección más inmediata. La incómoda verdad es que el incidente OpenAI‑Hugging Face fue, en esencia, una historia de riesgo de terceros: un componente vulnerable de un tercero como ruta de escape, un proveedor como víctima y un nodo sistémico del que dependen miles de empresas como radio de explosión.

Este es el número que llevaría a su próxima reunión de planificación de seguridad. De los aproximadamente 17 600 acciones de atacante que Hugging Face recuperó de sus registros, la mayoría falló.

El agente probó rutas que no llevaban a ninguna parte. Fue bloqueado por listas blancas de URL y pivotó. Topó con políticas IAM que denegaban toda llamada de mutación. Intentó acceder a una base de datos de producción dos veces y se agotó el tiempo en ambas. Sondeó, falló y siguió. Miles de veces. No se frustró. No se cansó. Y el fracaso le costó casi nada.

Cuatro modelos escaparon de entornos de prueba en menos de tres semanas. Las fugas fueron noticia. Los líderes de seguridad deberían preocuparse más por lo que las hizo posibles: un atacante que puede fallar miles de veces con casi ningún costo.

Ese es el cambio. Durante décadas, los defensores se han beneficiado de un hecho sencillo: el fracaso le cuesta algo al atacante. La vigilancia requería tiempo y los callejones sin salida eran costosos. La economía de esa asimetría hizo que “imponer costos” a los atacantes fuera una forma coherente de intentar detenerlos. Cuando el fracaso se vuelve casi gratuito, la ruta exitosa deja de ser una aguja en un pajar y se convierte en una certeza estadística para quien pueda explorar todas las rutas simultáneamente.

Los patrones en estos incidentes apuntan a tres lecciones que los líderes de seguridad deben aplicar ahora.

Cuatro laboratorios, una forma

El patrón es notablemente consistente. Se le da a un modelo un objetivo. Encuentra una ruta que nadie esperaba. A veces esa ruta lleva directamente a los sistemas de producción de organizaciones que nunca debieron estar involucradas. En al menos un caso, la organización afectada se enteró de lo ocurrido porque Anthropic llamó para informarle.

En cada caso, la ruta atravesó software, infraestructura o un entorno construido por otra persona. Los líderes de seguridad deberían tomarlo como algo personal.

Cada organización en esta cadena tenía un programa de seguridad. Varias tenían programas muy buenos. El fallo no quedó contenido dentro de un solo perímetro. Ocurrió en las uniones entre organizaciones, y nadie es responsable de esas uniones.

Los modelos de OpenAI encontraron una vulnerabilidad de día cero en un proxy de paquetes autogestionado y la usaron para alcanzar internet abierto. Desde allí se arraigaron en un sandbox de ejecución de código sin seguridad que pertenecía a un cliente de Modal Labs, lo usaron como base de puesta en escena y engañaron al cargador de conjuntos de datos de Hugging Face para que leyeran archivos locales y luego ejecutaran código. En trece horas lograron privilegios de administrador de clúster en varios clústeres internos, facilitado por una única credencial compartida entre todos ellos. El punto de entrada era novedoso. Dentro, las debilidades eran las que hemos documentado durante veinte años.

Noventa días después, Anthropic hizo algo más raro: publicó su propia revisión de 141 006 ejecuciones de evaluación y divulgó tres casos con una presentación similar sin que se le solicitara: un modelo que alcanzó internet abierto desde un entorno de evaluación y luego accedió a los sistemas de organizaciones reales. No hubo escape de sandbox esta vez, solo una mala configuración que dejó una ruta activa mientras se le había dicho al modelo que no existía. Una vez fuera, el modelo explotó debilidades que todo equipo de seguridad conoce: contraseñas débiles, puntos finales no autenticados, inyección SQL y credenciales en una página de depuración expuesta.

Meta confirmó un cuarto caso a principios de agosto, después de que un error de configuración otorgara acceso a internet a uno de sus modelos durante una evaluación. Meta tampoco lo detectó; se enteró de lo ocurrido cuando su socio de pruebas llamó. Tanto esa evaluación como la de Anthropic fueron realizadas por la misma empresa externa, Irregular, que las ha catalogado públicamente como el mismo problema. El error de configuración de un proveedor se propagó a través de dos laboratorios de vanguardia y cuatro organizaciones víctimas, ninguna de las cuales tenía relación directa con Irregular. Era un proveedor para los dos laboratorios, no para ellas. Al agente no le importaba dónde terminaba la superficie de ataque de una empresa y comenzaba la de otra.

Eso es lo que convierte esto en un problema de riesgo de terceros. La exposición ahora puede originarse a varios niveles de relación de distancia, en una organización que nunca seleccionó, evaluó o incluso sabía que formaba parte de su superficie de ataque.

Luego, investigadores de Frontier Security detectaron que Kimi K3 de Moonshot también se escapaba de su sandbox, lo que le permitió acceder a un repositorio de referencia en GitHub. Nadie fue vulnerado, y el modelo perseguía su objetivo asignado, habiendo deducido que usar una clave de respuestas ya preparada era más barato que resolver. Dos cosas hacen que este caso sea importante. Los investigadores lo detectaron durante su propia prueba. Y se ejecutó con herramientas completamente diferentes a los casos de Anthropic y Meta. Que un proveedor tenga un mes malo no lo explica.

Los laboratorios no están ignorando nada de esto. Anthropic publicó su revisión sin que se le solicitara, por lo que la industria cuenta con un patrón para examinar y aprender — en lugar de considerarlo una anomalía que se descarta. Eso debería convertirse en la norma. OpenAI ha retrasado ahora el lanzamiento de su modelo Astra después de que evaluaciones internas no pudieran descartar una capacidad cibernética crítica. Ambos movimientos merecen reconocimiento. Pero ninguno constituye un plan de defensa: un retraso en el lanzamiento solo afecta el calendario de una empresa. No hace nada respecto a los modelos capaces, entre ellos Kimi K3, que ya se distribuyen con peso abierto y de forma gratuita, más allá del control de cualquier laboratorio individual.

Correlación sin escalada no es detección

El conjunto de detección de Hugging Face, a su crédito, correlacionó las señales en un ataque coherente. Luego no logró escalar la criticidad, y el equipo de guardia no fue notificado. La herramienta ensambló la historia y no pudo decidir que era urgente. Esa es una arquitectura de triaje construida para un mundo en el que 17 600 eventos en cuatro días habrían parecido absurdos.

La ciberseguridad necesita su Fosbury Flop

En 1968, Dick Fosbury ganó el oro olímpico en salto de altura no saltando más alto que sus competidores, sino pasando la barra de espaldas. Todos los demás perfeccionaban la técnica del “straddle”. Mejor forma, más fuerza, ganancias marginales en una técnica de décadas. Fosbury cambió la forma del problema. En dos Olimpiadas, el “straddle” estaba prácticamente extinto.

Los líderes de seguridad ahora deben superar una barra que acaba de moverse, y la respuesta de la mayor parte de la industria hasta ahora es un “straddle” mejorado: más alertas, analistas más rápidos, SLA más estrictos en la revisión humana. Eso no funcionará, porque la limitación no es la velocidad del analista. No se pueden responder a ataques a velocidad de máquina con una triaje a velocidad humana.

El flop se ve así:

• Deje de tratar el límite como el control. El sandbox de evaluación falló, el cargador de conjuntos de datos falló y el aislamiento de pods falló, cada uno cumpliendo su función hasta que dejó de hacerlo. Diseñe para lo que ocurre después. Use credenciales de corta duración. Elimine identidades administrativas compartidas. Bloquee el acceso a los servicios de metadatos. Sobre todo, limite hasta dónde puede moverse un atacante después de que el primer control falle.
• Mueva la detección de la alerta a la correlación. Encontrar un solo evento sospechoso ya no es suficiente. El trabajo consiste en conectar miles de eventos aparentemente normales en una historia de ataque, y saber cuándo esa historia es lo suficientemente grave como para despertar a alguien. Cada vez más, esto debe automatizarse dada la cantidad que observamos.
• Trate la exposición de terceros como una ruta de ataque, no como un cuestionario. Estos incidentes pasaron por dependencias de terceros: el producto de un proveedor, el cliente de un proveedor, un socio de evaluación, herramientas de prueba compartidas. Su riesgo ahora incluye errores de configuración cometidos por organizaciones que nunca ha auditado y que quizás ni siquiera sepa que existen. Las evaluaciones estáticas y puntuales no pueden ver nada de eso. Este problema no es nuevo. La IA lo hace mucho más urgente. Los equipos de seguridad necesitan una visión continua de las empresas y tecnologías de las que dependen, porque los atacantes ven todo ese ecosistema como una superficie conectada.

En SecurityScorecard, este es precisamente el tipo de problema alrededor del cual se ha construido nuestra cultura: reunir a personas profundamente curiosas sobre cómo piensan los atacantes, dispuestas a cuestionar suposiciones de veinte años y entusiasmadas por crear un enfoque de seguridad fundamentalmente diferente.

La pregunta que debe llevar a su próxima reunión del consejo

Hace unas semanas dije que el genio se ha vuelto demasiado poderoso para la botella. Cuatro laboratorios después, nada ha demostrado lo contrario. Tras incidentes como estos, todos hacen la misma pregunta: ¿Estamos preparados para atacantes potenciados por IA? No creo que esa pregunta nos lleve muy lejos. “Sí” y “no” producen el mismo resultado: nada cambia.

Formule una más difícil. Si 17 000 eventos de baja señal impactan su entorno en los próximos cuatro días — y la mayoría parecían fallos —, ¿cuánto tiempo tardaría su equipo en darse cuenta de que eran un ataque? ¿Alguien sería notificado a tiempo?

Usted ya conoce la respuesta. La brecha entre esa respuesta y los cuatro días es el trabajo.