Google Threat Intelligence Group (GTIG) y Mandiant han detectado este año un aumento del LLMjacking, el secuestro de modelos de lenguaje mediante credenciales robadas. Según su análisis, algunas organizaciones han soportado más de 100.000 dólares de cargos fraudulentos en un solo día y cifras acumuladas de hasta un millón. Para una empresa española con IA generativa en la nube, es un riesgo financiero y de seguridad que ya no se puede tratar como algo teórico.
Qué es el LLMjacking y qué ha observado Google
El LLMjacking consiste en usar sin autorización los servicios de modelos de lenguaje de una organización, normalmente con claves de API robadas, para que sea la víctima quien pague el consumo. El proveedor cloud registra las peticiones como uso legítimo y factura los tokens al titular de la cuenta.
Según BleepingComputer, que recoge el análisis de GTIG y Mandiant, detrás de esta actividad hay dos grupos que se coordinan para comprometer y monetizar infraestructura de LLM empresarial:
- Quienes rastrean endpoints de LLM expuestos públicamente.
- Quienes roban claves de API válidas de equipos poco protegidos.
The Hacker News también se ha hecho eco de la investigación.
Cómo funciona el negocio: de la clave robada al «mixer»
Tras obtener el acceso, los atacantes lo venden a servicios conocidos como «LLM mixers». Estos ofrecen a sus suscriptores acceso no autorizado a modelos de IA a precios muy bajos y usan una infraestructura de proxies para reenviar los prompts a los servicios secuestrados con las claves robadas.
Los investigadores citan como ejemplos Jet Night, que vende «planes de acceso ilimitado» por 60 dólares al mes, y el servicio newapi[.]pro. En un caso, un actor ejecutó más de 500.000 llamadas a la API en menos de ocho horas con claves de terceros robadas para alimentar jet-night.com. Google afirma que ese servicio trasladó a la organización víctima casi un millón de dólares en costes de tokens.
Cuando el acceso se revende, el volumen de peticiones puede dispararse de golpe, en ocasiones por encima de 1.000 por segundo. Google también identifica un clúster, UNC6993, que parece usar herramientas de pasarela para agregar claves robadas y repartir las peticiones, y que probablemente vende el acceso en foros clandestinos.
Más allá de la factura: persistencia y uso de tu infraestructura
El impacto no es solo económico. Los atacantes entran mediante credenciales cloud expuestas o comprometidas, claves de cuentas de servicio, tokens de GitHub, tokens de sesión activos y claves de API de LLM. Una vez dentro, buscan credenciales, registros, bases de datos y gestores de secretos, e intentan crear cuentas de puerta trasera o inyectar claves SSH para mantener el acceso.
Los investigadores también han observado la explotación de CVE-2026-40217, una vulnerabilidad en LiteLLM que permite ejecutar código arbitrario en el servidor a través del endpoint de pruebas de los guardarraíles de código personalizado.
En algunos casos, los atacantes han usado la nube de la víctima para alojar endpoints proxy no autorizados y cargas de trabajo agénticas. Google describe un actor que habilitó agentes, desplegó proxies inversos accesibles públicamente y usó paquetes Node.js a medida para exponer endpoints compatibles con varios modelos de frontera bajo la identidad «D1337-KAIROS».
Qué recomienda Google
Las medidas empiezan por priorizar la gestión de identidades y accesos (IAM) y proteger la cadena de suministro:
- Usar plataformas centralizadas de secretos que permitan rotar y gestionar claves.
- Evitar privilegios ampliados salvo que el rol lo exija y denegar todo permiso no necesario de forma explícita, incluido el acceso a servicios de LLM en la nube.
- Exigir autenticación multifactor resistente al phishing.
- Disponer de visibilidad suficiente para detectar servicios de IA no autorizados (shadow AI).
- Fijar límites de uso de API y de gasto, que ayudan a detectar el abuso pronto y a limitar su impacto.
- Activar y vigilar los registros de auditoría e inferencia en la nube: activación de servicios no autorizados, comprobaciones sospechosas de credenciales, uso inusual e intentos de desactivar el registro.
Qué deberían hacer las empresas y cómo puede ayudar CGC
El LLMjacking se parece a otros abusos de credenciales en la nube, pero tiene una particularidad: el coste es inmediato y puede crecer muy rápido. Conviene tratarlo a la vez como un riesgo de seguridad y de control financiero. Para empezar, recomendamos:
- Inventariar el uso de IA: qué servicios de LLM se utilizan, quién los ha activado y con qué credenciales, incluidos los despliegues no autorizados.
- Revisar claves y secretos: localizar claves de API en repositorios, equipos y pipelines, y trasladarlas a un gestor centralizado con rotación.
- Ajustar permisos: aplicar mínimo privilegio y limitar quién puede activar o consumir modelos en la nube.
- Poner límites y alertas: cuotas de uso, presupuestos y avisos de consumo anómalo, con responsables claros que reaccionen.
- Monitorizar y ensayar la respuesta: integrar los registros de auditoría e inferencia en el SOC y definir qué hacer ante una clave comprometida.
En el sector financiero, y en cualquier empresa sujeta a requisitos de gestión de riesgos TIC, estos controles también aportan evidencias útiles para auditoría y cumplimiento.
En CGC Spain acompañamos a las organizaciones en la revisión de su exposición en la nube y en IA generativa, el diseño de controles de identidad y secretos y la definición de la monitorización y la respuesta a incidentes. Si quieres saber cómo se vería un incidente así en tu entorno, podemos empezar por un diagnóstico sencillo y priorizado.
