LLMJacking: acesso roubado a LLMs gerou conta de até US$ 1 milhão, diz o Google; o que conferir na sua nuvem

Cryptojacking sempre foi o golpe clássico de quem rouba acesso de nuvem: minerar devagar e torcer para ninguém olhar a fatura. O Google acha que o LLMJacking vai passar na frente. Num relatório de 2 de novembro, a Mandiant e o GTIG descrevem incidentes de 2026 em que criminosos sequestraram o acesso de empresas a LLMs e geraram mais de US$ 100 mil de cobrança num único dia. Em algumas vítimas, a conta acumulada chegou a US$ 1 milhão antes de o acesso ser cortado.

Os casos foram em serviços financeiros, varejo, tecnologia e transporte, nas Américas do Norte e do Sul e na Ásia-Pacífico.

Como eles entram

Na maioria das vezes, por credencial de nuvem vazada ou roubada: IAM, chave de service account, token pessoal do GitHub, token de sessão. O UNC6993 entrou por uma chave de service account mal configurada. O mesmo grupo mantinha um falso portal de "grupo de usuários de LLM", que levava a pessoa ao site legítimo do serviço e pedia que colasse de volta o JSON com o token ativo. Com isso, senha e MFA ficavam para trás.

Outro grupo garimpava chaves de LLM esquecidas em repositórios públicos do GitHub e testava cada uma com uma requisição de max_tokens=1, que sai barata e passa por baixo dos alertas de volume. Teve ainda quem varresse a internet atrás de Ollama aberto para registrar modelos próprios pelo /api/create.

No LiteLLM, um segundo grupo pegou chaves virtuais já validadas pelo grupo do acesso inicial e explorou uma troca de user ID no /key/regenerate para promovê-las a PROXY_ADMIN. O relatório chama a falha de CVE-2026-40217, mas no NVD e no aviso do LiteLLM o número é de outra falha, uma fuga de sandbox nos guardrails. Pelo que achamos, a falha pública mais parecida é a CVE-2026-47101, corrigida por completo na v1.83.14-stable.

O que fazem depois

Em vários incidentes, o serviço de LLM (Bedrock, Gemini API) nem estava habilitado quando a conta foi invadida; quem ligou foram os atacantes. O UNC6993 passou dos US$ 100 mil assim, criando chaves e habilitando serviços. Outro ator assinou planos pay-as-you-go com modelos premium e disparou inferência em volume. Para fugir do rate limit, criava e apagava service accounts de vida curta, de olho no faturamento da vítima.

O que mais chamou atenção foi a revenda. O GTIG chama de "LLM Mixers" os serviços que juntam chaves roubadas e revendem o acesso. Um deles, o Jet Night, vende plano ilimitado por uns US$ 60 por mês, supostamente com modelos de ponta, quando o equivalente legítimo custa de US$ 100 a US$ 250. Um ator que abastecia o serviço fez mais de 500 mil chamadas em menos de oito horas, e a vítima ficou com quase US$ 1 milhão em tokens. O Jet Night já anunciou várias quedas no Telegram, e o GTIG acha que são chaves revogadas pelas vítimas.

Na nossa leitura, API "compatível com OpenAI" barata demais merece desconfiança.

O que a gente conferiria

• Repositório: scanner de segredos no histórico inteiro, não só no código atual; o trufflehog no modo git faz isso. Chave que foi para repositório público tem de ser revogada; apagar o commit não resolve.
• Ollama: por padrão ele só aceita conexão da própria máquina. Se alguém mudou o OLLAMA_HOST para aceitar conexões de fora, teste a porta 11434 a partir de outra rede: se a rota /api/tags devolve a lista de modelos, qualquer um usa o seu servidor.
• LiteLLM: v1.83.14-stable ou mais nova, que cobre as CVE-2026-40217, 2026-47101 e 2026-47102.
• Chaves: uma por ambiente e por modelo, com limite de uso, para que a chave do modelo barato não chame o caro.
• Orçamento: alerta só avisa, como dizem as documentações do Google Cloud e da Azure. Para cortar, precisa de automação: Budget Actions com política de negação na AWS, função no Pub/Sub que desliga o faturamento no GCP, action group na Azure.
• Logs: max_tokens=1 vindo de onde não deveria e qualquer habilitação de serviço de IA. Na AWS, o relatório cita PutUseCaseForModelAccess e CreateFoundationModelAgreement no CloudTrail; no GCP, o EnableService do aiplatform.googleapis.com. Lá, os logs de Data Access, onde fica a inferência, vêm desligados por padrão.

Fontes: relatório do Google, Help Net Security e The Register.