LLMjacking: ataques com IA roubada já geram cobranças de até US$ 1 milhão

Uma credencial de nuvem exposta pode custar muito mais do que a perda de acesso a um sistema. Em ataques investigados ao longo de 2026, criminosos utilizaram identidades e chaves de API comprometidas para consumir modelos de inteligência artificial em nome das vítimas, gerando despesas que ultrapassaram US$ 100 mil em um único dia. Em algumas organizações, a conta acumulada chegou a US$ 1 milhão antes que o acesso indevido fosse interrompido. Os números foram divulgados em 2 de novembro pelo Google Threat Intelligence Group (GTIG) e pela Mandiant, a partir de investigações de resposta a incidentes em empresas de diferentes setores e regiões, incluindo a América do Sul.

O Blog Minuto da Segurança já havia explicado como o LLMjacking utiliza credenciais roubadas para consumir serviços de inteligência artificial e transferir os custos às empresas. A investigação mais recente amplia aquele cenário: além do uso indevido de APIs, revela a revenda organizada de capacidade de IA, mecanismos de persistência e episódios de prejuízo financeiro em escala muito superior. Esta atualização aprofunda os novos achados sem substituir a cobertura anterior.

O fenômeno, conhecido como LLMjacking, lembra o cryptojacking pela apropriação de recursos computacionais de terceiros, mas apresenta uma dinâmica financeira diferente. Em vez de manter máquinas minerando criptomoedas por longos períodos, o invasor pode disparar milhares de chamadas a modelos de linguagem de alto custo em poucas horas, ampliar quotas, criar novos acessos e transferir integralmente a cobrança para a conta corporativa comprometida. O prejuízo aparece no faturamento de serviços de IA e pode ser percebido tarde demais se a empresa acompanha apenas métricas tradicionais de infraestrutura. A investigação mostra que a ameaça deixou de depender exclusivamente de uma chave de API esquecida em um repositório público. O GTIG observou ataques iniciados com tokens de sessão, credenciais de IAM, chaves de contas de serviço e tokens de acesso pessoal a repositórios de código. Em um caso, uma conta de serviço mal configurada permitiu que o grupo rastreado como UNC6993 ampliasse o acesso a serviços de modelos de linguagem. Em outros episódios, invasores buscaram segredos em repositórios privados, bancos de dados, gerenciadores de credenciais e configurações de aplicações. A obtenção do primeiro token era apenas o começo da intrusão. Uma vez dentro do ambiente, os criminosos procuravam ampliar privilégios e garantir persistência. A Mandiant descreveu criação de identidades não autorizadas, geração de novas chaves, alterações em permissões e inclusão de chaves SSH em instâncias de computação. Também identificou abuso de componentes próprios da infraestrutura de IA. Em uma investigação, um segundo grupo utilizou chaves virtuais já comprometidas e explorou uma falha no gateway LiteLLM, identificada como CVE-2026-40217, para elevar privilégios até obter controle administrativo. O caso ilustra como o risco envolve não só o provedor do modelo, mas também os intermediários que distribuem e controlam o acesso às APIs.

Notícias Relacionadas

• LLMjacking: credenciais roubadas e custos de IA — cobertura anterior

O comércio do acesso roubado

