Anúncios do Google vinculados ao Claude enganam usuários do macOS

Imagine que você esteja procurando no Google um gerenciador de pacotes open source popular para macOS. Você digita algo como “brew macos”. No topo dos resultados, aparece um link patrocinado supostamente verificado pelo Google. O domínio parece confiável — pertence a uma empresa de IA bem conhecida, como a Anthropic, cujas ferramentas você talvez já utilize no trabalho diário. Nada parece suspeito. Não é um domínio aleatório, nem uma cópia com erro de digitação, nem um site de phishing evidente.

Você clica.

A página explica como instalar o Homebrew, um gerenciador de pacotes bastante popular. O texto é técnico, confiante e familiar. Ele até replica o método real de instalação — um comando de uma única linha no Terminal que baixa e executa um script de configuração. O formato do comando parece quase idêntico ao oficial publicado no site do Homebrew, brew.sh:

• Ele chama o bash
• Baixa um script remoto
• Executa o script imediatamente

Se você já instalou ferramentas de desenvolvimento antes, isso parece normal. Até esperado. Então você copia o comando para o Terminal. Pressiona Enter. O script é executado. Só que não é o Homebrew.

Em vez de baixar o instalador oficial do GitHub, ele baixa silenciosamente uma carga maliciosa de um servidor controlado por invasores e a executa. Do seu ponto de vista, nada de dramático acontece. Mas, em segundo plano, sua máquina já foi comprometida.

Se você for um usuário típico do Homebrew, provavelmente é:

• Um desenvolvedor
• Um engenheiro DevOps
• Um pesquisador de qualquer área
• Um usuário avançado de macOS que trabalha com código ou infraestrutura

Isso significa que seu laptop não é apenas um dispositivo pessoal comum — ele pode conter credenciais sensíveis que funcionam como portas de acesso para outros sistemas, repositórios ou infraestruturas. Se sua máquina armazena chaves SSH, tokens de acesso do GitHub, credenciais de nuvem, configurações de VPN, chaves de API, segredos de CI/CD ou acesso de leitura e escrita a repositórios e ambientes de produção, então uma infecção por malware não se limita ao seu laptop. Ela transforma seu dispositivo em um ponto de entrada comprometido — um elo contaminado em uma cadeia muito maior.

Esse malware pode potencialmente ler arquivos de configuração, extrair tokens de autenticação e enviá-los para um servidor remoto de comando e controle. Com credenciais roubadas, invasores podem causar danos massivos. O alcance disso é praticamente infinito, e o quão devastador pode ser o impacto depende apenas da sua imaginação.

A seguir, listamos apenas alguns cenários que estão longe de ser improváveis. Depois que os invasores obtêm suas credenciais, eles podem inserir código malicioso em um repositório público ou privado. Uma vez adicionado ao repositório, esse código pode se espalhar quando utilizado em bibliotecas compartilhadas ou implantações, transformando o que parece uma atualização normal em uma ameaça oculta que eventualmente alcança outros projetos e usuários.

Os invasores também podem adulterar o processo de build ou os arquivos de lançamento, fazendo com que até softwares aparentemente oficiais estejam secretamente comprometidos. Eles podem publicar versões com backdoor de pacotes amplamente utilizados, espalhando malware muito além do alvo original. E, com acesso às redes corporativas, invasores podem se mover pelos sistemas internos como fantasmas, alcançando bancos de dados sensíveis, servidores privados ou ambientes de produção — tudo começando com aquele único laptop infectado.

Fatos — ou como anúncios do Google promovendo links do Claude se tornaram venenosos

Você provavelmente já percebeu que tudo o que descrevemos acima não é apenas fruto da imaginação — nem um delírio, embora gostaríamos que fosse. Tudo isso realmente aconteceu e pode ter afetado milhares de pessoas. Em 11 de fevereiro, quando começamos a monitorar a campanha, uma das páginas promovidas por esses anúncios já havia recebido cerca de 10.000 cliques. Até agora, as duas páginas que identificamos receberam aproximadamente 25.000 cliques no total (pouco mais de 20.000 em uma e 4.300 na outra), de acordo com seus próprios contadores internos, enquanto o número de impressões dos anúncios provavelmente foi muito maior.

O ataque chama atenção pela simplicidade e pela escala. Na prática, ele ocorreu da seguinte forma, passo a passo:

• Um invasor cria um artefato público gerado por usuário no claude.ai, contendo instruções para instalar o Homebrew.
• A página segue o mesmo padrão de instalação das instruções oficiais, mas o comando é substituído por outro codificado em base64, projetado para baixar e executar uma carga maliciosa a partir de um servidor controlado pelo atacante.
• Em seguida, o invasor compra anúncios de pesquisa no Google direcionados a buscas como “brew macos” ou “brew install”.
• Como o trecho do anúncio exibe o domínio confiável claude.ai, os usuários tendem mais a confiar no link e clicar nele.
• Os usuários chegam ao que parece ser uma página oficial do Claude, mas que na verdade é conteúdo gerado por usuário e controlado pelo atacante.
• O comando codificado em base64 (confirmamos que contém uma URL relacionada a botnet) baixa e executa imediatamente código remoto — uma técnica clássica de distribuição de malware. Tudo isso acontece sem que o usuário perceba.

