GTIG AI Threat Tracker: de um prompt a milhares de credenciais em seis horas

O Google Threat Intelligence Group publicou a edição do segundo trimestre de 2026 do seu AI Threat Tracker em 8 de setembro de 2026. O caso que sustenta o relatório é curto o bastante para ser enunciado sem rodeios: um suposto ator com motivação financeira usou um recurso de nuvem pertencente a uma vítima, inseriu um prompt e um conjunto de instruções de agente previamente escritas em um chatbot de programação com IA e colheu milhares de credenciais de terceiros em menos de seis horas, com o agente gerenciando sozinho a verificação de vulnerabilidades, a solução de problemas e a rotação de IP. O mesmo relatório descreve servidores MCP trojanizados no PyPI, um ladrão de credenciais que rouba a própria identidade de um sistema de build para que seus pacotes com backdoor cheguem com atestações SLSA Build 3 válidas e assinadas criptograficamente, e texto adversarial destinado a fazer com que scanners de segurança baseados em LLM se recusem a ler o código por baixo dele. Tudo isso é o relato do Google sobre sua própria telemetria. Este relatório está catalogado, com seu grau de confiança e suas fontes citadas, no arquivo de incidentes de IA, que reúne todos os outros incidentes documentados desta série ao lado dele.

Nenhuma das alegações substantivas foi verificada por uma parte que não esteja apenas repetindo o Google. Help Net Security cobriu o rastreador no dia da publicação, a Cloud Security Alliance publicou uma nota de pesquisa no dia seguinte, e a Lineaje publicou uma análise do DUSTMAKER em 17 de setembro; cada uma é um resumo ou uma camada analítica sobre a divulgação do Google, e a própria Lineaje diz isso, observando que o GTIG “descreve várias capacidades relacionadas do DUSTMAKER, em vez de um único traço de execução de ponta a ponta observado”. A segunda fonte citada ao lado deste registro, um item de “threat pulse” do threatops.tech datado de 11 de setembro de 2026, é uma repetição, e não uma segunda testemunha: não acrescenta reportagem, não contesta nenhum número e eleva o rótulo de severidade sem explicar em relação ao que ele é medido. A cobertura não é totalmente consensual nem mesmo quanto ao nome da edição — a Help Net Security o chama de rastreador do Q3 2026, embora date seu principal caso no Q2 2026 — o que é uma diferença de numeração, não um conflito factual.

Os ficheiros de arquivo classificam isto como um relatório e não como um incidente: grau de confiança A, sem contestação, sem qualquer cifra quantificada de dano real registada a esse respeito. Essa classificação descreve a qualidade da documentação, não a escala do dano. A Google conta credenciais, não vítimas. O rastreador não diz quantas organizações foram apanhadas na campanha de seis horas, quem eram, que chatbot foi utilizado, nem se alguma das credenciais roubadas foi posteriormente vendida ou utilizada.

As seis horas que o GTIG descreve, e as três tarefas que o agente realizou sozinho

A sequência no relatório vai do acesso ao resultado com muito pouca participação humana no meio. O ator comprometeu um recurso de nuvem e depois usou um chatbot comercial de programação com IA junto com o que a GTIG chama de "um prompt" e "um conjunto de instruções de agente" — os playbooks em markdown que agora ficam em repositórios como arquivos AGENTS.md — para planejar, construir e executar a operação. A própria definição do Google para o resultado é uma "campanha massiva de coleta de credenciais habilitada por agentes", concluída "em menos de seis horas".

Três tarefas são descritas como autónomas, e são as três que, de outra forma, teriam exigido a atenção de um operador:

• O pipeline de varredura de vulnerabilidades, que as instruções do agente permitem que a IA "gerencie de forma autônoma", na formulação que a Help Net Security cita da GTIG.

• Resolução de problemas em tempo real de tudo o que a varredura revelou, para que uma falha não travasse a execução à espera de uma decisão.

• Rotação de IP, para que tentativas sucessivas partissem de endereços diferentes sem que ninguém emitisse o comando.

Onde a operação foi executada é tão importante quanto a rapidez com que foi executada. Ao operar a partir da própria infraestrutura de nuvem da vítima, o ator encaminhou o tráfego pelos intervalos de IP legítimos da vítima. Pedidos que parecem vir de dentro de uma organização são exatamente aqueles que as defesas baseadas em reputação estão menos capacitadas para questionar, e o relatório registra isso como uma consequência de operar a partir do próprio ambiente da vítima.

O que o relatório não contém é tão revelador quanto o que contém. Não há tempos por etapa, portanto “menos de seis horas” é uma medição única de toda a execução e não é decomponível em um gráfico. Não há nome para o ator além de “suspeito de motivação financeira”, nem vítima, nem declaração sobre qual modelo ou chatbot de qual fornecedor estava envolvido. O rastreador trata o caso como um exemplo prático de uma tendência, e está escrito em um nível de abstração que atende a esse propósito, e não no nível que um profissional de resposta a incidentes desejaria.

