Más de 100.000 dólares en un día y, en algunos casos, cargos acumulados de hasta un millón: ese es el coste que Google y Mandiant atribuyen a ataques de secuestro de infraestructura de inteligencia artificial empresarial. La técnica, conocida como LLMjacking, aprovecha credenciales robadas o expuestas para generar consumo en servicios cloud que la organización afectada sigue pagando.
El 2 de noviembre, Google Threat Intelligence Group (GTIG) publicó un análisis de varias intrusiones investigadas por Mandiant durante 2026. Los casos abarcan distintos proveedores de nube y de modelos de lenguaje, y afectaron a organizaciones de Norteamérica, Sudamérica y Asia-Pacífico en los sectores financiero, minorista, tecnológico y de transporte. BleepingComputer, The Hacker News, CSO Online y CRN Asia recogieron los hallazgos.
La operación no consiste necesariamente en robar datos ni en manipular un chatbot visible para el público. Los atacantes buscan acceso directo a los recursos de modelos y cómputo de la víctima, y luego los usan o los convierten en un servicio para terceros. En la práctica, las peticiones parecen consumo legítimo asociado a las cuentas comprometidas; la factura, sin embargo, llega a la empresa cuyo acceso fue secuestrado.
De una credencial robada a una factura de siete cifras
GTIG observó dos tipos de acceso inicial: la búsqueda de endpoints de modelos expuestos públicamente y el robo de claves API válidas desde máquinas o entornos desprotegidos. La vía más habitual en las investigaciones fue el uso de tokens de identidad cloud expuestos o robados. Entre ellos figuran credenciales de Identity and Access Management (IAM), claves de cuentas de servicio, tokens personales de GitHub y tokens de sesión activos.
También se encontraron claves de API de modelos publicadas en repositorios públicos de GitHub. Un grupo las comprobó mediante solicitudes automatizadas que generaban un solo token, con el parámetro max_tokens=1. La prueba permitía confirmar que una clave funcionaba sin producir el volumen de tráfico que normalmente podría llamar la atención de los sistemas de detección. CSO Online señaló que esas microtransacciones pueden quedar por debajo de umbrales de alerta basados en consumo.
En otro caso, un actor desconocido utilizó un Personal Access Token robado para entrar en repositorios privados de código y después explotó una vulnerabilidad sospechada en una aplicación empaquetada dentro de un entorno cloud con contenedores. Google también describió el uso de credenciales IAM corporativas para generar nuevas claves de acceso y el abuso de claves de cuentas de servicio con permisos amplios.
El acceso inicial puede abrir una búsqueda más amplia dentro de la infraestructura. Los atacantes enumeraron servicios cloud, repositorios y almacenes de datos; revisaron registros de acceso; clonaron código para localizar secretos incrustados y credenciales de desarrolladores, y realizaron consultas en bases de datos para obtener contraseñas y otros datos de acceso. En una intrusión, la exploración cubrió varias regiones cloud.
Para conservar el control, algunos actores crearon cuentas IAM o de servicio no autorizadas, modificaron permisos e inyectaron claves SSH en máquinas virtuales. Google también registró cuentas de puerta trasera disfrazadas de herramientas internas de optimización de facturación y el uso de permisos de creación de tokens para obtener credenciales temporales de cuentas con más privilegios. En un caso, ese proceso permitió extraer de gestores de secretos credenciales de infraestructura, contraseñas de bases de datos internas y claves API de terceros.
UNC6993, una página falsa y una brecha en LiteLLM
Uno de los grupos identificados por Google es UNC6993. A mediados de 2026, según el análisis de GTIG, comprometió una instancia cloud mediante una clave de cuenta de servicio mal configurada y usó el acceso para obtener entrada a una API de LLM. El grupo también creó una página de secuestro de sesión que imitaba un portal de aplicación.
La página conducía a los usuarios al sitio legítimo del servicio de LLM y les pedía pegar un bloque JSON que contenía un token de acceso activo. El token se enviaba después a una API de backend para sortear la contraseña y la autenticación multifactor (MFA). Google describió así una forma de robar una sesión ya autenticada sin depender únicamente de capturar una contraseña.
Las intrusiones no se limitaron a las credenciales. Los investigadores observaron la explotación de CVE-2026-40217, una vulnerabilidad en LiteLLM, software de enrutamiento de solicitudes entre aplicaciones y modelos. El análisis de Google sitúa el fallo en el endpoint /key/regenerate: un actor aprovechó una vulnerabilidad de reasignación de identificador de usuario para convertir claves virtuales estándar en credenciales administrativas PROXY_ADMIN.
CRN Asia describe el resultado como una escalada desde claves virtuales ordinarias hasta permisos de administrador. Google indicó que, en esa investigación, un segundo grupo obtuvo claves virtuales previamente validadas por el actor que había conseguido el acceso inicial y después atacó la lógica de la aplicación. Esa división de tareas muestra que las intrusiones pueden combinar el compromiso inicial de una cuenta con la toma de control posterior del gateway de modelos.
Los intermediarios revenden el acceso a los modelos
El negocio posterior se organiza alrededor de los llamados LLM Mixers: gateways de enrutamiento que agrupan credenciales comprometidas, distribuyen solicitudes entre cuentas y revenden acceso a suscriptores clandestinos. Los operadores pueden interponer su propia infraestructura para ocultar el origen de las peticiones y convertir cuotas empresariales robadas en un servicio de pago.
Google identificó a Jet Night como uno de esos servicios. En un caso, un actor realizó más de 500.000 llamadas a APIs de LLM en menos de ocho horas con claves API de terceros robadas para alimentar el enrutamiento de solicitudes de Jet Night. El consumo trasladó casi un millón de dólares en costes de tokens a la organización víctima.
Jet Night ofrecía un plan de tokens ilimitados por aproximadamente 60 dólares al mes, con acceso anunciado a modelos avanzados. Google comparó ese precio con un coste habitual de entre 100 y 250 dólares mensuales para servicios de consumo similares. El precio bajo permite atraer suscriptores, mientras el gasto real se carga a las cuentas de las empresas comprometidas.
GTIG observó además que Jet Night anunció varias interrupciones en su canal público de Telegram. Google considera probable que algunas estuvieran relacionadas con la revocación de claves robadas después de que las víctimas descubrieran el acceso no autorizado. La infraestructura depende de que las credenciales sigan activas: cuando una empresa las invalida, el servicio pierde parte de la capacidad que estaba revendiendo.
UNC6993, por su parte, habría utilizado herramientas de código abierto como new-api y gcli2api para reunir claves y repartir las solicitudes entre cuentas. GTIG cree que el grupo vende acceso a esas herramientas a través de tiendas clandestinas. En otro caso, una infraestructura de retransmisión personalizada, alojada en dominios que imitaban sistemas internos de una víctima, desvió cuotas comerciales de modelos hacia el ecosistema de reventa newapi[.]pro.
El uso fraudulento también puede ir más allá de las llamadas a modelos. Los investigadores vieron actores que activaron servicios de IA que no estaban habilitados antes de la intrusión, generaron claves adicionales y contrataron modalidades de pago por uso con modelos premium. Para sortear límites de solicitudes, algunos aplicaron una estrategia de «quemar y rotar»: crear y eliminar repetidamente cuentas de servicio de corta duración, mientras observaban la interfaz de facturación.
En un caso, un actor habilitó agentes, desplegó proxies inversos accesibles públicamente y utilizó paquetes proxy personalizados de Node.js para ofrecer endpoints compatibles con varios modelos avanzados bajo la identidad D1337-KAIROS. Google también documentó un backdoor basado en el marco de agentes Manus, que consultaba un modelo para interpretar instrucciones y ejecutar comandos en el entorno comprometido. El actor llegó a aprovisionar instancias cloud con GPU, intentó desplegar hardware de gama alta en varias regiones y solicitó aumentos de cuota mediante la API del proveedor.
Qué recomienda Google y qué espera de los atacantes
Google recomienda empezar por IAM y la seguridad de la cadena de suministro. Sus medidas incluyen centralizar la gestión y rotación de secretos, evitar privilegios que no sean necesarios para cada función y denegar por defecto los permisos que no se hayan requerido expresamente, incluido el acceso a servicios cloud de LLM.
La compañía también aconseja aplicar MFA resistente al phishing, vigilar la activación no autorizada de servicios de IA y configurar límites de uso y gasto para las APIs. Los registros de auditoría cloud y de inferencia deben estar habilitados y revisarse para detectar activaciones inesperadas, comprobaciones sospechosas de credenciales, patrones de consumo inusuales e intentos de desactivar el registro.
La recomendación de monitorización importa incluso antes de que aparezca una factura llamativa. Las pruebas de claves con solicitudes de un solo token pueden pasar inadvertidas si se observan únicamente los grandes volúmenes. Google propone dar visibilidad a los servicios de IA y modelos no autorizados —la llamada shadow AI— y tratar como un incidente grave cualquier activación de servicios que la organización no haya autorizado.
Las conclusiones de Google apuntan a una expansión del modelo de reventa. GTIG espera que los atacantes den prioridad al LLMjacking frente a formas tradicionales de robo de recursos, como el cryptojacking, por la posibilidad de monetizar rápidamente el acceso mediante los LLM Mixers. También prevé que mejoren la exploración automatizada de tokens expuestos y que busquen vulnerabilidades en middleware de enrutamiento a medida que las empresas incorporen modelos de mayor capacidad y flujos de trabajo con agentes.
«Las organizaciones tendrán que supervisar de cerca y proteger los modelos y el cómputo que están poniendo en marcha rápidamente, o puede que no sean las únicas que los utilicen. Eso significa examinar el uso, habilitar la autenticación multifactor y gestionar cuidadosamente los secretos».
— John Hultquist, analista jefe de Google Threat Intelligence Group
En los incidentes analizados, algunas organizaciones acumularon cargos de hasta un millón de dólares antes de revocar el acceso comprometido. Google recomienda vigilar tanto las credenciales como la activación de servicios, los cambios de permisos y el consumo de las APIs para detectar el abuso antes de que el coste siga creciendo.
Fuentes: BleepingComputer, The Hacker News, Google Cloud Blog, CSO Online, CRN Asia