Havia várias páginas desse tipo, promovidas via Google Ads por diferentes entidades falsas, com um total acumulado de cerca de 25.000 visualizações. Embora seja impossível saber quantas dessas visualizações resultaram na execução real do comando, mesmo uma pequena fração já seria suficiente para causar danos sérios, considerando o tipo de acesso e credenciais normalmente presentes em máquinas de desenvolvedores.

É importante destacar que essas páginas não foram criadas pela equipe do Claude. Tratava-se de conteúdo gerado por usuários (UGC) hospedado no domínio claude.ai. Ainda assim, a forma como esse conteúdo é hospedado e apresentado também faz parte do problema. Colocar conteúdo gerado por usuários diretamente no domínio principal de segundo nível (claude.ai) pode ser justificável do ponto de vista comercial ou de SEO, mas inevitavelmente cria um nível de confiança injustificadamente alto nesse conteúdo sob a perspectiva do usuário. Para a maioria das pessoas, uma página hospedada em claude.ai parece indistinguível de uma página oficial do Claude, tornando a confusão não apenas possível, mas provável. O aviso de que o conteúdo é gerado por usuários aparece no topo da página em letras pequenas e pouco visíveis, o que facilita que usuários menos atentos não o percebam. Além disso, esse aviso sequer aparece quando a página é visualizada em um celular.

Nesse sentido, a responsabilidade pelo abuso de confiança resultante não recai apenas sobre os atacantes ou sobre o Google, que permitiu a publicação do anúncio: as escolhas de domínio e de experiência do usuário também reduziram a cautela dos usuários e ampliaram a eficácia da campanha.

Quando o tempo é crucial

Vale ressaltar que reportamos esse incidente imediatamente após descobri-lo. A linha do tempo foi a seguinte:

• 11 de fevereiro, 15:00 UTC — Um relatório foi enviado ao Google Ads
• 11 de fevereiro, 16:00 UTC — Uma divulgação pública foi publicada no X
• 11 de fevereiro, 20:00 UTC — Um relatório foi enviado ao Claude

Apesar disso, as páginas maliciosas permaneceram acessíveis por horas. A moderação de conteúdo gerado por usuários (UGC) no Claude.ai mostrou-se lenta: a página específica que reportamos só foi removida 16 horas depois. Até esse momento, ela já havia acumulado aproximadamente 21.000 visitas durante o período em que a monitoramos.

Ainda mais preocupante é que outros artefatos maliciosos continuaram ativos mesmo depois disso. Pelo menos uma página semelhante ainda permanece acessível e já acumulou cerca de 4.300 cliques até o momento da redação deste texto. Em outras palavras, embora o relatório inicial tenha sido eventualmente tratado, o atraso na resposta permitiu que a campanha continuasse operando e atraindo novas vítimas mesmo após o problema ter sido sinalizado.

O que torna essa campanha de envenenamento por malware tão engenhosa

Na nossa avaliação, esse ataque tem potencial para ser particularmente eficaz porque combina confiança em todas as etapas com um direcionamento extremamente preciso.

Em alto nível, ele cria uma cadeia perigosa de confiança:

Anúncio de um publisher verificado pelo Google → Domínio oficial claude.ai → Execução de código oculto

Essa cadeia aumenta drasticamente a probabilidade de os usuários executarem o comando sem analisá-lo cuidadosamente.

De forma mais concreta:

• Confiança presumida em cada etapa
• O anúncio mostra um domínio real e reconhecido (claude.ai), não um site falsificado ou com erro de digitação (e muitos usuários nem prestam muita atenção ao rótulo “Patrocinado”).
• O clique leva a uma página real do Claude, não a uma cópia de phishing.
• O texto é escrito em estilo técnico convincente e parece exatamente o tipo de instrução que desenvolvedores esperam encontrar.
• O fluxo de instalação replica o processo legítimo do Homebrew, incluindo um comando shell de uma única linha (que, para ser justo, já parece um pouco assustador até mesmo na versão oficial).

Aqui é importante fazer uma breve explicação. O site legítimo é https://brew.sh/, e o comando oficial de instalação é:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Até certo ponto, ele já se parece exatamente com o tipo de coisa contra a qual especialistas em segurança costumam alertar. O comando baixa um script da internet e o executa imediatamente com bash. Esse padrão é precisamente o mesmo utilizado por distribuidores reais de malware. Claro que, nesse caso, o comando é legítimo e aponta para um repositório bem conhecido no GitHub mantido pelo projeto Homebrew. Mas, do ponto de vista puramente mecânico, o fluxo é idêntico: você está confiando que um servidor remoto forneça código e executando esse código sem inspecioná-lo antes.