Um servidor exposto que se transformou em um painel de 23.800 segredos

Uma segunda descoberta na mesma secção é mais concreta e constitui um caso separado. A GTIG encontrou um servidor de comando e controlo exposto que alojava uma framework automatizada de reconhecimento e gestão de credenciais à qual chama Recon. A listagem do diretório era legível e revelava o desenho: AGENTS.md, KNOWLEDGE.md, agentic_vuln_research.md, além de um diretório modular .openclaw/ e um diretório memory/. Esses nomes de ficheiro são a impressão digital de uma pilha de agentes, e não de um implante feito à medida — instruções, conhecimento acumulado e um plano de investigação, tudo em disco, onde as ferramentas do operador os podem ler.

O mesmo diretório, mais tarde, estava servindo como um painel frontend ativo que organizava e validava mais de 23.800 segredos coletados, incluindo chaves de API para serviços de nuvem e de IA. A GTIG caracteriza a mudança que isso representa como um movimento "de infostealers passivos e focados em endpoints para a coleta agêntica ofensiva" — ou seja, de malware que captura o que consegue de um único laptop para ferramentas que continuam operando sobre os alvos que já alcançaram.

Duas ressalvas acompanham esse número. Vinte e três mil e oitocentos é uma contagem de segredos, não de pessoas ou empresas, e o relatório não converte uma coisa na outra. E a GTIG não afirma se o servidor Recon e a campanha de seis horas são a mesma operação; eles são apresentados como observações separadas na mesma seção, portanto tratá-los como uma única linha narrativa seria uma inferência que o relatório não faz.

DUSTMAKER e a atestação que afirma corretamente que o pacote é genuíno

A metade do rastreador relativa à cadeia de abastecimento diz respeito ao UNC6780, que o Google também acompanha como TeamPCP, um grupo com motivação financeira que tem comprometido infraestruturas de código aberto desde março de 2026, em PyPI, npm e Docker Hub. O seu método com ferramentas de IA é direto: contas de programadores comprometidas foram utilizadas para publicar forks trojanizados de servidores MCP legítimos, com tiktoken_mcp citado como exemplo no PyPI, e foi injetado código malicioso em repositórios organizacionais oficiais, incluindo azure-functions-mcp-extension. A GTIG observa que os payloads e os hooks de workspace maliciosos eram depois ingeridos automaticamente sempre que os assets eram descarregados ou clonados — sem isco separado, sem segundo passo.

O ladrão de credenciais dele, DUSTMAKER, é onde reside o ponto técnico mais útil do relatório. A cadeia é curta. O ladrão detecta que está sendo executado em um ambiente de CI/CD; a GTIG escreve que, "se confirmado", ele extrai tokens OIDC da memória do processo de um runner do GitHub Actions. Ele usa esses tokens para se autorizar como um publicador confiável. Em seguida, publica versões comprometidas de pacotes que carregam atestados SLSA Build 3 válidos e assinados criptograficamente. Nada nessa cadeia é forjado. O atestado é real, emitido para uma identidade real, para uma compilação que realmente aconteceu — de código que o atacante escreveu. A conclusão da GTIG é a frase que importa para qualquer pessoa que dependa de proveniência: "Pacotes publicados com tokens válidos passarão pelas verificações automatizadas de confiança dos agentes de codificação de IA."

O restante do comportamento do DUSTMAKER visa locais que os defensores não monitorizam. Ele larga e modifica ficheiros dentro dos diretórios de trabalho do assistente de codificação de IA e do IDE — .claude/, .vscode/, .cursor/ — onde se confunde com o ruído dos programadores e evita locais que a deteção de endpoint realmente monitoriza, como chaves de registo do Windows ou /etc/cron.*. Escreve configuração que faz com que o IDE ou a extensão de IA execute um script como setup.mjs quando a área de trabalho é aberta, o que transforma a abertura de uma pasta em execução de código. Cria tarefas de pipeline com nomes de temática de IA, como "Copilot Setup", para procurar tokens, e emite chamadas à API para apagar os registos de execução do workflow, de modo a que a execução não apareça na interface do GitHub.

O malware que pede ao scanner para desviar o olhar

O último mecanismo é o menos verificado dos três. Os scripts do carregador JavaScript do DUSTMAKER começam com texto de prompt adversarial incorporado como comentários — em _index.js, entre outros — referenciando armas biológicas e nucleares e incluindo uma solicitação de especificação para um dispositivo de fissão por implosão de 20 quilotons. A avaliação do GTIG é que isso "provavelmente pretendia fazer com que os scanners de segurança de LLMs falhassem ou ignorassem a análise do código JavaScript malicioso subjacente, devido a recusas por motivos de segurança ou de política".

