Agentes de IA robaron credenciales en menos de seis horas
Google Threat Intelligence Group (GTIG) documentó el 8 de septiembre de 2026 una campaña observada durante el segundo trimestre en la que un marco multiagente robó miles de credenciales de terceros en menos de seis horas. Un actor presuntamente motivado por dinero lo desplegó en la infraestructura de nube de una organización que ya había sido comprometida.
El informe publicado ese día confirma que los agentes automatizaron la exploración de vulnerabilidades, la recolección de credenciales, la resolución de errores y la rotación de direcciones IP. No demuestra que la IA consiguiera el acceso inicial ni que toda la intrusión fuera autónoma, pero sí que redujo a horas la planificación, construcción y ejecución de una campaña masiva.
La cuenta de seis horas empezó después del acceso a la nube
La secuencia conocida comienza con un recurso de nube ya comprometido. Desde allí, el atacante combinó un asistente de programación con un prompt y archivos de instrucciones en Markdown que servían como guías operativas para el marco autónomo multiagente.
La ventana inferior a seis horas abarcó la planificación, la construcción y la ejecución de la campaña de recolección. No debe interpretarse como el tiempo total transcurrido desde el primer acceso a la organización, porque GTIG no publicó cuándo ni cómo se produjo esa intrusión previa.
Operar desde la nube de la víctima también permitió dirigir el tráfico a través de direcciones IP legítimas. Los agentes administraron la cadena de exploración, resolvieron problemas durante la ejecución y cambiaron las direcciones de salida sin intervención manual en esos pasos.
La IA ejecutó tareas intermedias sin sustituir al atacante
La reconstrucción de SiliconANGLE coincide en la obtención de miles de credenciales, el uso de instrucciones operativas y la probable motivación financiera del actor. También recoge una limitación decisiva: GTIG no había observado todavía cadenas de ataque completamente autónomas desplegadas contra objetivos reales.
En este caso, una persona estableció el objetivo y proporcionó los componentes e instrucciones. La autonomía apareció dentro del flujo: el sistema pudo mantener la exploración, responder a fallos y rotar IP sin que el operador tuviera que corregir manualmente cada paso.
La diferencia operativa no es la desaparición del atacante, sino la reducción de su latencia. Un solo operador pudo sostener una campaña a una velocidad y escala que normalmente requerirían más coordinación, mientras el equipo defensor disponía de menos tiempo para distinguir el abuso y revocar los accesos.
Los otros robos del informe fueron incidentes distintos
El mismo informe de GTIG describe operaciones en las que se sustrajeron modelos propietarios, código fuente, prompts, habilidades y otros activos relacionados con IA. Esos casos fueron investigaciones de extorsión por robo de datos y no etapas atribuidas a la campaña de credenciales ejecutada en menos de seis horas.
GTIG también vinculó provisionalmente a UNC6508 con el despliegue de modelos de pesos abiertos en entornos de nube comprometidos. Esa actividad permitía aprovechar el cómputo de las víctimas y evitar la supervisión de las API comerciales, pero correspondía a otro actor y a otra operación.
Separar los casos evita atribuir al ataque de seis horas consecuencias que la investigación no le asigna. Su alcance confirmado es más preciso: una infraestructura de nube comprometida se convirtió en plataforma para una recolección automatizada de credenciales de terceros.
Cuatro controles cortan la ruta entre nube, código y secretos
Para una empresa pequeña, la prioridad derivada del caso es impedir que una sola identidad abra simultáneamente la nube, los repositorios y los sistemas de despliegue. Las cuentas utilizadas por agentes deben tratarse como identidades de máquina con propietario, finalidad y permisos delimitados.
- Cuentas de nube: reemplazar claves permanentes por credenciales de corta duración, separar las funciones administrativas y proteger las cuentas humanas con autenticación multifactor resistente al phishing.
- Repositorios: restringir cada token a los proyectos y operaciones imprescindibles, proteger las ramas principales y bloquear secretos antes de que lleguen a commits o artefactos de compilación.
- Secretos: centralizarlos en un gestor, impedir que aparezcan en prompts o registros y limitar qué cargas de trabajo pueden leerlos.
- Agentes y asistentes: habilitar herramientas por proyecto, separar desarrollo de producción y exigir aprobación humana para desplegar, modificar permisos o consultar valores sensibles.
Esta separación reduce el radio de impacto y facilita la contención. Un asistente puede consultar código sin recibir credenciales de producción, preparar un cambio sin fusionarlo y proponer un comando sin ejecutarlo; un token breve y específico puede revocarse sin paralizar todas las integraciones.
La respuesta ya no puede esperar al día siguiente
La cobertura técnica de ITPro corroboró que los agentes gestionaron la exploración, la corrección de fallos y la rotación de IP, mientras la infraestructura comprometida daba al tráfico direcciones de salida legítimas. Una alerta que permanece en una cola hasta la jornada siguiente puede sobrevivir más tiempo que toda la campaña documentada.
- Invalidar sesiones, tokens y claves asociados con la identidad sospechosa, además de aislar los recursos desde los que sale la actividad.
- Preservar los registros de identidad, nube, repositorios, CI/CD y herramientas de IA antes de que roten.
- Buscar cuentas nuevas, cambios de permisos, descargas de código, lecturas de secretos y consumo de cómputo inesperado.
- Rotar las credenciales dependientes y restaurar los servicios solo después de cerrar la vía de acceso.
Cambiar una contraseña no basta si permanecen activos tokens derivados, sesiones o claves de servicio. Un equipo sin vigilancia permanente puede reducir la demora con alertas dirigidas a una persona responsable y un procedimiento de revocación disponible fuera del horario habitual.
La identidad del actor y la entrada inicial siguen sin conocerse
El informe no identifica públicamente al actor, a la organización cuya nube fue comprometida, al asistente de programación utilizado ni a las víctimas de las credenciales. Tampoco detalla la vía de acceso inicial, la secuencia completa de comandos o un conjunto exhaustivo de indicadores que permita reconstruir cada minuto.
El estado confirmado de la historia es más acotado: un atacante humano dirigió una operación que utilizó agentes para obtener miles de credenciales en menos de seis horas después de comprometer un recurso de nube. Hasta que aparezcan más datos técnicos, el caso demuestra que los permisos deben limitar el alcance antes del incidente y que la revocación tiene que funcionar en horas, no en días.
Lee también:
Suscríbete a nuestro boletín
Reciba las últimas noticias sobre Web3, IA y criptomonedas directamente en su bandeja de entrada.