No entanto, esse foi apenas um dos fatores que contribuíram para o sucesso dos invasores. O outro foi um público-alvo perfeitamente alinhado:

• O público-alvo é composto por usuários que realmente querem instalar o Homebrew; caso contrário, não estariam pesquisando por isso.
• Esse público provavelmente trabalha com engenharia e possui acesso corporativo, chaves SSH, tokens do GitHub e outras credenciais.
• Esse público espera executar comandos no terminal e não estranha esse comportamento. Ou seja, a ação maliciosa está perfeitamente inserida em um fluxo de trabalho normal e esperado.
• Como os anúncios aparecem para buscas como “brew macos” ou “brew install”, usuários de Windows ou pessoas sem interesse no Homebrew sequer os veem, tornando o tráfego altamente relevante.

Outro fator é o quão barato e fácil é escalar esse ataque. Não há necessidade de criar domínios falsos nem de realizar engenharia social por mensagens diretas ou e-mails. O invasor simplesmente cria uma página em um domínio confiável, compra anúncios e deixa que o próprio tráfego do Google faça o restante. Do ponto de vista operacional, o esforço é mínimo. Não é preciso construir infraestrutura complexa nem manter interação prolongada com as vítimas. Basta criar a página, lançar os anúncios e a distribuição acontece automaticamente. Depois que os anúncios estão ativos, o alcance passa a depender apenas do investimento em publicidade e do volume de tráfego, transformando uma configuração simples em um funil de infecção eficiente e potencialmente massivo.

Na nossa avaliação, a combinação de todos esses fatores criou algo próximo de uma tempestade perfeita: um padrão de instalação familiar e amplamente aceito, um canal de distribuição altamente confiável e um público com potencial para causar impactos significativos em etapas posteriores — exatamente com a intenção certa no momento certo. Embora não apoiemos de forma alguma as ações dos invasores, é difícil não notar uma certa “elegância” sombria na forma como todos esses elementos foram combinados de maneira tão eficiente.

Que conclusões podem ser tiradas disso

Esse ataque demonstra como domínios e plataformas confiáveis podem ser rapidamente transformados em armas. Os usuários veem um link para um domínio legítimo, seguem instruções que parecem normais e, sem perceber, executam comandos que comprometem suas máquinas. Um único clique pode transformar o laptop de um desenvolvedor em um ponto de entrada para roubo de credenciais, inserção de código malicioso em repositórios ou adulteração de processos de build e lançamentos, entre outras consequências.

A conclusão é clara: Google Ads + uma plataforma confiável e bem conhecida + usuários técnicos com grande impacto em cadeias posteriores = um poderoso vetor de distribuição de malware. Mesmo um único endpoint infectado pode iniciar uma reação em cadeia na cadeia de suprimentos, afetando milhares de usuários posteriormente, muito além do alvo original.

Tão importante quanto isso, este incidente também mostra por que tudo isso foi possível desde o início.

Primeiro, existe o problema antigo da moderação insuficiente de anúncios por parte do Google. Não se trata de algo novo nem isolado. Embora o enorme volume de anúncios que o Google precisa processar possa explicar parcialmente a situação, isso não muda o resultado: campanhas maliciosas continuam passando pelos filtros e alcançando grandes audiências. Casos semelhantes já foram documentados anteriormente, por exemplo nesta análise da campanha de malware Bumblebee que abusava do Google Ads.

Segundo, houve a lentidão na moderação de conteúdo gerado por usuários no Claude, combinada com uma escolha questionável de produto e design de domínio. Hospedar conteúdo gerado por usuários não verificado — e potencialmente perigoso — diretamente no domínio principal de segundo nível (claude.ai) faz com que esse conteúdo herde, na prática, a confiança associada à marca.

Considerando tudo isso em conjunto, não se tratou apenas de um ataque engenhoso — mas de uma falha sistêmica em múltiplas camadas: revisão de anúncios, moderação de plataformas e mecanismos de sinalização de confiança.

Ainda assim, esperamos que este incidente sirva como um alerta para as empresas envolvidas e leve a correções rápidas. Dada a dimensão do problema, milhares de pessoas podem já ter sido afetadas ou ainda estar em risco de se tornarem vítimas. É do interesse do Google, da Anthropic — empresa responsável pelo Claude — e, principalmente, dos usuários que essas questões sejam resolvidas o mais rápido possível.

Atualização (13 de fevereiro)

Observamos que os invasores reutilizaram a mesma tática, com uma mudança importante. Em vez de hospedar as instruções maliciosas no claude.ai, a página foi publicada em share.evernote.com, um domínio de terceiro nível utilizado para conteúdo gerado por usuários no Evernote. A mecânica do ataque permaneceu a mesma: uma página de UGC aparentemente legítima em uma plataforma confiável foi usada para distribuir um comando malicioso, demonstrando que essa abordagem não está ligada a um único serviço, como o Claude da Anthropic, mas pode ser replicada em diferentes plataformas populares que hospedam conteúdo criado por usuários.