A monetização é a parte mais reveladora do relatório. Os pesquisadores identificaram operadores que não utilizavam necessariamente toda a capacidade furtada para suas próprias tarefas. Em vez disso, ofereciam o acesso a terceiros por meio de estruturas chamadas de “LLM Mixers”: gateways que agregam credenciais de diferentes vítimas, encaminham solicitações a modelos comerciais e revendem o serviço a assinantes clandestinos. A operação cria uma separação entre quem invade o ambiente e quem administra a revenda, aproximando o LLMjacking de outros mercados especializados do crime digital. Em um dos episódios analisados, mais de 500 mil chamadas a APIs de modelos foram realizadas em menos de oito horas. O tráfego foi associado ao serviço Jet Night, que, segundo os pesquisadores, transferiu quase US$ 1 milhão em custos de tokens para a organização atingida. O GTIG também identificou o uso de proxies, infraestrutura de encaminhamento e ferramentas de agregação para distribuir o consumo entre credenciais e contas. Os pesquisadores avaliam que preços muito inferiores aos praticados normalmente por serviços comerciais podem ser sustentados pela utilização de acessos obtidos de maneira ilícita. Essa avaliação é uma hipótese fundamentada nas evidências da investigação, não uma prova de que todo serviço barato de IA opere dessa forma. A técnica pode passar despercebida no início. Antes de disparar grandes volumes de requisições, invasores testaram chaves comprometidas com chamadas mínimas, em alguns casos limitadas a um token de saída. Essa validação produz pouco tráfego e pode não acionar alertas configurados apenas para grandes aumentos de consumo. Em seguida, os operadores passam a habilitar serviços, criar credenciais adicionais e acionar modelos premium. O relatório também descreve estratégias de criação e exclusão contínua de contas de serviço para contornar limites e prolongar o abuso. Para empresas brasileiras, a exposição não depende de hospedar um modelo próprio. Basta que aplicações, integrações, automações ou equipes de desenvolvimento utilizem serviços de IA cobrados por consumo e mantenham credenciais com permissões inadequadas. Uma chave exposta em código-fonte, um token reutilizado por um pipeline ou um gateway acessível sem controles suficientes pode transformar uma conta corporativa em infraestrutura de terceiros. Em ambientes com múltiplos projetos, a ausência de separação entre desenvolvimento e produção aumenta o potencial de propagação do incidente. O impacto também não se limita à fatura. Durante as investigações, os atacantes acessaram repositórios, pesquisaram segredos e, em alguns casos, realizaram operações associadas à obtenção de dados. Isso não significa que todo episódio de LLMjacking envolva vazamento de informações, mas demonstra por que a investigação não pode ser encerrada apenas com o bloqueio da cobrança ou a troca de uma chave de API. É necessário determinar quais identidades foram utilizadas, que permissões tinham, que outros segredos puderam ser acessados e se foram criados mecanismos de persistência.

A proteção começa pelas identidades e pela visibilidade do consumo

O primeiro controle é conhecer o ambiente de IA efetivamente utilizado. Inventariar endpoints, gateways, modelos habilitados, contas de serviço, chaves de API e integrações permite descobrir recursos que não deveriam estar expostos ou sequer ativos. As credenciais precisam ser mantidas em gerenciadores de segredos, com rotação, escopos restritos e separação por aplicação, ambiente e modelo. Uma chave usada por uma funcionalidade simples não deveria autorizar o consumo ilimitado de modelos de alto custo. Limites de requisição, quotas por modelo, alertas de orçamento e políticas de aprovação para habilitar novos serviços ajudam a reduzir a velocidade do prejuízo. Esses mecanismos, porém, não substituem controles de identidade: uma conta com permissões administrativas pode conseguir modificar quotas ou criar acessos alternativos. Por isso, eventos de criação de chaves, concessão de privilégios, ativação de APIs de IA e mudanças em configurações de auditoria merecem monitoramento de segurança, mesmo quando o volume de inferências ainda é pequeno. O relatório recomenda observar sinais específicos em AWS, Azure e Google Cloud. Entre eles estão invocações anormais de modelos, descoberta de serviços disponíveis, alterações em implantações, criação de chaves e tentativas de desabilitar registros. Há um detalhe operacional importante: determinadas chamadas de inferência só aparecem quando logs de dados ou diagnósticos estão explicitamente habilitados. Sem essa telemetria, a organização pode descobrir o abuso pela cobrança, mas não conseguir reconstruir adequadamente sua origem e extensão. Outro ponto crítico é a proteção de gateways e bibliotecas que intermediam o uso de modelos. A vulnerabilidade citada no LiteLLM mostra que componentes de roteamento também precisam entrar no inventário de ativos, no processo de gestão de vulnerabilidades e nos testes de segurança. A mesma disciplina vale para pipelines de desenvolvimento, imagens de contêiner, repositórios de modelos e dependências de aplicações. Não basta proteger o console do provedor se a aplicação intermediária oferece um caminho mais simples para o atacante. A investigação do GTIG e da Mandiant reforça uma mudança no cenário de ameaças: recursos corporativos de IA passaram a ter valor de revenda imediato, assim como credenciais, dados e capacidade computacional já tinham em outros mercados clandestinos. Para reduzir a exposição, segurança, desenvolvimento, operações de nuvem e finanças precisam acompanhar conjuntamente quem pode consumir modelos, em que volume e com quais permissões. Uma conta inesperada de IA pode ser o primeiro sintoma visível de um comprometimento mais amplo — e não apenas um problema de controle orçamentário.