O rótulo dessa frase importa. É uma afirmação sobre intenção, inferida a partir do texto que o loader carrega, não uma demonstração de que algum scanner de fato recusou o arquivo. O relatório não nomeia um scanner que tenha ignorado o arquivo, não informa uma taxa de contorno e não diz que a técnica funcionou. O que está estabelecido é que alguém escreveu a isca e a distribuiu dentro de um ladrão de credenciais — o que, por si só, é evidência de que os atacantes esperam que a triagem baseada em LLM esteja no caminho.

UNC6508, MIDNIGHT NEPTUNE e CALANQUE ION estão no mesmo relatório.

O material do rastreador ligado a Estados é mais amplo do que o seu material criminoso, e em grande parte menos automatizado. UNC6508, um grupo com ligações à RPC, conduziu uma campanha de espionagem de vários anos contra a pesquisa académica, médica e militar norte-americana e agora visa especificamente a pesquisa proprietária em IA; a GTIG suspeita que o grupo comprometa ambientes de nuvem para implementar modelos locais de pesos abertos, o que evita a monitorização das API comerciais e põe a computação da própria vítima a trabalhar.

Em outros lugares, o padrão é o de modelos prontos para uso fazendo trabalho comum em escala. O grupo norte-coreano MIDNIGHT NEPTUNE, anteriormente UNC1069, usou DeepSeek-Coder para escrever trojans de acesso remoto em Python com persistência multiplataforma e injeção de processos, usou LLMs para scripts Bash de movimento lateral, operou personas de engenharia social e iscas técnicas, envenenou configurações de repositórios internos, alterou Claude CLI hooks e implantou o SOMBERMEME backdoor quando um desenvolvedor interagiu com o repositório. O grupo iraniano CALANQUE ION, anteriormente APT42, usou modelos para identificar endereços de e-mail alvo, executar OSINT, localizar iscas, resumir dados exfiltrados e tentar engenharia reversa de código de licenciamento. O grupo ligado à RPC, BASIN CASTLE, usou Gemini para perfilamento de alvos, tradução de material chinês para relatórios políticos formais em inglês e solução de problemas de PowerShell; RAVINE CASTLE pesquisou bypasses de SAML do VMware vCenter e pós-exploração de Active Directory com ele; o grupo russo SANDWORM RELIC fez o Gemini escrever seu código de pulverização de senhas. Com motivação financeira, o UNC6240, também rastreado como ShinyHunters, usou Claude Code prompts para escrever código ofuscado, contornar o Cloudflare e analisar diretórios exfiltrados por meio de ferramentas MCP personalizadas.

Um caso nesta seção vai além dos demais. Um grupo com vínculo à RPC usou o Gemini para projetar um framework dinâmico automatizado de testes de penetração, destinado a observar o estado de um alvo, raciocinar sobre o que fazer em seguida e realizar varredura de portas e análise de serviços. O Google diz que tomou medidas mais amplas contra as campanhas que identificou, desativando ativos, projetos e contas associados. Separadamente, em junho de 2026, o Google desarticulou "Outsider Enterprise," um serviço de cibercrime sediado na China que fornecia kits de phishing, e descreveu isso como a primeira vez que moveu uma ação judicial por uso indevido do Gemini. Essas são duas declarações distintas, e um resumo que as fundisse diria mais do que o relatório diz: o framework de pentest pertence à linguagem de desativação de ativos, e a ação judicial pertence à Outsider Enterprise.

LLMJacking, e quanto custa agora uma conta de IA roubada

O rastreador também precifica o mercado em torno do acesso roubado à IA. A demanda clandestina concentrou-se em credenciais do Claude e do Gemini, juntamente com as IDEs de programação autônomas Cursor Pro e Devin, sendo este último criado pela Cognition, e os preços médios de mercado por conta mais que dobraram durante 2026. Os infostealers que fazem a coleta — LUMMAC.V2, STEALC.V2, VIDAR e ACRSTEALER — foram atualizados para mirar na configuração de desenvolvedor de IA. Em maio de 2026, os controladores do ACRSTEALER publicaram regras de captura de arquivos para o secrets.json do Cline e o config.yaml do Continue AI, ambos os quais podem conter chaves de API em texto simples e endpoints personalizados de roteamento de modelos.

