Ataque ClickFix usa DNS e nslookup para preparar cargas maliciosas no Windows

Ataque ClickFix usa DNS e nslookup para preparar cargas maliciosas no Windows

A técnica induz usuários a acionar consultas DNS pelo Windows Run, extrai a resposta como estágio intermediário e avança para scripts, persistência por LNK e execução do ModeloRAT.

ComponenteFluxo ClickFix em Windows usando comando operacional omitido, nslookup, resposta DNS Name:, script Python, VBScript, arquivo LNK e ModeloRAT.
VetorEngenharia social por páginas falsas, CAPTCHA falso, phishing, malvertising ou iscas de download que convencem o usuário a acionar uma instrução pelo Windows Run.
ImpactoPreparação de carga por DNS, download de arquivo ZIP externo, reconhecimento local, execução de scripts e persistência para iniciar o malware a cada inicialização do sistema.
PrioridadeMonitorar uso anômalo de nslookup com servidor DNS externo fixo, criação de LNK na pasta Startup e execução encadeada de Python, VBScript e ferramentas de shell.
ArtefatosForam citados azwsappdev[.]com, testdomain123123[.]shop e raxelpak[.]com como domínios relacionados a cadeias ou infraestrutura observada.
MalwaresModeloRAT, Lumma Stealer, CastleLoader, RenEngine Loader, Hijack Loader, Odyssey Stealer, StealC e Stealerium aparecem em cadeias associadas a ClickFix ou técnicas semelhantes.
Resumo técnico

Uma nova variação de ClickFix amplia o uso de engenharia social ao transformar o DNS em canal de preparação de carga. Em vez de depender apenas de requisições web tradicionais, o fluxo induz a vítima a iniciar uma ação pelo Windows Run que passa por comando operacional omitido e aciona nslookup contra um servidor DNS externo definido pelo operador. A resposta da consulta é filtrada para extrair o campo Name:, que passa a funcionar como material de segundo estágio. O ponto crítico não é uma vulnerabilidade de software, mas a manipulação de confiança operacional: a vítima acredita estar seguindo uma correção, verificação ou etapa de suporte e acaba dando início à própria cadeia de infecção.

O ClickFix já era usado em phishing, malvertising, downloads enganosos e páginas falsas de CAPTCHA. A variação baseada em DNS adiciona uma camada de validação e sinalização antes da carga seguinte, o que reduz dependência de tráfego HTTP óbvio e permite que parte da atividade se misture a consultas de rede comuns. Após esse estágio, a cadeia descrita baixa um arquivo ZIP de azwsappdev[.]com, extrai um script Python malicioso, realiza reconhecimento, executa comandos de descoberta e grava um VBScript responsável por iniciar o ModeloRAT, um trojan de acesso remoto escrito em Python e já associado anteriormente a distribuição por CrashFix.

Fluxo técnico

O fluxo começa com uma página, anúncio ou mensagem que apresenta uma tarefa aparentemente legítima, como verificação de CAPTCHA, solução de erro inexistente ou instrução de compatibilidade. O usuário é convencido a acionar uma instrução pelo Windows Run. Essa instrução chama comando operacional omitido e usa nslookup para consultar um servidor DNS externo controlado pelo operador, não o resolvedor padrão do sistema. A resposta DNS é tratada como um mecanismo de preparação: o campo Name: é isolado e usado para avançar a execução da próxima etapa. O desenho dá ao atacante um ponto de decisão fora do fluxo web convencional e permite alterar a sequência sem expor diretamente toda a cadeia em uma página inicial.

Depois da preparação por DNS, a cadeia obtém um ZIP de um servidor externo, extrai um script Python e o utiliza para reconhecimento e descoberta local. O script também implanta um VBScript que atua como lançador do ModeloRAT. Para persistência, um arquivo de atalho LNK apontando para o VBScript é colocado na pasta Startup do Windows, fazendo com que o malware seja reiniciado quando o sistema operacional inicia. Esse encadeamento deixa sinais em processo, sistema de arquivos, rede e persistência, mesmo quando o conteúdo da consulta DNS ou do script intermediário não está disponível para inspeção completa.

A mesma lógica de ClickFix aparece em outras cadeias. Campanhas com Lumma Stealer usam CAPTCHA falso para distribuir CastleLoader em versão AutoIt. Esse carregador verifica sinais de virtualização e programas de segurança antes de descriptografar e iniciar o stealer em memória. Também foram observadas iscas de software crackeado e filmes pirateados que entregam instaladores ou executáveis falsos, inclusive arquivos disfarçados de mídia. Em outra rota, campanhas desde março de 2025 usam RenEngine Loader sob a promessa de cheats de jogos e software pirateado, com Hijack Loader como carregador secundário antes do Lumma Stealer.

Superfície afetada

A exposição principal está em endpoints Windows onde usuários têm permissão para abrir o Windows Run, iniciar interpretadores do sistema, executar scripts e gravar itens em caminhos de inicialização do perfil. A cadeia não exige exploração de uma falha específica descrita no contexto; ela depende de execução manual induzida e do abuso de ferramentas legítimas. Ambientes com baixa restrição de script, pouca inspeção de DNS, ausência de controle sobre Python e tolerância a atalhos em Startup ficam mais expostos à continuidade da infecção.

O alcance não fica restrito ao Windows. Outras campanhas citadas usam ClickFix ou iscas equivalentes para macOS, com foco em stealers voltados a credenciais, carteiras de criptomoedas e armazenamento de navegadores. Uma campanha entrega Odyssey Stealer, rebrand de Poseidon Stealer e derivado de Atomic macOS Stealer, com coleta contra 203 extensões de carteira em navegador e 18 aplicações desktop de carteira. Também há referência a persistência por LaunchDaemon, consulta periódica ao C2 a cada 60 segundos, execução arbitrária de shell, reinfecção e proxy SOCKS5 para tunelamento pelo sistema comprometido.

No ecossistema web, páginas WordPress comprometidas e anúncios maliciosos continuam servindo como pontos de entrada. Uma campanha ClearFake usa CAPTCHA falso para acionar um arquivo HTA e entregar Lumma Stealer; outra usa injeções JavaScript e EtherHiding para buscar conteúdo por meio de contrato na BNB Smart Chain, aumentando resiliência contra remoção e fazendo tráfego malicioso parecer atividade Web3 legítima.

  • Endpoints Windows com execução de comando operacional omitido, nslookup, Python e VBScript permitida para usuários finais.
  • Perfis de usuário em que a pasta Startup aceita criação de atalhos LNK sem controle ou alerta.
  • Usuários expostos a phishing, malvertising, páginas falsas de CAPTCHA, downloads pirateados e artigos falsos de suporte técnico.
  • Ambientes macOS com uso de carteiras de criptomoedas, extensões de navegador e permissões sensíveis acessíveis por binários confiáveis.
Hunting e telemetria

A detecção deve tratar nslookup como ponto de partida quando ele aparece iniciado por comando operacional omitido após interação de usuário, especialmente com servidor DNS externo explícito e sem relação com diagnóstico corporativo. A sequência de processo é mais importante que um único evento: abertura pelo Windows Run, criação de shell, consulta DNS incomum, download subsequente de arquivo ZIP, extração de script Python, criação de VBScript e gravação de LNK em Startup. A defesa também deve correlacionar consultas DNS a domínios pouco vistos, servidores resolvers fora do padrão corporativo e atividade de rede logo após páginas de verificação ou correção falsas.

Em endpoints, sinais fortes incluem Python executado a partir de diretórios de usuário, scripts com nomes e caminhos incomuns, VBScript usado como lançador, criação de tarefas agendadas em cadeias CastleLoader e persistência por Startup. Para Lumma Stealer e carregadores associados, a caça deve considerar processos AutoIt, instaladores NSIS falsos, scripts VBA ofuscados, verificações de virtualização e execução em memória. Em macOS, eventos relevantes incluem AppleScript ou Terminal iniciados por iscas de compatibilidade, LaunchDaemon persistente, requisições periódicas ao C2, acesso incomum a Keychain, armazenamento de navegador e carteiras de criptomoedas.

Na rede, indicadores citados devem permanecer defangados e usados como pivôs, não como lista completa de bloqueio. azwsappdev[.]com aparece no download do ZIP da cadeia ModeloRAT; testdomain123123[.]shop foi associado à infraestrutura de Lumma Stealer; raxelpak[.]com aparece em uma campanha macOS de artigo falso. A presença desses domínios deve ser correlacionada com processo de origem, usuário, host e janela temporal, porque a ausência deles não elimina a técnica.

  • nslookup filho de comando operacional omitido com resolvedor externo fixo e consulta sem vínculo com operação administrativa conhecida.
  • Evento de download de ZIP seguido por extração e execução de script Python no mesmo host.
  • Criação de VBScript e atalho LNK na pasta Startup do usuário.
  • Processos AutoIt, NSIS ou VBA ofuscado próximos a instalação de software pirateado, cheats ou arquivos disfarçados de mídia.
  • Em macOS, LaunchDaemon novo, AppleScript inesperado, acesso a Keychain e conexões periódicas a infraestrutura externa.
Mitigação

A resposta deve começar pelo bloqueio da cadeia de execução induzida. Organizações podem restringir o uso de Windows Run para usuários sem necessidade operacional, aplicar políticas de controle de aplicação para Python, VBScript, HTA, AutoIt e instaladores não aprovados, além de impedir persistência não autorizada em Startup. Controles de DNS devem registrar servidor consultado, processo de origem quando disponível, domínio, resposta e volume por host. Consultas DNS feitas por ferramentas de diagnóstico a resolvers externos devem gerar alerta quando partirem de estáções comuns.

Para hosts suspeitos, a contenção precisa preservar evidências antes de limpeza: árvore de processos, cache DNS, histórico de downloads, artefatos em Startup, scripts em diretórios de usuário, tarefas agendadas e conexões recentes. Contas usadas no host devem ser avaliadas para roubo de credenciais, principalmente quando a cadeia envolver stealers como Lumma, StealC, Stealerium ou Odyssey. Em ambientes com carteiras de criptomoedas, a resposta deve considerar que seed phrases e dados de extensão podem ter sido coletados, sem registrar valores sensíveis em tickets ou relatórios.

A prevenção depende também de reduzir a eficácia da engenharia social. Treinamentos e banners devem focar no comportamento específico: páginas que pedem ações pelo Windows Run, Terminal, PowerShell, AppleScript ou comandos de correção não devem ser tratadas como verificação legítima. Navegadores, gateways web e EDR devem bloquear páginas de CAPTCHA falso, downloads vindos de sites de software crackeado, arquivos compactados protegidos por senha em campanhas suspeitas e anúncios que redirecionam para fluxos de instalação ou diagnóstico sem procedência corporativa.

  • Criar regra de alerta para comando operacional omitido seguido de nslookup com servidor DNS externo explícito em estáção de usuário.
  • Bloquear ou restringir execução de VBScript, HTA, AutoIt e Python fora de diretórios e assinaturas aprovadas.
  • Monitorar e revisar criação de LNK na pasta Startup e tarefas agendadas novas em perfis de usuário.
  • Inspecionar downloads de ZIP e instaladores NSIS originados de páginas de CAPTCHA, software pirateado ou anúncios.
  • Rotacionar credenciais e revogar sessões quando houver evidência de stealer, preservando logs de identidade, navegador e endpoint.

Postar um comentário

0 Comentários