Hackers colocaram uma armadilha no Google para quem usa Claude. E funcionou.
O primeiro resultado de busca parecia oficial. Tinha a marca certa, o layout certo, as instruções certas. Só faltava ser verdadeiro.
Hackers colocaram uma armadilha no Google para quem usa Claude. E funcionou.
O primeiro resultado de busca parecia oficial. Tinha a marca certa, o layout certo, as instruções certas. Só faltava ser verdadeiro.
Um desenvolvedor chamado Dan Foley estava tentando configurar um plugin do GitHub no Claude Code. Coisa rotineira. Foi ao Google, buscou “github plugin claude code” e clicou no primeiro resultado, que aparecia como anúncio patrocinado com o título “Install Claude Code - Claude Code Docs”.
O site era uma cópia perfeita da documentação oficial da Anthropic. Mesmo layout, mesma identidade visual, mesmo tom. Só que uma linha das instruções de instalação tinha sido trocada por um comando com uma URL ofuscada, escondendo o destino real do que seria baixado na máquina.
Foley percebeu antes de executar. A maioria das pessoas não percebe.
O que estava dentro do comando
Quando o destino real foi decodificado, o endereço apontava para um domínio flagrado pelo ThreatFox como distribuidor de stealer, um tipo de malware que roda silencioso, sem janelas, sem alertas, sem nenhum sinal visível e sai da máquina levando senhas salvas no navegador, cookies de sessão, tokens de autenticação, carteiras de cripto e qualquer credencial que encontre pelo caminho.
Pesquisadores da Bitdefender e da Push Security mapearam a campanha em detalhe. No macOS, o comando enviava um binário Mach-O ofuscado via terminal.
No Windows, usava o mshta.exe, um utilitário legítimo do próprio sistema, para não levantar alertas do antivírus.
O nome do malware é Amatera, um infostealer em modelo MaaS, Malware as a Service.
O que isso significa na prática: qualquer operador com pouca habilidade técnica consegue alugar o payload, clonar uma página de documentação e comprar um anúncio no Google.
A barreira de entrada para esse tipo de ataque caiu a quase zero.
O detalhe que deveria constranger o Google
O anúncio estava verificado.
O Google exige documentação legal para verificar anunciantes. O perfil listado no Ad Center era de uma empresa chamada “Enhancv R&D”, com sede na Bulgária, e estava com o selo de verificação ativo. Os pesquisadores da Bitdefender e do AdGuard identificaram casos similares onde contas de anunciantes legítimas na Malásia foram comprometidas e usadas para rodar a campanha.
O resultado prático é que hackers passaram pela verificação do Google usando identidades reais, seja comprando o acesso a contas comprometidas ou submetendo documentos de empresas que existem de verdade. O sistema de verificação funcionou exatamente como foi projetado. E o anúncio malicioso ficou no topo dos resultados de qualquer forma.
A resposta do Google depois que Foley reportou foi retirar o anúncio e suspender a conta. Mas uma análise do AdGuard mostrou que páginas similares acumularam mais de 21 mil visitas antes de serem derrubadas, e pelo menos uma variante seguia ativa com mais de 4 mil cliques mesmo após o reporte inicial.
Por que o alvo é exatamente o desenvolvedor de IA
Esse ataque não é aleatório. É cirúrgico.
Desenvolvedores que usam Claude Code, Cursor, Windsurf e ferramentas de AI coding são um alvo de altíssimo valor. Uma máquina comprometida de um desenvolvedor não entrega só as senhas pessoais. Entrega tokens de API, chaves SSH, variáveis de ambiente de produção, credenciais de cloud, acessos a repositórios privados. Uma infecção em um laptop de dev pode virar ponto de entrada para pipelines inteiros de CI/CD e infraestrutura corporativa.
Isso não é ataque de oportunidade. É a lógica do shovel business aplicada ao crime: quem está em corrida do ouro com IA está com a cabeça nas ferramentas, no velocity, na entrega. Não está lendo URL dentro de um comando de instalação que veio do primeiro resultado do Google.
E os atacantes sabem disso.
Como ganhar dinheiro com esse sinal agora
O vetor de ataque que essa campanha explora, malvertising combinado com clonagem de página de instalação, está crescendo junto com a popularidade de cada nova ferramenta de IA. Cursor, Windsurf, Replit, qualquer produto novo que virar pauta de developer Twitter em menos de 48 horas vira candidato a ter uma página falsa no Google Ads antes que a maioria dos usuários saiba como é o site oficial.
Isso abre espaço real para quem quer construir negócio em cima disso agora:
Serviço de threat intelligence para equipes de desenvolvimento, monitorando impersonation ativo das ferramentas que os devs do time usam. Não existe produto acessível e focado nisso para times pequenos.
Consultoria de onboarding seguro para empresas que estão adotando AI coding tools em escala e precisam de um blueprint de instalação verificada com hash de binário, domínio oficial e processo auditado.
Conteúdo educacional que ensina o comportamento específico de verificação de URL em comandos de terminal. É um hábito que a maioria dos devs não tem. Quem criar esse conteúdo de forma clara e prática vai surfar o algoritmo enquanto o assunto ainda está quente.
O quiet money aqui está em chegar antes que o problema vire pauta de CISO em palco de congresso.
Como se precaver agora, antes que seja tarde
A regra mais importante não é técnica. É comportamental. Desenvolvedor que copia e cola comando de instalação direto do primeiro resultado do Google sem verificar a URL está jogando roleta.
O hábito de tratar o topo do Google como sinônimo de oficial é exatamente o que essa campanha explorou. O primeiro passo é parar de confiar em anúncio patrocinado para qualquer coisa que envolva instalar software, configurar CLI ou rodar comando no terminal. Sempre vá direto ao repositório oficial no GitHub ou ao domínio que você conhece de cabeça.
Antes de executar qualquer one-liner de instalação, leia o comando inteiro, decodifique qualquer string em Base64 ou URL encurtada que apareça dentro dele, e confirme que o destino final é o domínio oficial da ferramenta. Se o comando tiver uma URL ofuscada ou encurtada no meio, pare.
Não é paranoia, é protocolo.
Para times, o blueprint mínimo é criar uma lista interna de fontes verificadas para cada ferramenta de AI coding que o time usa, com hash do binário oficial e link direto ao repositório, e fazer isso virar parte do onboarding.
Nenhum dev novo instala nada sem seguir essa lista. Ferramentas como o ThreatFox permitem checar se um domínio já foi flagrado como malicioso antes de você chegar nele.
E o AdGuard ou qualquer bloqueador de anúncios ativo no navegador elimina a camada de risco dos resultados patrocinados de uma vez por todas, que é a porta de entrada de toda essa cadeia de ataque.
O que isso mapeia no horizonte
A superfície de ataque da IA não é só o modelo, não é só o dado de treino, não é só o output. É toda a cadeia de distribuição das ferramentas que desenvolvem e operam esses sistemas.
Cada nova ferramenta popular é um novo domínio para clonar, um novo termo de busca para comprar, uma nova base de usuários que ainda não sabe onde fica o site oficial. A curva de adoção de AI tools está em velocidade máxima, e a curva de cautela dos usuários está muito atrás.
Hackers não precisam quebrar os modelos. Eles só precisam chegar antes da documentação oficial no Google.
E por enquanto estão conseguindo.
Me conta aqui nos comentários:
Você ou alguém da sua equipe já copiou um comando de instalação direto de um resultado patrocinado sem verificar a URL?
Sua empresa tem algum processo de verificação antes de instalar ferramentas de IA em máquinas de desenvolvimento, ou ainda está no “cada um instala o que precisa”?
Se você fosse criar um produto de segurança focado em equipes de AI coding, por onde começaria?
Siga Tech Gossip: www.techgossip.com.br
#Cibersegurança #InteligenciaArtificial #Developers #AITools #Malware #TechGossip #ClaudeCode #Segurança #GoogleAds #InformaçãoDigital