InstallFix: quando o golpe começa no Google Ads e termina no terminal

TL;DR: A campanha InstallFix mostra um padrão perigoso: o atacante não precisa explorar uma CVE no seu ambiente se conseguir convencer alguém a copiar um comando de instalação falso. No caso analisado pela Trend Micro, páginas falsas de Claude Code promovidas via Google Ads levaram usuários a executar uma cadeia com mshta.exe, VBScript, PowerShell ofuscado, bypass de AMSI, C2 por vítima e comportamento associado a infostealer.

Eu gosto desse caso porque ele junta três coisas que muita empresa ainda olha separadas:

• confiança em resultado patrocinado;
• cultura de copiar comando de instalação;
• máquina de dev como alvo de alto valor.

O usuário pesquisa por "Claude Code", vê um anúncio no topo, abre uma página bonita, copia o comando e roda. Na cabeça dele, isso é instalação. Na cabeça do atacante, isso é execução inicial.

Essa é a parte mais importante do InstallFix: o ataque não força a porta. Ele entrega uma porta falsa e pede para a vítima entrar.

O que aconteceu

A Trend Micro publicou uma análise da campanha InstallFix, também chamada de Fake Claude Installer threat. Segundo a pesquisa, os atacantes usaram páginas falsas de instalação do Claude AI/Claude Code distribuídas por Google Ads para induzir usuários a executar comandos maliciosos.

As páginas tinham instruções específicas por sistema operacional e imitavam a experiência normal de instalação de ferramenta moderna. Isso funciona porque devs, analistas e usuários técnicos já estão condicionados a copiar comandos de documentação para o terminal.

O ponto não é "as pessoas são descuidadas". O ponto é que o fluxo legítimo de instalação de ferramenta CLI já parece muito com uma primitiva de execução remota.

Quando a documentação oficial manda rodar npm install, curl, brew, winget ou algum bootstrapper, o atacante só precisa trocar a origem.

Por que isso é um problema de AppSec e DevSecOps

Muita gente colocaria esse caso só na caixinha de phishing ou malware. Eu acho limitado.

Para mim, isso também é AppSec e DevSecOps porque mira a cadeia de trabalho do desenvolvedor. A máquina de dev costuma ter:

• tokens de GitHub;
• chaves SSH;
• sessão aberta em cloud;
• acesso a repositórios privados;
• credenciais de package registry;
• secrets em .env;
• ferramentas de deploy;
• histórico de comandos e contexto do produto.

Um infostealer em uma estação dessas pode virar incidente de supply chain. Não porque o pacote oficial foi comprometido, mas porque a identidade de quem publica, aprova ou faz deploy pode ser roubada.

Isso conversa diretamente com o que já escrevi sobre o incidente TanStack: a cadeia de confiança não é só código. Ela inclui pessoas, sessão, token, pipeline e máquina local.

A cadeia de infecção em linguagem simples

A Trend Micro descreve uma cadeia em vários estágios. Traduzindo para o que importa na defesa:

1. Malvertising no Google Ads. O usuário busca por Claude Code e recebe um resultado patrocinado que leva para uma página falsa.
2. Página falsa com comando de instalação. A vítima copia e executa um comando que parece legítimo.
3. mshta.exe entra na jogada. No Windows, a cadeia usa mshta.exe para baixar e executar um arquivo claude.msixbundle.
4. O arquivo é um ZIP/HTA polyglot. Ele parece um pacote ZIP/MSIX, mas tem conteúdo HTA/VBScript anexado para execução pelo mshta.exe.
5. VBScript roda sem chamar atenção. O script usa COM/Shell.Application, esconde janela e chama o próximo estágio.
6. cmd.exe reconstrói PowerShell. A cadeia monta powershell em partes, usa comando codificado e tenta escapar de detecções simples.
7. Bypass de AMSI e SSL. O stager desativa validação de certificado e tenta cegar AMSI com patch em memória.
8. C2 único por vítima. A máquina gera um identificador baseado em COMPUTERNAME + USERNAME, usado para montar um subdomínio único.
9. Payload fileless. O próximo estágio é baixado e executado em memória.
10. Persistência. Foram observadas tarefas agendadas para sobreviver a reboot.
11. Coleta de dados. A análise dinâmica observou comportamento de coleta de dados de navegador e carteiras digitais.

A parte técnica é interessante, mas a tese é simples: o atacante transformou documentação falsa em loader.

O detalhe que muita gente ignora: Google Ads não é sinal de legitimidade

Tem uma confiança quase automática em resultado patrocinado.

Isso é ruim por dois motivos. Primeiro, porque o anúncio aparece antes do resultado orgânico. Segundo, porque o usuário interpreta "apareceu no topo" como "foi validado".

Não foi.

