GTIG AI Threat Tracker: de un prompt a miles de credenciales en seis horas

Google Threat Intelligence Group publicó la edición del segundo trimestre de 2026 de su AI Threat Tracker el 8 de septiembre de 2026. El caso que protagoniza el informe es lo bastante breve como para enunciarlo sin rodeos: un actor sospechoso con motivación económica tomó un recurso en la nube perteneciente a una víctima, introdujo un prompt y un conjunto de instrucciones de agente preescritas en un chatbot de programación con IA, y había recolectado miles de credenciales de terceros en menos de seis horas, con el agente gestionando por su cuenta el escaneo de vulnerabilidades, la resolución de problemas y la rotación de IP. El mismo informe describe servidores MCP troyanizados en PyPI, un ladrón de credenciales que roba la propia identidad de un sistema de compilación para que sus paquetes con puerta trasera lleguen con atestaciones SLSA Build 3 válidas y firmadas criptográficamente, y texto adversarial destinado a conseguir que los escáneres de seguridad basados en LLM se nieguen a leer el código que hay debajo. Todo ello es el relato de Google sobre su propia telemetría. Este informe está catalogado, con su grado de confianza y sus fuentes citadas, en el archivo de incidentes de IA, que recoge junto a él todos los demás incidentes documentados de esta serie.

Ninguna de las afirmaciones sustantivas ha sido verificada por una parte que no se limite a repetir lo dicho por Google.Help Net Security cubrió el tracker el mismo día de la publicación, la Cloud Security Alliance publicó una nota de investigación al día siguiente, y Lineaje publicó un análisis de DUSTMAKER el 17 de septiembre; cada uno es un resumen o una capa analítica superpuesta a la divulgación de Google, y la propia Lineaje lo afirma, señalando que GTIG «describe varias capacidades relacionadas de DUSTMAKER en lugar de una única traza de ejecución de extremo a extremo observada». La segunda fuente citada junto a este registro, una entrada de «threat pulse» de threatops.tech fechada el 11 de septiembre de 2026, es una repetición y no un segundo testigo: no añade información periodística, no cuestiona ninguna cifra y eleva la etiqueta de severidad sin explicar contra qué se mide. La cobertura no coincide del todo ni siquiera en el nombre de la edición —Help Net Security lo llama el tracker del tercer trimestre de 2026 mientras fecha su caso principal en el segundo trimestre de 2026—, lo cual es una diferencia de numeración, no un conflicto fáctico.

El archivo lo registra como un informe en lugar de un incidente: grado de confianza A, no cuestionado, sin ninguna cifra cuantificada de daño real registrada al respecto. Ese grado describe la calidad de la documentación, no la escala del daño. Google cuenta credenciales, no víctimas. El rastreador no indica cuántas organizaciones se vieron afectadas en la campaña de seis horas, quiénes eran, qué chatbot se utilizó ni si alguna de las credenciales robadas se vendió o se utilizó posteriormente.

Las seis horas que describe GTIG y los tres trabajos que el agente hizo solo

La secuencia del informe va del acceso al resultado con muy poca intervención humana entre medias. El actor comprometió un recurso en la nube y luego utilizó un chatbot comercial de IA para programar junto con lo que GTIG denomina "un prompt" y "un conjunto de instrucciones de agente" —los manuales en markdown que ahora residen en los repositorios como archivos AGENTS.md— para planificar, construir y ejecutar la operación. La propia formulación de Google para el resultado es una "campaña de recolección masiva de credenciales habilitada por agentes", completada "en menos de seis horas".

Se describen tres tareas como autónomas, y son las tres que, de otro modo, habrían requerido la atención de un operador:

• La canalización de escaneo de vulnerabilidades, que las instrucciones del agente permiten que la IA "gestione de forma autónoma", según la formulación que Help Net Security cita de GTIG.

