El DNS ya no es solo resolución: ClickFix sorprende al usar respuestas DNS para ejecutar PowerShell y distribuir un RAT

Hace poco hemos visto una variación inquietante de las ya conocidas campañas "ClickFix": delincuentes están utilizando respuestas DNS como canal para entregar código malicioso. En lugar de descargar un ejecutable mediante HTTP o convencer a la víctima de pegar directamente un script en PowerShell, los atacantes piden a la persona que ejecute una consulta DNS dirigida a un servidor controlado por ellos; la respuesta contiene el segundo escenario —un comando PowerShell— que se ejecuta en la máquina víctima. Según los investigadores de Microsoft, es la primera vez que se documenta el uso de DNS como canal en este tipo de campañas.

El vector es sorprendentemente sencillo y peligroso por su sigilo: el usuario es engañado para abrir el cuadro Ejecutar de Windows y ejecutar un comando nslookup apuntando a un servidor DNS malicioso. La respuesta DNS incluye en su campo "NAME" un payload en texto —un comando PowerShell— que luego se invoca mediante el intérprete de comandos del sistema. Esa segunda etapa, una vez lanzada, descarga un ZIP con un runtime de Python y scripts maliciosos que realizan reconocimiento en el equipo y en la red, instalan mecanismos de persistencia y finalmente despliegan un troyano de acceso remoto (RAT), identificado en los análisis como ModeloRAT.

Microsoft documentó esta observación en una reciente publicación en su canal de inteligencia, donde explican que los atacantes están pidiendo explícitamente a las víctimas que ejecuten una consulta DNS personalizada y extraigan del campo "Name:" la siguiente etapa del ataque. Puedes ver el hilo original de Microsoft en su publicación pública aquí: Microsoft Threat Intelligence en X. Para quienes quieran reproducir de forma segura cómo se vería una consulta similar contra un servidor determinado, hay herramientas públicas como la interfaz de digwebinterface, que muestran cómo se estructura una respuesta DNS.

¿Por qué usar DNS? Porque es un canal que suele pasar desapercibido: la resolución de nombres es una función básica y constante en las redes, y muchas organizaciones no inspeccionan el contenido de las respuestas DNS con el mismo detalle que el tráfico HTTP(S). Además, al entregar comandos en texto dentro de registros DNS, los actores pueden modificar la carga útil sobre la marcha y sortear filtros de URL o bloqueos en servidores web. Desde un punto de vista técnico, esto encaja con técnicas documentadas en frameworks de inteligencia de amenazas que describen el abuso de protocolos de aplicación como DNS para comunicaciones de mando y control (MITRE ATT&CK – DNS como canal de aplicación).

La campaña descrita por Microsoft siguió un patrón clásico de ClickFix, pero con matices nuevos. Tradicionalmente, ClickFix se basa en ingeniería social: la víctima recibe instrucciones convincentes para ejecutar comandos que "arreglan" algo —una actualización, un permiso, un supuesto fallo— y así instala código malicioso. En este caso el truco pedía acciones muy concretas relacionadas con una consulta DNS, lo que demuestra cómo los atacantes están experimentando y adaptando la técnica para evadir controles y aumentar su tasa de éxito.

Esta evolución es parte de una tendencia más amplia: en los últimos meses han surgido variantes que usan desde scripts de App-V en Windows, pantallas falsas de BSOD, hasta abusos del Azure CLI para secuestrar sesiones sin necesidad de contraseña (la campaña identificada como "ConsentFix"). También se han documentado campañas que usan páginas compartidas de modelos de lenguaje (por ejemplo, páginas públicas de ChatGPT, Grok o servicios similares) para publicar guías falsas que inducen a los usuarios a seguir pasos maliciosos. Un repaso de noticias especializadas ayuda a seguir la pista de estas mutaciones; medios como BleepingComputer suelen cubrir estas variantes y sus implicaciones.

Consecuencias técnicas y de detección: cuando el payload viaja dentro de una respuesta DNS en texto, las defensas tradicionales que revisan descargas HTTP o bloquean dominios maliciosos pueden no captar la comunicación. Además, el uso de herramientas legítimas del sistema (nslookup, cmd.exe, PowerShell) y la ejecución manual por parte del usuario dificultan la clasificación como actividad anómala con reglas simples. Por eso es crítico combinar controles técnicos con formación: sin la interacción humana (ejecutar el comando indicado), la cadena de infección no se completa.

Desde la perspectiva del atacante, la secuencia observada fue: 1) inducir al usuario a ejecutar una consulta DNS contra un servidor controlado por el atacante; 2) obtener en la respuesta DNS un comando PowerShell que se guarda o se ejecuta directamente; 3) ese comando descarga un archivo ZIP con un runtime de Python y varios scripts para reconocimiento y movimiento dentro del host; 4) se crean entradas de persistencia (por ejemplo en %APPDATA% y accesos directos en la carpeta de inicio) y 5) se instala ModeloRAT para control remoto permanente. Aunque el servidor DNS identificado por Microsoft ya no estaba activo al momento del informe, la metodología queda clara y es fácilmente replicable por otros actores maliciosos.

Qué pueden hacer usuarios y administradores: la prevención pasa por no ejecutar comandos que lleguen de fuentes no verificadas y por cuestionar cualquier instrucción que pida abrir el cuadro Ejecutar para lanzar utilidades del sistema. Las organizaciones deben monitorizar y analizar las consultas DNS salientes, aplicar listas de resolutores seguros y utilizar soluciones que inspeccionen el contenido de las respuestas DNS. Las recomendaciones formales sobre cómo reconocer y evitar el phishing y la ingeniería social están disponibles en los recursos de seguridad pública, por ejemplo en la guía de CISA sobre ingeniería social: CISA — Social Engineering and Phishing. Para administradores Windows, la documentación oficial sobre herramientas como nslookup puede servir para entender exactamente qué comandos pueden ser abusados: Nslookup (documentación Microsoft).

En el plano técnico operativo es aconsejable registrar y alertar sobre consultas DNS inusuales (por ejemplo, peticiones a resolutores externos no autorizados) y detectar patrones como respuestas con cargas elevadas de texto no habituales en registros NAME o TXT. Las soluciones de seguridad en endpoints que monitorizan el uso de PowerShell y la ejecución de procesos hijos pueden bloquear la cadena antes de que el segundo payload se descargue y ejecute. Finalmente, mantener políticas de menor privilegio y restringir la capacidad de los usuarios estándar para ejecutar comandos administrativos reduce drásticamente el riesgo.

La aparición de este uso de DNS en campañas ClickFix nos recuerda que la seguridad es una carrera entre detección y adaptación: cuando una técnica se vuelve efectiva, los atacantes la reinventan y la abren a nuevos canales. La protección más efectiva es una mezcla de control técnico, visibilidad de red y formación continua de los usuarios, porque muchas de estas campañas dependen precisamente de que alguien pulse "Aceptar" o copie un comando sin verificar su procedencia.

Si quieres profundizar en el caso técnico y en el hilo original de la investigación, revisa la comunicación de Microsoft en su canal de inteligencia y consulta recursos de análisis de amenazas y estándares como MITRE ATT&CK para entender el contexto de abuso de DNS como canal de comando y control: Microsoft Threat Intelligence (X) y MITRE ATT&CK – DNS. Para lecturas más orientadas al público general y seguimiento de incidentes similares, medios especializados como BleepingComputer publican actualizaciones frecuentes.