Google Ads é canal de aquisição. Para o atacante, também é canal de entrega. A diferença entre campanha de marketing e campanha de malware pode ser só o domínio, o criativo e o payload.

Em times técnicos, eu colocaria isso em treinamento de segurança sem drama:

• resultado patrocinado não valida domínio;
• comando de instalação precisa bater com documentação oficial;
• página bonita não prova origem;
• botão "copy" não transforma comando em confiável.

Onde a detecção deveria acender

Se eu estivesse olhando esse caso em um SOC, não apostaria em um único indicador. Eu procuraria comportamento.

Alguns sinais fortes:

• mshta.exe chamando URL remota;
• mshta.exe criando cmd.exe ou powershell.exe;
• PowerShell com -enc, -EncodedCommand, IEX ou Invoke-Expression;
• PowerShell 32-bit em SysWOW64 sem necessidade clara;
• comando com reconstrução de string, como set x=pow + set y=ershell;
• tentativa de desabilitar validação SSL em PowerShell;
• presença de AMSI_RESULT_NOT_DETECTED em comando, script ou memória;
• tarefas agendadas criadas logo após execução de instalador;
• conexão para domínio recém-criado ou domínio com subdomínio hexadecimal por host;
• download de arquivo com extensão de instalador que também é interpretado como script.

O erro seria bloquear só o hash e seguir a vida. Hash ajuda, mas esse tipo de campanha muda rápido.

Controles práticos

Eu começaria por estes controles:

1. Bloquear ou restringir mshta.exe. Em muita empresa, ele não tem uso legítimo. AppLocker, WDAC ou política de EDR podem reduzir bastante o risco.
2. Tratar máquina de dev como ativo sensível. Dev workstation não é notebook comum. Tem token, chave e acesso privilegiado.
3. Usar DNS filtering e secure web gateway. Principalmente para domínios recém-criados, TLDs incomuns e infra com reputação ruim.
4. Reduzir dependência de instalação manual. Preferir pacote oficial, registry confiável, mirror interno, MDM ou catálogo corporativo.
5. Treinar com exemplos reais. Mostrar uma página falsa de instalação é mais efetivo do que falar genericamente "cuidado com phishing".
6. Monitorar criação de tarefas agendadas. Persistência por scheduled task ainda é comum porque funciona.
7. Rotacionar secrets após suspeita. Se a máquina rodou um infostealer, limpar malware não basta. Token roubado continua válido.

Isso também se conecta com hardening prático de Cloudflare: controle bom é o que reduz superfície antes do incidente, não só depois do alerta.

IoCs da campanha

Os indicadores abaixo vêm do arquivo oficial de IoCs da Trend Micro. Mantive os domínios e URLs defangados para evitar clique acidental.

Domínios

URLs

IPs

Hashes

Artefatos de arquivo

• claude.msixbundle
• cloude-91267b64-989f-49b4-89b4-984e0154d4d1

Hunting rápido

Ideias de hunting que eu colocaria no backlog:

process.name:mshta.exe AND process.command_line:(*http* OR *msixbundle*)

parent.process.name:mshta.exe AND process.name:(cmd.exe OR powershell.exe OR wscript.exe OR cscript.exe)

process.name:powershell.exe AND process.command_line:(*-enc* OR *-EncodedCommand* OR *IEX* OR *Invoke-Expression* OR *AMSI_RESULT_NOT_DETECTED*)

network.destination.domain:*oakenfjrod* OR process.command_line:*1-5-8*

Essas consultas precisam ser adaptadas para o EDR/SIEM de cada empresa. A lógica é mais importante que a sintaxe.

Minha leitura

InstallFix é um lembrete de que a fronteira entre "documentação" e "execução" ficou perigosa.

Quanto mais ferramentas de IA entram no fluxo de desenvolvimento, mais os atacantes vão copiar a estética dessas ferramentas. Eles não precisam convencer alguém a abrir um anexo estranho. Basta parecer o tutorial certo no momento certo.

Para mim, a defesa passa por três mudanças:

• verificar origem antes de rodar comando;
• monitorar comportamento de instalação como evento de segurança;
• tratar endpoints de desenvolvimento como parte crítica da cadeia de software.

O atacante entendeu uma coisa simples: dev confia em terminal. Agora a segurança precisa entender isso também.

Leia também

• CTI: a inteligência que separa o ruído do risco real, para transformar IoCs em priorização.
• O Incidente TanStack, para conectar credenciais de dev com risco de supply chain.
• Hardening Cloudflare com Python, para pensar controles preventivos fora do endpoint.

Referências

• Trend Micro: InstallFix and Claude Code
• Trend Micro: IoCs oficiais da campanha InstallFix
• Anthropic: documentação oficial de instalação do Claude Code
• Snyk: guia de Claude Code com Snyk Studio