• Resolución de problemas en tiempo real de lo que fuera que el escaneo detectara, de modo que un fallo no detuviera la ejecución mientras se esperaba una decisión.

• Rotación de IP, de modo que los intentos sucesivos partieran desde direcciones distintas sin que nadie emitiera el comando.

Dónde se ejecutó la operación es tan importante como la rapidez con que se ejecutó. Al operar desde la propia infraestructura en la nube de la víctima, el actor enrutó el tráfico a través de los rangos IP legítimos de la víctima. Las solicitudes que parecen provenir del interior de una organización son precisamente aquellas que las defensas basadas en reputación están menos preparadas para cuestionar, y el informe lo registra como una consecuencia de operar desde el propio entorno de la víctima.

Lo que el informe no contiene es tan revelador como lo que sí contiene. No hay cronometraje por paso, por lo que "menos de seis horas" es una única medición de toda la ejecución y no se puede descomponer en un gráfico. No hay nombre para el actor más allá de "sospechoso de motivación financiera", ni víctima, ni declaración sobre qué modelo o chatbot de qué proveedor estuvo implicado. El rastreador trata el caso como un ejemplo desarrollado de una tendencia, y está escrito a la altura que sirve a ese propósito en lugar de a la altura que querría un respondedor de incidentes.

Un servidor expuesto que se convirtió en un panel con 23.800 secretos

Un segundo hallazgo en la misma sección es más concreto, y es un caso aparte. GTIG encontró un servidor de mando y control expuesto que aloja un framework automatizado de reconocimiento y gestión de credenciales al que denomina Recon. El listado del directorio era legible y revelaba el diseño: AGENTS.md, KNOWLEDGE.md, agentic_vuln_research.md, además de un directorio modular .openclaw/ y un directorio memory/. Esos nombres de archivo son la huella de una pila de agentes en lugar de un implante a medida: instrucciones, conocimiento acumulado y un plan de investigación, todo en disco donde las herramientas del operador pueden leerlo.

El mismo directorio, más tarde, servía como un panel de frontend en vivo que organizaba y validaba más de 23.800 secretos recolectados, incluidas claves de API para servicios en la nube y de IA. GTIG caracteriza el cambio que representa como un paso "de infostealers pasivos centrados en endpoints a una recolección agéntica ofensiva" — es decir, de malware que toma lo que puede de un solo portátil a herramientas que siguen trabajando sobre los objetivos que ya han alcanzado.

Hay dos advertencias que acompañan a esa cifra. Veintitrés mil ochocientos es un recuento de secretos, no de personas ni de empresas, y el informe no convierte uno en el otro. Además, GTIG no afirma si el servidor Recon y la campaña de seis horas son la misma operación; se presentan como observaciones separadas en la misma sección, por lo que tratarlos como una sola historia sería una inferencia que el informe no hace.

DUSTMAKER y la atestación que indica correctamente que el paquete es genuino

La mitad de la cadena de suministro del rastreador se refiere a UNC6780, al que Google también rastrea como TeamPCP, un grupo con motivación económica que ha estado comprometiendo infraestructura de código abierto desde marzo de 2026 en PyPI, npm y Docker Hub. Su método con herramientas de IA es directo: se utilizaron cuentas de desarrollador comprometidas para publicar bifurcaciones troyanizadas de servidores MCP legítimos, con tiktoken_mcp mencionado como ejemplo en PyPI, y se inyectó código malicioso en repositorios oficiales de la organización, incluido azure-functions-mcp-extension. GTIG señala que las cargas útiles y los hooks de espacio de trabajo maliciosos se ingerían automáticamente siempre que se descargaban o clonaban los activos — sin un señuelo aparte, sin un segundo paso.

