A popularização da inteligência artificial está criando uma nova oportunidade para o cibercrime: em vez de sequestrar computadores para minerar criptomoedas, criminosos estão roubando capacidade computacional de modelos avançados de IA. Conhecido como LLMjacking, esse tipo de ataque permite que invasores utilizem contas corporativas na nuvem, credenciais de serviços e chaves de API roubadas para executar operações de inteligência artificial às custas das vítimas.
O problema ganhou destaque após uma investigação divulgada pelo Google Threat Intelligence Group (GTIG) e pela equipe de resposta a incidentes da Mandiant em novembro de 2026. Os pesquisadores identificaram invasões que provocaram cobranças superiores a US$ 100 mil (cerca de R$ 550 mil) em um único dia, enquanto os prejuízos acumulados em determinadas organizações chegaram a US$ 1 milhão antes que os acessos fraudulentos fossem revogados.
As investigações também revelaram uma estrutura criminosa cada vez mais organizada. Além de roubar credenciais, os invasores comercializam acesso a modelos de linguagem, criam serviços clandestinos de revenda de tokens e manipulam ferramentas legítimas utilizadas por desenvolvedores. Entre os casos identificados estão atividades atribuídas ao grupo UNC6993 e campanhas que envolvem versões adulteradas de ferramentas como Claude Code e OpenAI Codex.
O que é LLMjacking e por que ele supera o cryptojacking tradicional
O LLMjacking é uma modalidade de ataque cibernético na qual criminosos obtêm acesso não autorizado a modelos de linguagem de grande escala, conhecidos como LLMs (Large Language Models), utilizando recursos computacionais e financeiros pertencentes a terceiros.
Na prática, o invasor não precisa desenvolver um modelo próprio, comprar infraestrutura especializada ou pagar pelas APIs utilizadas. Basta conseguir credenciais válidas de uma organização que tenha contratado serviços de inteligência artificial em provedores de nuvem.
Essas credenciais podem incluir chaves de API, tokens de autenticação, credenciais de contas de serviço e permissões associadas ao IAM (Identity and Access Management). Com elas, os criminosos conseguem realizar consultas, executar tarefas automatizadas e consumir modelos comerciais de alto custo.
O ataque pode assumir diferentes formas. Em situações mais simples, o invasor utiliza uma chave exposta para enviar grandes volumes de prompts. Em operações mais sofisticadas, compromete o ambiente de nuvem, cria novas credenciais, habilita serviços adicionais e estabelece infraestrutura própria para distribuir o acesso aos modelos.
A diferença em relação ao cryptojacking tradicional está principalmente na velocidade e no valor do consumo.
Na mineração clandestina de criptomoedas, o atacante normalmente mantém computadores comprometidos trabalhando continuamente. O prejuízo cresce conforme o consumo de eletricidade, processamento e recursos de infraestrutura.
No LLMjacking, entretanto, o custo pode aumentar de maneira muito mais agressiva. Modelos avançados, especialmente aqueles utilizados para raciocínio complexo, programação e execução de agentes autônomos, podem consumir grandes quantidades de tokens em pouco tempo.
Segundo a investigação do Google e da Mandiant, algumas organizações enfrentaram cobranças superiores a US$ 100 mil em apenas 24 horas. Em determinados incidentes, o impacto financeiro acumulado chegou a aproximadamente US$ 1 milhão (cerca de R$ 5,5 mi).
Isso significa que uma credencial comprometida pode transformar uma integração legítima de inteligência artificial em uma despesa extraordinária antes mesmo que a equipe financeira ou de infraestrutura perceba a anomalia.
Como operam os atacantes: vetores de acesso e táticas do grupo UNC6993
O acesso inicial é um dos pontos mais importantes dessas campanhas. Os criminosos procuram credenciais que permitam utilizar serviços de IA sem precisar comprometer diretamente os servidores responsáveis pelos modelos.
Entre os principais alvos estão:
- Chaves de API expostas: credenciais armazenadas acidentalmente em arquivos de configuração, scripts, variáveis de ambiente ou repositórios públicos.
- Tokens pessoais do GitHub (PATs): utilizados para acessar projetos privados, pipelines e informações sensíveis.
- Credenciais de contas de serviço: identidades automatizadas com permissões excessivas em ambientes de nuvem.
- Configurações inadequadas de IAM: políticas que concedem acesso a recursos além do necessário.
- Repositórios corporativos: utilizados como fonte de informações sobre infraestrutura, integrações e segredos operacionais.
O grupo UNC6993, acompanhado pelos pesquisadores do Google, demonstra como essas técnicas podem ser combinadas em uma operação direcionada.
Engenharia social e sequestro de sessão
Uma das estratégias identificadas envolve engenharia social direcionada a desenvolvedores e profissionais que trabalham com inteligência artificial.
Os criminosos utilizam páginas fraudulentas que imitam portais de comunidades e serviços relacionados a IA. A intenção é convencer as vítimas a interagir com conteúdos aparentemente legítimos, mas que servem para capturar informações de autenticação ou executar componentes maliciosos.
Esse tipo de abordagem pode permitir o roubo de sessões autenticadas e tokens ativos, reduzindo a dependência de ataques tradicionais contra senhas.
O problema é especialmente relevante porque a autenticação multifator (MFA) não elimina todos os riscos. Quando um invasor consegue capturar uma sessão já autenticada ou um token válido, pode aproveitar a autorização existente sem necessariamente repetir o processo convencional de login.
Por isso, organizações precisam tratar tokens de sessão e credenciais temporárias com o mesmo cuidado aplicado às senhas administrativas.
Reconhecimento interno e movimentação lateral
Depois de conseguir acesso inicial, o invasor procura ampliar sua presença no ambiente comprometido.
As atividades podem incluir clonagem de repositórios, análise de arquivos de configuração, busca por segredos armazenados no código e identificação de serviços conectados à infraestrutura de inteligência artificial.
O objetivo é encontrar novas credenciais e permissões que permitam alcançar outros projetos e contas de nuvem.
Outro comportamento importante é a exploração de componentes intermediários utilizados para conectar aplicações a diferentes modelos de linguagem. O LiteLLM, por exemplo, funciona como uma camada de integração e roteamento de solicitações entre serviços de IA.
Uma vulnerabilidade relevante nesse contexto é a CVE-2026-40217, classificada com severidade alta e pontuação CVSS 8.8. A falha permite escapar do mecanismo de isolamento utilizado pelo endpoint de teste de código personalizado, podendo resultar na execução arbitrária de código no processo do LiteLLM.
A vulnerabilidade não deve ser confundida com uma prova de que todos os ataques de LLMjacking exploram esse componente. Entretanto, demonstra como um middleware de IA comprometido pode ampliar os riscos para toda a infraestrutura conectada.
Os pesquisadores também identificaram o uso de estratégias de rotação rápida de contas de serviço. Conhecida como burn and rotate, a técnica consiste em criar e excluir identidades temporárias continuamente para dificultar o controle de consumo e contornar limites operacionais.
Esse comportamento pode tornar a investigação mais difícil, especialmente quando os registros de auditoria não são centralizados.
A ascensão dos LLM Mixers e o mercado clandestino de revenda
O LLMjacking deixou de ser apenas uma forma de consumo não autorizado de inteligência artificial. As investigações mostram que existe um mercado clandestino estruturado para transformar credenciais corporativas roubadas em serviços comerciais oferecidos a outros criminosos e usuários.
Nesse ecossistema surgem os chamados LLM Mixers, serviços que funcionam como gateways intermediários. Eles recebem solicitações de clientes, selecionam modelos disponíveis e encaminham as requisições utilizando credenciais pertencentes às organizações comprometidas.
O funcionamento é semelhante ao de um serviço legítimo de agregação de APIs, mas existe uma diferença fundamental: parte da capacidade oferecida pode ser financiada por contas corporativas invadidas.
O Google identificou, por exemplo, o serviço clandestino Jet Night, associado a mais de 500 mil chamadas de API em menos de oito horas. A operação transferiu quase US$ 1 milhão em custos de tokens para uma organização vítima.
O serviço anunciava planos de tokens ilimitados por aproximadamente US$ 60 mensais, oferecendo acesso a modelos avançados por valores muito inferiores aos preços normalmente praticados no mercado.
Essa diferença de preço é um indicador importante. Quando um intermediário consegue oferecer capacidade computacional avançada por valores incompatíveis com os custos normais dos provedores, existe a possibilidade de que esteja utilizando credenciais obtidas ilegalmente.
Outro aspecto preocupante é a especialização dessas operações. Enquanto alguns grupos se concentram no comprometimento inicial das contas, outros administram os gateways, controlam os clientes e distribuem o consumo entre diferentes credenciais roubadas.
Manipulação de ferramentas oficiais: o caso do Claude Code e OpenAI Codex
Uma investigação da Symantec, divisão de segurança da Broadcom, revelou outra abordagem preocupante: a manipulação de ferramentas legítimas utilizadas por desenvolvedores.
O relatório publicado em outubro de 2026 descreve uma infraestrutura clandestina que utiliza as versões genuínas do OpenAI Codex CLI e do Anthropic Claude Code CLI. Portanto, não se trata necessariamente de distribuir executáveis falsificados ou explorar uma vulnerabilidade diretamente nos produtos.
O ataque acontece depois da instalação legítima.
Os usuários são convencidos a executar comandos adicionais que baixam scripts de configuração hospedados em domínios semelhantes aos utilizados por empresas de inteligência artificial. Esses scripts utilizam PowerShell ou Bash, podendo funcionar sem deixar um arquivo convencional persistente no disco.
Depois da execução, as configurações locais das ferramentas são modificadas.
No Codex, os invasores alteram o arquivo ~/.codex/config.toml. No Claude Code, modificam ~/.claude/settings.json. O objetivo é substituir os endereços oficiais dos serviços por servidores controlados pelo intermediário clandestino.
Entre as alterações identificadas estão:
- Redirecionamento de APIs: substituição dos endereços oficiais por endpoints controlados pelo serviço clandestino.
- Substituição de credenciais: instalação de chaves e tokens fornecidos pelo intermediário.
- Desativação do sandbox: configuração do Codex com o modo
danger-full-access. - Ampliação do acesso à rede: habilitação de conectividade para operações de escrita.
- Redução da telemetria: desativação de mecanismos de diagnóstico e comunicação de erros.
Em pelo menos um computador investigado, o script também encerrou a sessão legítima do Anthropic Claude e removeu variáveis de ambiente relacionadas à autenticação antes de configurar as credenciais do intermediário.
A operação foi identificada em aproximadamente 12 organizações, principalmente na China continental, mas também em subsidiárias multinacionais na Coreia do Sul, Taiwan e Malásia.
É importante destacar que a Symantec não encontrou evidências de que o operador tenha efetivamente abusado de todas as informações às quais poderia ter acesso. O risco, entretanto, é significativo: um servidor intermediário consegue visualizar os prompts, arquivos e segredos enviados pelo desenvolvedor ao agente de IA.
Com o sandbox desativado, uma resposta maliciosa ou comprometida também poderia executar comandos com os privilégios do usuário.
Para administradores, isso demonstra que verificar apenas a origem do pacote instalado não é suficiente. É necessário monitorar também os comandos executados posteriormente e as alterações realizadas nos arquivos de configuração das ferramentas.
Boas práticas para blindar ambientes em nuvem contra o LLMjacking
A proteção contra LLMjacking exige uma combinação de segurança de identidade, controle financeiro, monitoramento de aplicações e governança sobre o uso de inteligência artificial.
A primeira medida é abandonar a ideia de que uma chave de API pode permanecer indefinidamente válida dentro de um projeto. Credenciais precisam ter finalidade definida, permissões limitadas e ciclos regulares de renovação.
1. Configure limites de consumo e alertas financeiros
Administradores devem configurar alertas de faturamento para cada projeto e serviço de IA utilizado pela organização.
Sempre que possível, estabeleça cotas de requisições, limites de tokens e restrições por modelo. Uma aplicação de testes não precisa ter autorização para consumir modelos premium sem limites.
Alertas devem considerar não apenas o valor financeiro, mas também alterações repentinas no volume de chamadas, horários incomuns e utilização de modelos que não fazem parte da operação habitual.
2. Adote o princípio do menor privilégio no IAM
Contas de serviço devem receber exclusivamente as permissões necessárias para executar suas funções.
Evite conceder permissões administrativas a identidades utilizadas por aplicações, pipelines de integração contínua e ferramentas de desenvolvimento.
Também é importante revisar privilégios relacionados à criação de chaves, geração de tokens temporários e administração de serviços de inteligência artificial.
3. Centralize o armazenamento de segredos
Chaves de API não devem ser armazenadas diretamente em códigos-fonte, arquivos .env enviados ao Git ou scripts compartilhados.
Utilize plataformas de gerenciamento de segredos, como cofres de credenciais e serviços nativos dos provedores de nuvem.
Implemente varreduras automatizadas em repositórios GitHub e GitLab para identificar credenciais expostas. Caso uma chave seja encontrada publicamente, revogue-a imediatamente. Simplesmente apagar o arquivo do repositório não garante que a credencial tenha deixado de ser acessível.
4. Monitore alterações nas ferramentas de desenvolvimento
Em ambientes que utilizam Claude Code e OpenAI Codex, estabeleça políticas para verificar os arquivos de configuração e as variáveis de ambiente.
Investigue alterações inesperadas em base_url, ANTHROPIC_BASE_URL, OPENAI_BASE_URL e CODEX_API_KEY.
Também merece atenção a configuração danger-full-access, principalmente quando aparece sem autorização formal.
Scripts que combinam comandos de download e execução imediata, como curl | bash e iwr | iex, precisam ser tratados com cautela. Prefira instalações verificadas, fontes oficiais e processos controlados de implantação.
5. Atualize gateways e middlewares de IA
Componentes como LiteLLM concentram autenticação, roteamento e controle de acesso a diferentes modelos. Por isso, precisam integrar o mesmo processo de gerenciamento de vulnerabilidades aplicado aos serviços críticos da organização.
Há uma ressalva importante sobre a CVE-2026-40217: o relatório do Google descreve sua exploração no endpoint /key/regenerate, por meio de uma falha de reassociação de identificadores de usuário que permite elevar Virtual Keys a credenciais administrativas. Já registros públicos associados ao mesmo identificador apresentam uma descrição diferente, relacionada à execução de código no endpoint /guardrails/test_custom_code.
Essa divergência exige cuidado na identificação do componente vulnerável. Administradores devem consultar os avisos oficiais do projeto e dos fornecedores, verificar a versão efetivamente instalada e aplicar as correções correspondentes, sem presumir que a simples atualização de um componente resolve todos os problemas de configuração e identidade.
6. Centralize logs e monitore o tráfego
Mantenha registros de auditoria das operações realizadas nas contas de nuvem e nos gateways de IA.
Investigue eventos de criação e exclusão de contas de serviço, geração de novas chaves, alterações de políticas IAM, ativação inesperada de modelos e mudanças nas configurações de auditoria.
Também monitore requisições pequenas e repetitivas, inclusive chamadas com max_tokens=1. Embora pareçam inofensivas, elas podem ser utilizadas para testar silenciosamente credenciais roubadas.
Por fim, restrinja conexões de saída dos serviços aos destinos aprovados sempre que a arquitetura permitir. Isso reduz a possibilidade de que aplicações corporativas enviem solicitações para proxies clandestinos.
O futuro da segurança de infraestrutura na era dos agentes de inteligência artificial
O crescimento do LLMjacking mostra que a inteligência artificial está modificando não apenas a maneira como empresas desenvolvem software, mas também a economia do cibercrime.
Antes, uma credencial comprometida poderia permitir acesso a dados, servidores ou serviços internos. Agora, ela também pode representar uma fonte direta de capacidade computacional comercializável, com custos transferidos integralmente para a organização vítima.
A popularização de agentes autônomos, ferramentas de programação e middlewares de integração amplia essa superfície de ataque. Uma única identidade comprometida pode permitir a criação de novas credenciais, ativação de modelos premium, execução de agentes e estabelecimento de gateways clandestinos.
O cenário exige que equipes de DevOps, infraestrutura e segurança da informação tratem o consumo de IA como um recurso crítico, sujeito a políticas de identidade, auditoria, orçamento e controle de acesso.
Não basta proteger o código-fonte ou exigir autenticação multifator. É necessário controlar todo o ciclo de vida das credenciais, acompanhar o comportamento das APIs e garantir que ferramentas de inteligência artificial não tenham permissões superiores às suas necessidades reais.
