Un agente de IA pasó de buscar claves expuestas en GitHub a extraer datos de Azure Key Vault en solo cinco minutos. No ocurrió en un laboratorio ni en una prueba controlada: Microsoft Threat Intelligence lo observó en un ataque real contra uno de sus clientes y lo publicó el 5 de noviembre.
Informe: Microsoft Threat Intelligence, 5 de noviembre de 2026
Actividad observada: desde agosto de 2026
Caso extremo: 5 minutos de la búsqueda en GitHub a la exfiltración
Marco citado: ARTEX, programa ofensivo con agentes
La caza empezó en agosto de 2026. Microsoft vio a los atacantes lanzar grandes volúmenes de consultas contra el buscador de GitHub, combinando el nombre de la empresa objetivo con palabras típicas de un secreto y con nombres de servicios en la nube o de otros proveedores de IA.
El trabajo pesado lo hace un marco ofensivo con agentes: Microsoft pone como ejemplo a ARTEX, un programa donde el operador fija la meta y los agentes encadenan el reconocimiento, el análisis de lo encontrado y el ataque siguiente, con muy poca mano humana en el teclado. El mismo ARTEX dejó 1.465 consolas expuestas en internet, contadas por Censys: copias funcionales sobran para quien quiera usarlo.
GitGuardian, la empresa que lleva años rastreando secretos en el código público, pone el tamaño del campo de caza: solo en 2025 aparecieron 28,65 millones de secretos nuevos escritos en código, y las fugas de credenciales de servicios de IA crecieron un 81 % ese año. El material para los agentes no escasea.
Las consultas no buscan cualquier clave. Los agentes mostraron una fijación repetida por las credenciales que abren servicios de IA: claves API de los grandes proveedores y aplicaciones OAuth con acceso a Foundry Tools, la plataforma de IA de Azure. Una llave así vale doble: abre la nube de la víctima y, en algunos casos, alimenta el propio ataque.
De la búsqueda en GitHub a la bóveda, en cinco minutos
En el caso más rápido, el agente buscó los secretos de cliente de una aplicación en GitHub, obtuvo un token de la aplicación OAuth de esa misma organización y con esa identidad enumeró los recursos de la nube hasta llegar a la bóveda de claves.
De esa búsqueda a la exfiltración de datos de Azure Key Vault pasaron cinco minutos. Microsoft no detalla los pasos intermedios ni qué datos salieron en ese caso: la cifra cubre el tramo completo, de la primera consulta al robo.
Otro frente arrancó el 28 de octubre, con credenciales válidas filtradas o robadas. El marco inició sesión como entidad de servicio —la identidad con la que una aplicación se autentica— en decenas de aplicaciones repartidas por varios inquilinos de Microsoft Entra ID, el sistema de identidad de Azure y Microsoft 365.
En algunos casos, la credencial tomada era de una aplicación multiinquilino y estaba comprometida en origen, en la empresa que la desarrolló: una sola llave abrió las puertas de los clientes que usan esa aplicación.
Dentro, el agente iba directo a las operaciones que devuelven credenciales: claves de cuentas de almacenamiento, ajustes de App Service, cadenas de conexión y credenciales de publicación, conexiones de aprendizaje automático y credenciales de usuario de Kubernetes. Con esas piezas entró en SharePoint y OneDrive, descargó archivos, revisó elementos de correo y mapeó suscripciones, permisos y despliegues de modelos de IA.
Se equivoca, se corrige y vuelve a entrar
La corrección en marcha es la parte que quita el sueño. Cuando una llamada a la API de Azure fallaba por llevar una versión vieja, el agente cambiaba el método o la versión y reintentaba hasta recibir la respuesta válida.
Microsoft bajó esa conducta a segundos concretos: unos 28 segundos para corregir la consulta de metadatos de secretos de una bóveda, 60 para las reglas del cortafuegos de una base de datos de Azure SQL y 80 para una consulta de Application Insights. Ningún humano teclea tan rápido ni tan seguido.
Los agentes también buscaron secretos guardados dentro de Azure DevOps y usaron Run Command, la función que ejecuta scripts dentro de las máquinas virtuales de Azure: con ese acceso se leen credenciales almacenadas en la propia máquina, se salta a otras identidades o se deja código listo para volver.
El error caro sería creer que basta con borrar el archivo. Una credencial expuesta sigue viva hasta que alguien la revoca o la rota: borrar el código no la invalida, y quedan copias en el historial de cambios, en cachés y en archivos repartidos por otros sistemas. La instrucción de Microsoft es tratar toda clave que estuvo pública como comprometida.
La salida pasa por matar el secreto longevo: identidades administradas para que las aplicaciones se autentiquen sin claves escritas en el código, mínimo privilegio para cada entidad de servicio y escaneo continuo de los repositorios. Para cazar agentes, Microsoft probó incluso señuelos y superficies falsas que les hacen perder tiempo y presupuesto: en sus pruebas, ese ruido bajó el tráfico que llegaba a los activos reales.
De la autoría no hay nombre: Microsoft no atribuye la actividad a ningún grupo ni dice cuántas organizaciones cayeron. GitGuardian fechó el retiro de ARTEX de GitHub el 8 de octubre, y las sesiones con credenciales robadas empezaron el 28: tres semanas después de desaparecer del repositorio, la herramienta seguía trabajando.
Fuente: Microsoft