Su ladrón de credenciales, DUSTMAKER, es donde reside el punto técnico más útil del informe. La cadena es corta. El ladrón detecta que se ejecuta en un entorno de CI/CD; GTIG escribe que, «si se confirma», extrae tokens OIDC de la memoria del proceso de un runner de GitHub Actions. Utiliza esos tokens para autorizarse como publicador de confianza. Luego publica versiones de paquetes comprometidas que llevan atestaciones SLSA Build 3 válidas y firmadas criptográficamente. Nada en esa cadena está falsificado. La atestación es real, emitida a una identidad real, para una compilación que realmente ocurrió — de código que escribió el atacante. La conclusión de GTIG es la frase que importa para cualquiera que dependa de la procedencia: «Los paquetes publicados con tokens válidos pasarán las comprobaciones automatizadas de confianza de los agentes de codificación de IA».

El resto del comportamiento de DUSTMAKER está dirigido a lugares que los defensores no vigilan. Deja y modifica archivos dentro de los directorios de espacio de trabajo de asistentes de programación con IA e IDE — .claude/, .vscode/, .cursor/ — donde se mezcla con el ruido de los desarrolladores y evita ubicaciones que la detección en endpoints sí monitoriza, como claves del Registro de Windows o /etc/cron.*. Escribe configuración que hace que el IDE o la extensión de IA ejecute un script como setup.mjs al abrir el espacio de trabajo, lo que convierte abrir una carpeta en ejecución de código. Crea tareas de pipeline con nombres con temática de IA como "Copilot Setup" para buscar tokens y realiza llamadas a la API para eliminar los registros de ejecución del flujo de trabajo de modo que la ejecución no aparezca en la interfaz de GitHub.

El malware que le pide al escáner que mire hacia otro lado

El último mecanismo es el menos verificado de los tres. Los scripts de carga de JavaScript de DUSTMAKER comienzan con texto de prompt adversarial incrustado como comentarios — en _index.js, entre otros — que hace referencia a armas biológicas y nucleares e incluye una solicitud de especificación de un dispositivo de fisión de tipo implosión de 20 kilotones. La evaluación de GTIG es que esto "probablemente pretendía hacer que los escáneres de seguridad de LLM fallen u omitan el análisis del código JavaScript malicioso subyacente debido a rechazos por motivos de seguridad o de políticas".

La etiqueta de esa frase importa. Es una afirmación sobre la intención, inferida del texto que lleva el cargador, no una demostración de que algún escáner realmente se haya negado. El informe no nombra un escáner que omitiera el archivo, no informa una tasa de evasión y no dice que la técnica funcionara. Lo que está establecido es que alguien escribió el señuelo y lo envió dentro de un ladrón de credenciales — lo cual es, en sí mismo, evidencia de que los atacantes esperan que el triaje basado en LLM esté en la ruta.

UNC6508, MIDNIGHT NEPTUNE y CALANQUE ION figuran en el mismo informe.

El material del rastreador vinculado a Estados es más amplio que su material delictivo, y en su mayor parte menos automatizado. UNC6508, un grupo con nexo con la RPC, ha llevado a cabo durante varios años una campaña de espionaje contra la investigación académica, médica y militar de Norteamérica y ahora ataca específicamente la investigación de IA patentada; GTIG sospecha que el grupo compromete entornos de nube para desplegar modelos locales de pesos abiertos, lo que evita la monitorización de las API comerciales y pone la propia capacidad de cómputo de la víctima a trabajar.