Uma intrusão descrita pelo GTIG mostra quanto vale uma conta de IA depois de comprometida. Em abril de 2026, um token de acesso pessoal do GitHub exposto foi suficiente para habilitar o Gemini Enterprise, provisionar computação de alto desempenho, criar repositórios Docker para uma implantação da API LiteLLM e o framework de agentes Manus, e disponibilizar serviços do Cloud Run expostos a allUsers por meio de uma vinculação de invocador do IAM. A mesma sessão criou uma conta de serviço não autorizada com privilégios de Editor e exportou suas chaves, consultou o BigQuery em busca de variáveis de ambiente e credenciais, tentou transferir a propriedade do projeto para um endereço externo e usou a API Cloud Quotas para solicitar capacidade de NVIDIA RTX 6000 e instâncias adicionais de 48 vCPUs.

O cenário da extração de modelos é a mesma lógica econômica em maior escala. O GTIG afirma que campanhas de destilação agora ocorrem regularmente, “algumas ultrapassando 100 milhões de prompts”, com consultas rotacionadas entre milhares de contas comprometidas e fraudulentas e roteadas por infraestrutura de proxy, e que o Google implantou contramedidas que podem degradar o desempenho de um modelo aluno e métodos para identificar modelos destilados do Gemini pela proveniência.

O que está estabelecido, o que é avaliação e o que o GTIG diz que não viu

Estabelecido, no sentido de que o Google está descrevendo sua própria telemetria primária e suas próprias ações de conta: o relatório e sua data; os artefatos que ele diz ter observado, incluindo os nomes dos pacotes, os nomes dos arquivos do carregador, os nomes dos diretórios e o painel de 23.800 segredos; e as etapas de interrupção que o Google diz ter tomado, às quais pode atestar porque desativar uma conta é algo que ele faz, e não algo que ele infere. Help Net Security, a Cloud Security Alliance e a Lineaje relatam todos esses itens sem contradição, embora nenhum deles traga evidências independentes próprias.

Avaliação, no sentido de que se trata de um julgamento que o Google está fazendo: cada atribuição a um Estado-nação no relatório; a interpretação da isca de recusa como deliberada; e a alegação de que tokens roubados passarão nas "verificações automatizadas de confiança de agentes de codificação com IA", o que é uma afirmação sobre como essas verificações costumam ser construídas, e não uma medição de um produto específico falhando em uma delas.

Não estabelecido: a identidade do ator das seis horas, as vítimas e o seu número, o chatbot e o modelo envolvidos, e se o servidor Recon está sequer ligado a essa campanha.

E o teto do próprio relatório é mais baixo do que seu título sugere. O GTIG declara que ainda não observou pipelines de exploração totalmente autônomos em ambiente real, e avalia que o uso por adversários "poderia estar evoluindo para esse caso de uso". A divisão está dentro do ataque, e não ao seu redor: seres humanos fornecem o objetivo, o prompt e o arquivo de instruções; o agente fornece a varredura, a resolução de problemas e a rotação, e não interrompe para pedir permissão. Uma leitura atenta mostra que a campanha de seis horas não é evidência de que a autonomia chegou. É evidência de que a parcela humana do trabalho encolheu para a parte que exige um humano — decidir o que fazer —, enquanto tudo entre a decisão e o resultado rodava por conta própria.

O que o Google diz que mudou, e o controle para o qual o relatório realmente aponta

A resposta declarada do Google segue duas frentes. No caso de abuso, ela afirma que as atividades "acionaram as respostas de segurança do Gemini", que tomou "medidas adicionais e mais amplas" contra as campanhas com base nas falhas de segurança operacional dos atores, que desativou ativos, projetos e contas associados, e que o Google DeepMind usou as descobertas para fortalecer seus classificadores e o próprio modelo, de modo que ele recuse essas solicitações. Na frente de defesa, o Google implantou Google AI Threat Defense, que combina Gemini e modelos de fronteira com a priorização de riscos da Wiz, a remediação com Gemini e CodeMender, e a inteligência da Mandiant, usando modelos mais leves para varredura contínua e modelos de fronteira para achados de alto risco; também introduziu Gemini 3.8 Flash Cyber para detecção de vulnerabilidades e aplicação automatizada de correções, e publicou orientações de código aberto para o fortalecimento da cadeia de suprimentos.

A correção específica que o caso DUSTMAKER exige é mais estreita do que essa pilha, e análises externas convergem nela. Uma atestação SLSA responde se um pacote foi construído pela identidade que ele alega. Ela não responde se essa identidade ainda pertence à parte em que você pretendia confiar, e todo o método do DUSTMAKER é tomar emprestada uma identidade em vez de forjá-la. O resumo de Lineaje da mudança subjacente é a declaração mais clara disso: "O conteúdo do repositório se torna autoridade de execução." Nomes de pacotes, nomes de servidores MCP, selos de atestação e arquivos de instruções dentro de um repositório agora todos chegam com alguma pretensão de serem obedecidos, e o token OIDC roubado é o que faz a pretensão parecer verificada.