DNS is no longer just resolution: ClickFix surprises using DNS responses to run PowerShell and distribute a RAT

We have recently seen a disturbing variation of the already known "ClickFix" campaigns: criminals are using DNS responses as a channel to deliver malicious code. Instead of downloading an executable using HTTP or convincing the victim to directly paste a PowerShell script, attackers ask the person to run a DNS query to a server controlled by them; the answer contains the second scenario - a PowerShell command - that runs on the victim machine. According to Microsoft researchers, this is the first time DNS has been documented as a channel in this type of campaign.

The vector is surprisingly simple and dangerous for its stealth: the user is deceived to open the Run Windows box and run a nslookup command pointing to a malicious DNS server. The DNS response includes in its "NAME" field a text payload - a PowerShell command - which is then invoked by the system command interpreter. That second stage, once launched, download a ZIP with a Python runtime and malicious scripts that perform computer and network recognition, install persistence mechanisms and finally deploy a remote access trojan (RAT), identified in the analysis as ModeloRAT.

Microsoft documented this observation in a recent publication on its intelligence channel, where they explain that attackers are explicitly asking victims to run a custom DNS consultation and remove from the "Name:" field the next stage of the attack. You can see the original Microsoft thread in its public publication here: Microsoft Threat Intelligence in X. For those who want to play safely what a similar query would look like against a given server, there are public tools like the interface of digwebinterface, which show how a DNS response is structured.

Why use DNS? Because it is a channel that often goes unnoticed: name resolution is a basic and constant function in networks, and many organizations do not inspect the content of DNS responses in the same detail as HTTP (S) traffic. In addition, by delivering text commands into DNS records, actors can modify the payload on the go and remove URL filters or blockages on web servers. From a technical point of view, this fits with documented techniques in threat intelligence frameworks that describe the abuse of application protocols such as DNS for command and control communications ( MITRE ATT & CK - DNS as an application channel).

The campaign described by Microsoft followed a classic ClickFix pattern, but with new nuances. Traditionally, ClickFix is based on social engineering: the victim receives convincing instructions to run commands that "fix" something - an update, a permit, a supposed failure - and so installs malicious code. In this case the trick asked for very concrete actions related to a DNS consultation, which shows how attackers are experiencing and adapting the technique to evade controls and increase their success rate.

This evolution is part of a broader trend: in recent months, variants have emerged that use from App-V scripts on Windows, BSOD false screens, to abuses of the CLI Azure to kidnap sessions without password (the campaign identified as "ConsentFix"). Campaigns using shared pages of language models (e.g. ChatGPT public pages, Grok or similar services) have also been documented to publish false guides that induce users to follow malicious steps. A review of specialized news helps to track these mutations; means such as BleepingComputer They usually cover these variants and their implications.

Technical and detection consequences: when the payload travels within a DNS response in text, traditional defenses that review HTTP downloads or block malicious domains may not capture communication. In addition, the use of legitimate system tools (nslookup, cmd.exe, PowerShell) and user manual execution make it difficult to classify as abnormal activity with simple rules. It is therefore critical to combine technical controls with training: without human interaction (run the command indicated), the infection chain is not completed.

From the attacker's perspective, the observed sequence was: (1) to induce the user to run a DNS query against a server controlled by the attacker; (2) to obtain in the DNS response a PowerShell command that is saved or run directly; (3) that command downloads a ZIP file with a Python runtime and several scripts for recognition and movement within the host; (4) to create persistence entries (for example in% APPDATA% and direct access in the home folder) and (5) to install ModeloRAT for permanent remote control. Although the DNS server identified by Microsoft was no longer active at the time of the report, the methodology is clear and easily replicable by other malicious actors.

What users and administrators can do: prevention is by not running commands coming from unverified sources and by questioning any instruction that you ask to open the Run box to launch system utilities. Organizations should monitor and analyse outgoing DNS consultations, apply safe resolution lists and use solutions that inspect the content of DNS responses. Formal recommendations on how to recognize and avoid phishing and social engineering are available in public security resources, for example in the CISA social engineering guide: CISA - Social Engineering and Phishing. For Windows administrators, official documentation on tools like nslookup can be used to understand exactly which commands can be abused: Nslookup (Microsoft documentation).

At the technical operational level it is advisable to record and alert on unusual DNS queries (e.g. requests to unauthorized external resolution) and to detect patterns such as responses with high, unusual text loads in NAME or TXT records. Security solutions in endpoints that monitor the use of PowerShell and the execution of child processes can block the chain before the second payload is downloaded and run. Finally, maintaining less privileged policies and restricting the ability of standard users to run administrative commands drastically reduces the risk.

The emergence of this use of DNS in ClickFix campaigns reminds us that safety is a race between detection and adaptation: when a technique becomes effective, the attackers reinvent it and open it to new channels. The most effective protection is a mix of technical control, network visibility and continuous training of users because many of these campaigns depend precisely on someone pressing "Accept" or copy a command without verifying its origin.

If you want to deepen the technical case and the original thread of the research, check Microsoft's communication on its intelligence channel and consult threat and standard analysis resources such as MITRE ATT & CK to understand the context of DNS abuse as command and control channel: Microsoft Threat Intelligence (X) and MITRE ATT & CK - DNS. For more general public-oriented reading and follow-up to similar incidents, specialized media such as BleepingComputer they publish frequent updates.