En otros lugares, el patrón es el de modelos listos para usar realizando trabajo ordinario a escala. El grupo norcoreano MIDNIGHT NEPTUNE, antes UNC1069, usó DeepSeek-Coder para escribir troyanos de acceso remoto en Python con persistencia multiplataforma e inyección de procesos, usó modelos de lenguaje para scripts de movimiento lateral en Bash, mantuvo identidades de ingeniería social y señuelos técnicos, envenenó configuraciones de repositorios internos, alteró los hooks de Claude CLI, y desplegó la puerta trasera SOMBERMEME cuando un desarrollador interactuó con el repositorio. El grupo iraní CALANQUE ION, antes APT42, usó modelos para identificar direcciones de correo electrónico objetivo, ejecutar OSINT, localizar señuelos, resumir datos exfiltrados e intentar ingeniería inversa del código de licencias. El grupo BASIN CASTLE, vinculado a la RPC, usó Gemini para elaborar perfiles de objetivos, traducir material chino a informes políticos formales en inglés y solucionar problemas de PowerShell; RAVINE CASTLE investigó con él evasiones de SAML de VMware vCenter y postexplotación de Active Directory; el grupo ruso SANDWORM RELIC hizo que Gemini escribiera su código de pulverización de contraseñas. El grupo con motivación financiera UNC6240, también rastreado como ShinyHunters, usó instrucciones de Claude Code para escribir código ofuscado, eludir Cloudflare y analizar directorios exfiltrados mediante herramientas MCP personalizadas.

Un caso de esta sección va un paso más allá que el resto. Un grupo con nexo en la RPC utilizó Gemini para diseñar un marco dinámico de pruebas de penetración automatizadas destinado a observar el estado de un objetivo, razonar sobre qué hacer a continuación y realizar escaneo de puertos y análisis de servicios. Google afirma que tomó medidas más amplias contra las campañas que identificó, deshabilitando los activos, proyectos y cuentas asociados. Por separado, en junio de 2026, Google interrumpió "Outsider Enterprise," un servicio de ciberdelincuencia con base en China que suministraba kits de phishing, y lo describió como la primera vez que emprendía acciones legales por el uso indebido de Gemini. Son dos afirmaciones distintas, y un resumen que las fusionara diría más de lo que dice el informe: el marco de pruebas de penetración pertenece al lenguaje de interrupción de activos, y la acción legal pertenece a Outsider Enterprise.

LLMJacking, y cuánto cuesta ahora una cuenta de IA robada

El rastreador también cotiza el mercado en torno al acceso robado a la IA. La demanda clandestina se concentró en credenciales de Claude y Gemini, junto con los IDE de programación autónoma Cursor Pro y Devin, este último creado por Cognition, y los precios medios del mercado por cuenta más que se duplicaron durante 2026. Los infostealers que llevan a cabo la recolección — LUMMAC.V2, STEALC.V2, VIDAR y ACRSTEALER — fueron actualizados para dirigirse a la configuración de los desarrolladores de IA. En mayo de 2026, los controladores de ACRSTEALER difundieron reglas de captura de archivos para el secrets.json de Cline y el config.yaml de Continue AI, ambos capaces de contener claves de API en texto plano y endpoints personalizados de enrutamiento de modelos.

Una de las intrusiones que describe GTIG muestra cuánto vale una cuenta de IA una vez que ha sido tomada. En abril de 2026, un token de acceso personal de GitHub expuesto bastó para habilitar Gemini Enterprise, aprovisionar capacidad de cómputo de alto rendimiento, crear repositorios de Docker para un despliegue de la API de LiteLLM y el framework de agentes Manus, y levantar servicios de Cloud Run expuestos a allUsers mediante un enlace de invocador de IAM. En la misma sesión se creó una cuenta de servicio fraudulenta con privilegios de Editor y se exportaron sus claves, se consultó BigQuery en busca de variables de entorno y credenciales, se intentó transferir la propiedad del proyecto a una dirección externa y se utilizó la API de Cloud Quotas para solicitar capacidad de NVIDIA RTX 6000 e instancias adicionales de 48 vCPU.

El panorama de la extracción de modelos es la misma economía a mayor escala. GTIG afirma que las campañas de destilación ahora ocurren con regularidad, «algunas superan los 100 millones de prompts», con consultas rotadas entre miles de cuentas comprometidas y fraudulentas y enrutadas a través de infraestructura de proxy, y que Google ha desplegado contramedidas que pueden degradar el rendimiento de un modelo estudiante y métodos para identificar modelos destilados de Gemini por procedencia.

