El Grupo de Inteligencia de Amenazas de Google (GTIG) y Mandiant han documentado varios incidentes de 2026 en los que los atacantes secuestraron el acceso corporativo a modelos de lenguaje de gran tamaño (LLM, por sus siglas en inglés) alojados en la nube y lo revendieron. Hubo cargos fraudulentos de más de 100.000 dólares en un solo día y facturas acumuladas que llegaron al millón de dólares en algunas organizaciones antes de que se revocara el acceso. El informe, publicado el 2 de noviembre de 2026, pone nombre a grupos, servicios de reventa y técnicas de una práctica conocida como LLMjacking.
Las claves del LLMjacking descrito por Google en 30 segundos
- Los atacantes usan credenciales cloud robadas para consumir modelos de IA de pago a cuenta de la víctima y revender ese acceso.
- GTIG y Mandiant lo detallan en un informe del 02/11/2026, con víctimas en Norteamérica, Sudamérica y Asia-Pacífico.
- Se registraron cargos de más de 100.000 dólares en un día y hasta un millón acumulado en algunas organizaciones.
- La vía de entrada dominante fueron claves de cuentas de servicio, tokens de GitHub y tokens de sesión expuestos o robados, además del fallo CVE-2026-40217 de LiteLLM.
Las organizaciones afectadas pertenecen a los servicios financieros, el comercio minorista, la tecnología y el transporte. Google subraya la diferencia con la minería de criptomonedas a costa ajena. Según el informe (traducción propia), «a diferencia del consumo gradual de recursos asociado al cryptojacking, el LLMjacking puede generar grandes picos de cargos fraudulentos en la nube en cuestión de horas». En varios casos, además, los servicios de IA ni siquiera estaban activados en la cuenta de la víctima: fueron los intrusos quienes los habilitaron.
El término no es nuevo. Lo acuñó Sysdig en mayo de 2024, cuando describió un ataque en el que las credenciales de AWS se habían obtenido de un servidor con una versión vulnerable de Laravel (CVE-2021-3129) y se probaron contra diez servicios de LLM, entre ellos Amazon Bedrock, Azure, Google Vertex AI, OpenAI y Anthropic. Sysdig calculó que, en el peor escenario y con Claude 2.x al límite de cuota en varias regiones, el coste para la víctima podía superar los 46.000 dólares al día. Entre diciembre de 2024 y febrero de 2025, Microsoft llevó a los tribunales a Storm-2139, una red que usó credenciales de clientes expuestas en fuentes públicas para entrar en Azure OpenAI Service y revender el acceso.
Cómo roban y revenden el acceso a los modelos
GTIG señala que el vector de acceso inicial dominante han sido los tokens de identidad cloud expuestos o robados: credenciales de gestión de identidades y accesos (IAM), claves de cuentas de servicio, tokens de acceso personal (PAT) de GitHub y tokens de sesión activos. También detectó la recolección oportunista de claves de API de LLM corporativas publicadas en repositorios públicos de GitHub, endpoints de Ollama abiertos a Internet y el uso de tokens de federación para generar nuevas claves y saltarse la autenticación multifactor (MFA).
El grupo rastreado como UNC6993 entró mediante una clave de cuenta de servicio mal configurada y acumuló más de 100.000 dólares en cargos. Este mismo actor montó una página que guiaba a los usuarios hasta la web legítima del servicio de IA y les pedía pegar el JSON de su sesión, con un token de acceso activo dentro, lo que permitía esquivar la contraseña y la MFA. En otro caso, un actor que recibió claves virtuales ya validadas explotó una vulnerabilidad en el endpoint /key/regenerate de la pasarela LiteLLM (CVE-2026-40217) para convertirlas en credenciales maestras con privilegios PROXY_ADMIN.
El dinero sale de los llamados «mezcladores de LLM», pasarelas que agregan credenciales robadas y venden acceso a suscriptores. Uno de ellos, Jet Night, ejecutó más de 500.000 llamadas a la API en menos de ocho horas y trasladó a una sola organización casi un millón de dólares en coste de tokens. Según GTIG, ofrecía un plan ilimitado por unos 60 dólares al mes, cuando un consumo típico rondaría entre 100 y 250 dólares mensuales. Los operadores se apoyan en herramientas de código abierto como new-api y gcli2api.
Técnicas e indicadores de compromiso (IOC) publicados
- Barridos de validación con peticiones mínimas (
max_tokens=1) para comprobar claves sin disparar alertas por volumen. - Táctica de «quemar y rotar»: crear y borrar cuentas de servicio efímeras para esquivar los límites de uso.
- Alta de la cuenta víctima en acuerdos de pago por uso con modelos premium y solicitudes de cuota de GPU.
- Persistencia con cuentas IAM nuevas, claves SSH inyectadas en los metadatos de las instancias y cuentas de servicio disfrazadas de utilidades internas de optimización de facturación.
- Dominios de mezcladores:
jet-night.comynewapi.pro. El resto de IOC está en una colección de Google Threat Intelligence para usuarios registrados.
Qué registros revisar en AWS, Azure y Google Cloud
La recomendación central de Google es tratar cualquier activación no autorizada de un servicio de LLM como un incidente de seguridad crítico. El informe enumera las operaciones concretas que conviene vigilar en cada nube:
| Nube | Uso de modelos | Reconocimiento y desbloqueo | Evasión |
|---|---|---|---|
AWS (CloudTrail, bedrock.amazonaws.com) | InvokeModel, InvokeModelWithResponseStream, Converse | ListFoundationModels, ListInferenceProfiles, GetFoundationModelAvailability, PutUseCaseForModelAccess, CreateFoundationModelAgreement | Get/Put/DeleteModelInvocationLoggingConfiguration |
| Azure | Microsoft.CognitiveServices/accounts/deployments/write | Nuevos despliegues de modelos | Microsoft.Insights/diagnosticSettings/write y delete |
| Google Cloud | PredictionService.Predict, GenerateContent, StreamGenerateContent | ServiceUsage.EnableService, ListModels, ListEndpoints, ListPublisherModels | Cambios en registros de auditoría |
En AWS, GTIG pide tratar como alta severidad cualquier intento de desactivar el registro de invocaciones hecho por una identidad que no sea la de la infraestructura como código. También sugiere revisar agentes de usuario poco habituales en la organización, como claude-cli, aws-sdk-rust o aws-sdk-go-v2. Una consulta rápida a CloudTrail sirve para ver quién está llamando a Bedrock:
aws cloudtrail lookup-events
--lookup-attributes AttributeKey=EventSource,AttributeValue=bedrock.amazonaws.com
--max-results 50
--query 'Events[].{hora:EventTime,evento:EventName,usuario:Username}'En Google Cloud hay un matiz importante: los registros de acceso a datos, donde aparecen las llamadas de predicción, están desactivados por defecto por su volumen y coste de ingesta, según recuerda el propio informe. Sin ellos, el primer aviso suele llegar por la factura. Por eso Google insiste en vigilar también las peticiones pequeñas de validación y no solo los picos de gasto, que aparecen cuando el daño ya está hecho.
Prevención y respuesta ante un caso de LLMjacking
La primera barrera es no dejar claves en el código ni en repositorios. GitHub ya detectó 39 millones de secretos filtrados en 2024, como contó OpenSecurity al analizar aquel informe. Las medidas que recoge GTIG son conocidas, pero en estos incidentes fallaron:
- Gestor de secretos centralizado, rotación automática de claves y escáneres de secretos en GitHub o GitLab.
- Mínimo privilegio, con denegación explícita de los servicios de LLM que no se usen.
- Claves de API limitadas por modelo, entorno y uso, con cuotas y límites de gasto por modelo.
- MFA resistente al phishing, restricción del tráfico de salida y parcheo de pasarelas como LiteLLM.
- Inventario de «Shadow LLM», es decir, servicios de IA activados sin control del equipo de seguridad.
En AWS Organizations, una política de control de servicios (SCP) permite fijar qué modelos y regiones se pueden invocar en todas las cuentas. El siguiente ejemplo, que debe adaptarse a cada caso (los perfiles de inferencia entre regiones usan ARN propios), bloquea cualquier modelo distinto del aprobado y las operaciones que se usan para desbloquear modelos o apagar el registro. La llamada Converse se autoriza con el mismo permiso bedrock:InvokeModel:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "SoloModelosAprobados",
"Effect": "Deny",
"Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
"NotResource": ["arn:aws:bedrock:eu-west-1::foundation-model/MODELO-APROBADO"]
},
{
"Sid": "SinDesbloqueoNiApagadoDeLogs",
"Effect": "Deny",
"Action": [
"bedrock:PutUseCaseForModelAccess",
"bedrock:CreateFoundationModelAgreement",
"bedrock:DeleteModelInvocationLoggingConfiguration"
],
"Resource": "*"
}
]
}A eso se suman las alertas de presupuesto. AWS Budgets puede aplicar automáticamente una política IAM de denegación o una SCP al superar un umbral, aunque trabaja con datos de facturación que llegan con retraso. Ninguna alerta de gasto sustituye a la detección en los registros.
Si el ataque ya se ha producido, revocar la primera clave robada no basta. GTIG advierte de que los intrusos crean cuentas, claves y accesos de reserva, así que hay que auditar los usuarios IAM y las claves de acceso creados durante el periodo sospechoso, las cuentas de servicio nuevas (sobre todo las que imitan herramientas de facturación), las claves SSH añadidas a metadatos de proyecto o instancia y cualquier cambio en la configuración de registros. Después conviene desactivar el acceso a modelos que no se usan, rotar todos los secretos que estuvieran al alcance de la identidad comprometida y abrir un caso con el proveedor por los cargos. El patrón no es exclusivo de la IA: el robo de credenciales ya es el ataque que mejor esquiva la seguridad corporativa, y el LLMjacking es su versión más cara por hora.
Preguntas frecuentes
¿Qué es el LLMjacking?
Es el uso de credenciales cloud o claves de API robadas para consumir modelos de IA de pago a costa de la víctima, a menudo para revender ese acceso. Sysdig acuñó el término en mayo de 2024.
¿Qué servicios de IA se han visto afectados?
El informe de Google cita Amazon Bedrock, la API de Gemini, la plataforma de IA de Google Cloud, los servicios cognitivos de Azure y endpoints de Ollama expuestos. Casos anteriores afectaron también a Azure OpenAI Service y a otros proveedores.
¿Cómo se detecta un LLMjacking en AWS?
Revisando en CloudTrail las llamadas a InvokeModel, Converse y las operaciones de desbloqueo de modelos o de cambio del registro de invocaciones. También ayudan los agentes de usuario inusuales y las peticiones de un solo token.
¿Basta con revocar la clave robada?
No. Google advierte de que los atacantes crean cuentas y claves de reemplazo, por lo que hay que auditar identidades, claves SSH y cuentas de servicio creadas durante el incidente.
Fuentes:
