O DNS já não é apenas resolução: ClickFix surpreende ao usar respostas DNS para executar PowerShell e distribuir um RAT

Recentemente, vimos uma variação inquietante das já conhecidas campanhas "ClickFix": criminosos estão usando respostas DNS como canal para entregar código malicioso. Em vez de baixar um executável por HTTP ou convencer a vítima de colar directamente um programa em PowerShell, os atacantes pedem à pessoa que execute uma consulta DNS dirigida a um servidor controlado por eles; a resposta contém o segundo cenário — um comando PowerShell — que é executado na máquina vítima. Segundo os pesquisadores da Microsoft, é a primeira vez que se documenta o uso de DNS como canal neste tipo de campanhas.

O vetor é surpreendentemente simples e perigoso por seu sigilo: O usuário é enganado para abrir o quadro Executar do Windows e executar um comando nslookup apontando para um servidor DNS malicioso. A resposta DNS inclui em seu campo "NAME" um payload em texto - um comando PowerShell - que é então invocada através do intérprete de comando do sistema. Essa segunda etapa, uma vez lançada, descarrega um ZIP com um runtime de Python e scripts maliciosos que realizam reconhecimento na equipe e na rede, instalam mecanismos de persistência e finalmente exibem um troiano de acesso remoto (RAT), identificado nas análises como ModeloRAT.

A Microsoft documentou esta observação em uma recente publicação no seu canal de inteligência, onde explicam que os atacantes estão pedindo explicitamente às vítimas que executem uma consulta DNS personalizada e extrai do campo "Name:" a próxima etapa do ataque. Você pode ver o fio original da Microsoft em sua publicação pública aqui: Microsoft Threat Intelligence em X. Para aqueles que querem reproduzir de forma segura como seria visto uma consulta semelhante contra um servidor determinado, há ferramentas públicas como a interface de digwebinterface, que mostram como se estrutura uma resposta DNS.

Por que usar o DNS? Porque é um canal que costuma passar despercebido: a resolução de nomes é uma função básica e constante nas redes, e muitas organizações não inspecionam o conteúdo das respostas DNS com o mesmo detalhe que o tráfego HTTP(S). Além disso, ao entregar comandos em texto dentro de registros DNS, os atores podem modificar a carga útil sobre a marcha e sortear filtros de URL ou bloqueios em servidores web. De um ponto de vista técnico, isso se encaixa com técnicas documentadas em frameworks de inteligência de ameaças que descrevem o abuso de protocolos de aplicação como DNS para comunicações de comando e controle ( MITRE ATT&CK – DNS como canal de aplicação).

A campanha descrita pela Microsoft seguiu um padrão clássico do ClickFix, mas com novas nuances. Tradicionalmente, o ClickFix baseia-se em engenharia social: a vítima recebe instruções convincentes para executar comandos que "arreglan" algo - uma atualização, uma permissão, uma suposta falha - e assim instala código malicioso. Neste caso, o truque pedia ações muito concretas relacionadas a uma consulta DNS, o que demonstra como os atacantes estão experimentando e adaptando a técnica para evitar controles e aumentar sua taxa de sucesso.

Essa evolução é parte de uma tendência mais ampla: nos últimos meses surgiram variantes que usam desde scripts do App-V no Windows, telas falsas de BSOD, até abusos do Azure CLI para seqüestrar sessões sem necessidade de senha (a campanha identificada como "ConsentFix"). Também foram documentadas campanhas que usam páginas compartilhadas de modelos de linguagem (por exemplo, páginas públicas de ChatGPT, Grok ou serviços similares) para publicar guias falsas que induzem usuários a seguir passos maliciosos. Uma análise de notícias especializadas ajuda a seguir a faixa destas mutações; meios como BleepingComputer Elas costumam cobrir estas variantes e suas implicações.

Consequências técnicas e de detecção: Quando o payload viaja dentro de uma resposta DNS em texto, as defesas tradicionais que revisam downloads HTTP ou bloqueiam domínios maliciosos podem não captar a comunicação. Além disso, o uso de ferramentas legítimas do sistema (nslookup, cmd.exe, PowerShell) e a execução manual por parte do usuário dificultam a classificação como atividade anómala com regras simples. Por isso é crítico combinar controles técnicos com formação: sem a interação humana (executar o comando indicado), a cadeia de infecção não é completa.

Do ponto de vista do atacante, a sequência observada foi: 1) induzir o utilizador a executar uma consulta DNS contra um servidor controlado pelo atacante; 2) obter na resposta DNS um comando PowerShell que é gravado ou executado diretamente; 3) esse comando descarrega um arquivo ZIP com um runtime de Python e vários programas para reconhecimento e movimento dentro do host; 4) são criados itens de persistência (por exemplo, em %APPDATA% e acessos diretos na pasta inicial) e 5) é instalado o ModeloRAT para controle remoto permanente. Embora o servidor DNS identificado pela Microsoft já não estivesse ativo no momento do relatório, a metodologia fica clara e é facilmente replicavel por outros atores maliciosos.

O que podem fazer usuários e administradores: a prevenção passa por não executar comandos que cheguem de fontes não verificadas e por questionar qualquer instrução que peça abrir o quadro Executar para lançar utilitários do sistema. As organizações devem monitorizar e analisar as consultas DNS enviadas, aplicar listas de resolutores seguros e utilizar soluções que inspeccionem o conteúdo das respostas DNS. As recomendações formais sobre como reconhecer e evitar o phishing e a engenharia social estão disponíveis nos recursos de segurança pública, por exemplo no guia da CISA sobre engenharia social: CISA — Social Engineering and Phishing. Para administradores Windows, a documentação oficial sobre ferramentas como nslookup pode servir para entender exatamente quais comandos podem ser abusados: Nslookup (documentação Microsoft).

No plano técnico operacional, é aconselhável registrar e alertar sobre consultas DNS incomuns (por exemplo, solicitações para resolutores externos não autorizados) e detectar padrões como respostas com cargas elevadas de texto não habituais em registros NAME ou TXT. As soluções de segurança em endpoints que monitoram o uso de PowerShell e a execução de processos filhos podem bloquear a cadeia antes que o segundo payload seja baixado e executado. Finalmente, manter políticas de menor privilégio e restringir a capacidade dos usuários padrão para executar comandos administrativos reduz drasticamente o risco.

A aparição deste uso de DNS em campanhas ClickFix nos lembra que a segurança é uma corrida entre detecção e adaptação: quando uma técnica se torna efetiva, os atacantes a reinventam e a abrem a novos canais. A proteção mais efetiva é uma mistura de controle técnico, visibilidade de rede e formação contínua dos usuários, porque muitas dessas campanhas dependem precisamente de que alguém pulse "Aceptar" ou copie um comando sem verificar sua proveniência.

Se você quiser aprofundar o caso técnico e o fio original da pesquisa, consulte a comunicação da Microsoft no seu canal de inteligência e consulta recursos de análise de ameaças e padrões como MITRE ATT&CK para entender o contexto de abuso de DNS como canal de comando e controle: Microsoft Threat Intelligence (X) e MITRE ATT&CK – DNS. Para leituras mais orientadas para o público geral e acompanhamento de incidentes semelhantes, meios especializados como BleepingComputer Eles publicam atualizações frequentes.