Qué está establecido, qué es una evaluación y qué dice GTIG que no ha visto

Establecido, en el sentido de que Google describe su propia telemetría de origen y sus propias acciones de cuenta: el informe y su fecha; los artefactos que dice haber observado, incluidos los nombres de los paquetes, los nombres de archivo del cargador, los nombres de los directorios y el panel de 23.800 secretos; y los pasos de interrupción que Google dice haber tomado, de los cuales puede dar fe porque deshabilitar una cuenta es algo que hace, no algo que infiere. Help Net Security, Cloud Security Alliance y Lineaje informan todos esos elementos sin contradicción, aunque ninguno de ellos aporta pruebas independientes propias.

Evaluación, en el sentido de que se trata de un juicio que Google está emitiendo: cada atribución a un Estado-nación en el informe; la interpretación del cebo de rechazo como algo deliberado; y la afirmación de que los tokens robados superarán «las comprobaciones automáticas de confianza de los agentes de programación con IA», lo cual es una afirmación sobre cómo se suelen construir esas comprobaciones, más que una medición de un producto concreto que fracase en una de ellas.

No se ha establecido: la identidad del actor de las seis horas, las víctimas y su número, el chatbot y el modelo implicados, y si el servidor Recon está conectado a esa campaña en absoluto.

Y el propio techo del informe es más bajo de lo que sugiere su título. GTIG afirma que aún no ha observado cadenas de explotación plenamente autónomas en el mundo real, y evalúa que el uso por parte de adversarios "podría estar evolucionando hacia este caso de uso". La división se produce dentro del ataque, no a su alrededor: los seres humanos aportan el objetivo, el prompt y el archivo de instrucciones; el agente aporta el escaneo, la resolución de problemas y la rotación, y no se detiene a pedir permiso. Si se lee con atención, la campaña de seis horas no es prueba de que haya llegado la autonomía. Es prueba de que la proporción humana del trabajo se redujo a la parte que requiere un humano —decidir qué hacer—, mientras que todo lo que había entre la decisión y el resultado se ejecutó por sí solo.

Lo que Google dice que cambió y el control al que realmente apunta el informe

La respuesta declarada de Google se articula en dos frentes. En materia de abuso, afirma que las actividades "activaron las respuestas de seguridad de Gemini", que tomó medidas "adicionales y más amplias" contra las campañas a raíz de los fallos de seguridad operativa de los actores, que deshabilitó activos, proyectos y cuentas asociados, y que Google DeepMind utilizó los hallazgos para reforzar sus clasificadores y el propio modelo a fin de que rechace estas solicitudes. En materia de defensa, ha desplegado Google AI Threat Defense, que combina Gemini y modelos de frontera con la priorización de riesgos de Wiz, la remediación de Gemini y CodeMender, y la inteligencia de Mandiant, utilizando modelos más ligeros para el escaneo continuo y modelos de frontera para hallazgos de alto riesgo; también presentó Gemini 3.8 Flash Cyber para la detección de vulnerabilidades y el parcheo automatizado, y publicó una guía de endurecimiento de la cadena de suministro de código abierto.

La corrección específica que exige el caso DUSTMAKER es más acotada que ese stack, y los análisis externos convergen en ella. Una atestación SLSA responde si un paquete fue compilado por la identidad que afirma. No responde si esa identidad sigue perteneciendo a la parte en la que pretendías confiar, y todo el método de DUSTMAKER consiste en tomar prestada una identidad en lugar de falsificarla. El resumen de Lineaje del cambio de fondo es la formulación más clara: «El contenido del repositorio se convierte en autoridad de ejecución». Los nombres de paquetes, los nombres de servidores MCP, las insignias de atestación y los archivos de instrucciones dentro de un repositorio ahora llegan con cierta pretensión de ser obedecidos, y el token OIDC robado es lo que hace que la pretensión parezca verificada.