Monday morning. An employee from the finance department opens an email about a required browser verification. A window resembling a CAPTCHA appears on screen — click to confirm you’re not a robot. After clicking, instructions appear: press Windows+R, paste the command, press Enter. The employee follows every step. They don’t know that they’ve just launched a DNS query to a server controlled by a criminal group, and the response contained an encoded PowerShell script. Within seconds, a remote access trojan began running on their workstation. No antivirus alert was triggered — because it was the user themselves who initiated every command.
The ClickFix technique with the DNS staging variant, described in detail by the Microsoft Threat Intelligence team in February 2026, represents a fundamental shift in how malicious software is delivered. This is no longer about classic phishing links leading to infected sites. Attackers have learned to leverage one of the most trusted network protocols — DNS — as a payload delivery channel. This article explains how this mechanism works step by step, why traditional security controls fail to detect it, and what an organization must change in its security architecture to defend against it.
What exactly is the ClickFix technique and where did it come from?
ClickFix is a social engineering technique in which attackers persuade the victim to independently run a malicious command on their own computer. The name comes from the most common lure scenario — the user sees a message suggesting they need to “fix” something with a “click.” In practice, this means copying a command to the clipboard via JavaScript on a webpage, then pasting it into the Windows “Run” dialog.
The technique first appeared in early March 2024. The first operators — an initial access broker designated as TA571 and the ClearFake cluster — used it to distribute malicious software through fake browser update messages. The mechanism proved so effective that dozens of cybercriminal groups adopted it over the following months. Proofpoint reported that in 2025, the number of attacks using ClickFix increased by 517%, and the technique accounted for 8% of all blocked attacks.
The effectiveness of ClickFix stems from a simple fact — it is the user themselves who runs the malicious code. EDR-class systems that monitor unauthorized processes and suspicious application behavior have limited effectiveness against actions consciously initiated by an authorized user. From the operating system’s perspective, the user opened the “Run” dialog, pasted a command, and pressed Enter. This is a legitimate sequence of actions.
The lures evolved from simple browser error messages, through fake CAPTCHA pages with an “I’m not a robot” button, to fabricated device registration notifications. Attackers continuously test new variants — and the DNS staging variant revealed by Microsoft represents the next level of sophistication.
📚 Read the complete guide: Ransomware: Ransomware - czym jest, jak się chronić, co robić po ataku
Why did nation-state groups become interested in ClickFix?
ClickFix ceased to be exclusively a cybercriminal tool in the second half of 2024. Between October 2024 and February 2025, Proofpoint identified ClickFix operations conducted by groups linked to three nations — Russia, North Korea, and Iran. Each adapted the technique to their intelligence objectives.
The Russian group APT28 (also known as Sofacy, TA422) in October 2024 sent phishing messages with a link imitating a Google spreadsheet. After clicking, the victim landed on a page with a fake reCAPTCHA that copied a PowerShell command to the clipboard and displayed instructions to run it in the “Run” dialog. Another Russian group — designated UNK_RemoteRogue — in December 2024 targeted defense sector contractors, using compromised Zimbra servers to send messages leading to a fake Microsoft Office page. The payload established communication with a C2 server based on the Empire framework.
The Korean Kimsuky (TA427, Emerald Sleet) in January–February 2025 targeted think tanks dealing with North Korea policy. The operation began with a forged meeting invitation. After brief trust-building correspondence, the victim received a link to a page with instructions to run a PowerShell command. The Iranian MuddyWater (TA450) in November 2024 attacked 39 organizations in the Middle East within two days, impersonating Microsoft.
Adoption by APT groups confirms two facts. First — the technique is effective enough to complement advanced arsenals. Second — defending against ClickFix requires a shift in approach, because classic IOCs (IP addresses, domains, file hashes) change rapidly, but the behavioral attack pattern itself remains recognizable.
What does the DNS staging variant involve and why is it more dangerous?
The DNS staging variant, described by Microsoft Threat Intelligence in February 2026, introduces a fundamental change in the payload delivery mechanism. In classic ClickFix, the command copied to the victim’s clipboard contains a direct HTTP reference — typically an mshta or PowerShell call downloading a script from a web server controlled by the attacker. Such traffic is relatively easy to detect by proxies, application-layer firewalls, and IDS/IPS systems monitoring HTTP traffic.
In the DNS staging variant, attackers replaced the HTTP connection with the nslookup command — a native Windows diagnostic tool used to query DNS servers. The command that the victim runs through the “Run” dialog executes a DNS query not to the default system resolver, but to an external DNS server controlled by the attacker. The DNS response — specifically the Name: field in the response — contains an encoded code fragment. The command then filters the response (likely through findstr) and passes the extracted content to an interpreter, which executes it as the second stage of the attack.
This approach offers attackers several significant advantages. DNS queries are one of the most fundamental types of network traffic — every device generates thousands of them daily. Most organizations do not log the full content of DNS responses, and even if they do, parsing the Name: field for encoded payloads requires dedicated rules. Attackers can dynamically modify DNS response content, rotating payloads without changing infrastructure. Moreover, DNS queries are rarely blocked by firewalls — unlike HTTP, which undergoes inspection at multiple layers.
Microsoft described DNS in this context as a “lightweight staging or signaling channel.” This is a precise description — DNS does not serve here to transfer large binary files, but to deliver a compact command that initiates the actual infection chain.
What does the full infection chain look like step by step?
The infection chain in the DNS staging variant consists of five stages, each of which deliberately minimizes traces and bypasses a different layer of security controls.
Stage 1 — Social engineering lure. The victim lands on a crafted page — it could be a fake browser verification message, CAPTCHA, document update, or device registration notification. The page contains JavaScript that copies the malicious command to the victim’s system clipboard. The user sees instructions: open the “Run” dialog (Windows+R), paste the content (Ctrl+V), press Enter.
Stage 2 — DNS query via nslookup. The command pasted by the victim launches cmd.exe, which executes nslookup with parameters pointing to an external DNS server controlled by the attacker. The DNS server’s response — instead of a standard IP address — contains an encoded command in the Name: field. The script filters the response, extracting the second-stage payload.
Stage 3 — Archive download. The extracted command downloads a ZIP archive from a domain controlled by the attacker (in the campaign described by Microsoft — the domain azwsappdev[.]com). At this stage, communication switches to HTTP, but the initial validation and staging occurred via DNS, allowing it to bypass early detection layers.
Stage 4 — Reconnaissance and escalation. A Python script is extracted from the archive that performs environment reconnaissance — collecting information about the operating system, installed software, network configuration, and user privileges. This data is transmitted to the C2 server via HTTP POST requests.
Stage 5 — ModeloRAT installation and persistence. A Visual Basic script launches ModeloRAT — a remote access trojan written in Python, previously distributed in CrashFix campaigns. ModeloRAT enables operators to execute arbitrary commands on the compromised system. Persistence is achieved by creating a shortcut in the Windows Startup folder — a simple but effective mechanism for surviving reboots.
The entire chain from the moment the user clicks to full system compromise takes just seconds. The critical point is that the first stage — establishing contact with the attacker’s infrastructure — occurs via DNS, which is inadequately monitored in most organizations.
Why do traditional security systems fail to detect this attack?
The effectiveness of the DNS staging variant stems from the fact that the attack deliberately bypasses each traditional detection layer individually. No single layer sees the complete picture.
Email layer (secure email gateway) — in many ClickFix campaigns, the lure is not delivered via email but through compromised websites, Google Ads, or injections on legitimate sites. Even if the lure comes from email, the link leads to a page that itself contains no malicious code — only JavaScript that copies text to the clipboard.
Web layer (proxy, web filtering) — the lure page does not host executable files or exploits. From the proxy’s perspective, it is an ordinary HTML page with JavaScript. Category filtering won’t help if the page is newly registered or a legitimate service has been compromised.
Endpoint layer (EDR/AV) — the user themselves opens the “Run” dialog and pastes the command. From the operating system’s point of view, this is a conscious action by an authorized user. The nslookup command is a native Windows tool — its execution alone is not anomalous. Some EDR systems may flag suspicious use of cmd.exe → nslookup → PowerShell, but this requires precisely configured behavioral rules.
Network layer (firewall, IDS/IPS) — a DNS query to an external server is one of the most common types of network traffic. Most organizations do not enforce exclusive use of internal DNS resolvers. Even if they monitor DNS traffic, parsing the Name: field content for encoded payloads is not a standard configuration.
SIEM layer — event correlation requires appropriate logs from each layer. If the organization does not log DNS queries with full responses, launched command parameters (command-line auditing), and activity in the Startup folder, SIEM has no data to correlate.
This analysis shows that defense against ClickFix with DNS staging requires a multi-layered approach — no single technology is sufficient.
What role does DNS play in modern attack techniques?
DNS has been used as a communication channel in offensive operations for years, but the ClickFix variant with DNS staging brings this practice to a new level of accessibility. Previously, using DNS in attacks required advanced C2 infrastructure and dedicated software — techniques such as DNS tunneling (transmitting data in DNS queries and responses), DNS beaconing (regular signaling to the C2 server), and DNS exfiltration (extracting data via DNS queries) were the domain of advanced APT groups.
In the ClickFix variant, DNS serves a validation and staging function. Attackers are not tunneling gigabytes of data through DNS. They use a single query to deliver a compact payload — a few dozen to a few hundred bytes of an encoded command. This makes the technique significantly simpler to implement and harder to detect, because the volume of DNS traffic is minimal.
The Name: field in the DNS response, which under normal conditions contains the domain name associated with the query, in this attack contains an encoded character string that serves as a command to execute. Such abuse does not require special software on the DNS server side — it is sufficient to configure a record to return the appropriate value. Attackers can rotate payloads in real time by changing the DNS server configuration without needing to modify the lure page or the command copied to the victim’s clipboard.
From a defense perspective, this is a serious challenge. Organizations that have implemented HTTP/HTTPS traffic inspection through proxies and blocking of known malicious domains may have a false sense of security. DNS traffic — particularly responses — is a black box in many environments.
How should an organization change DNS monitoring to detect this type of attack?
Effective detection of the DNS staging variant requires, above all, full visibility into DNS traffic — not just queries, but also responses. Most organizations log DNS queries (query logs) but do not record full responses (response logs). In the ClickFix DNS staging attack, it is precisely the response that contains the payload.
The first step is enforcing the use of internal DNS resolvers by all workstations on the network. In the variant described by Microsoft, the nslookup command points to an external DNS server — bypassing the default system resolver. A firewall policy blocking DNS traffic (port 53 TCP/UDP) to servers other than the organization’s internal resolvers effectively prevents this technique. It is worth noting that this applies to both classic DNS on port 53 and DNS over HTTPS (DoH) on port 443, which is becoming increasingly popular and harder to control.
The second step is implementing anomaly analysis in DNS traffic. An nslookup query executed from the “Run” dialog by a user from the finance department — directed to a DNS server unknown to the organization — is an event that should generate an alert. NDR-class systems (Network Detection and Response) and advanced SIEM solutions can correlate such events with other indicators: a new command in cmd.exe, a ZIP archive download, a file created in the Startup folder.
The third step is analyzing DNS responses for unusual content. A DNS response whose Name: field contains an encoded character string instead of a standard domain name is a strong indicator of compromise. DNS security solutions (e.g., DNS firewalls, passive DNS solutions) can identify this type of anomaly.
It is also worth considering implementing DNSSEC — a DNS response validation protocol that makes it harder to manipulate response content. Although DNSSEC is not a panacea for ClickFix (attackers control their own DNS server and can sign responses), it raises the attack complexity threshold and eliminates certain vectors.
What endpoint detection rules should the SOC team implement?
Endpoint-level detection requires behavioral rules that monitor the specific chain of events characteristic of ClickFix. The mere fact of running nslookup is not malicious — it is a native diagnostic tool used by administrators and helpdesk staff. The key is the context in which nslookup is launched and what happens immediately after it.
The first rule should monitor the execution of cmd.exe from the “Run” dialog (explorer.exe → cmd.exe), followed by an nslookup call with a parameter pointing to an external DNS server (an IP address outside the range of internal resolvers). This sequence — especially when executed by a user without administrative privileges — is a strong indicator of ClickFix.
The second rule should detect the process chain cmd.exe → nslookup → findstr → PowerShell (or mshta, wscript, cscript). Filtering the nslookup response through findstr and passing the result to a script interpreter is a mechanism specific to this attack variant.
The third rule concerns file creation in the Startup folder by unauthorized processes. ModeloRAT — the final payload in the campaign described by Microsoft — establishes persistence by creating a .lnk shortcut in the %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup directory. Monitoring write operations in this directory should be standard practice.
The fourth rule — more general — should flag the execution of PowerShell with arguments derived from a DNS query or from a command piped from another process. EDR systems with command-line auditing capabilities can log the full command line and identify encoded payloads (e.g., Base64 strings).
Darktrace, in its analysis of ClickFix, points to additional behavioral indicators: the appearance of a new PowerShell user-agent in network traffic, downloading files with numerical names matching the Unix timestamp pattern, and HTTP POST requests sending system information to rarely visited IP addresses.
Flashcard: Key SOC detection rules — Monitor the sequence explorer.exe → cmd.exe → nslookup with an external DNS server — Detect the chain cmd.exe → nslookup → findstr → PowerShell/mshta — Alert on file writes to the Startup folder by atypical processes — Log full command lines (command-line auditing) for cmd.exe and PowerShell — Correlate DNS, process, and network events within a 60-second time window
How to effectively reduce ClickFix risk through policies and configuration?
Technical detection controls are one side of the coin. Equally important — and in the case of social engineering often more effective — are preventive controls at the level of group policies, system configuration, and operational procedures.
The most direct control is disabling or restricting the “Run” dialog for users who do not need it in their daily work. The Group Policy (GPO) “Remove Run menu from Start Menu” effectively eliminates the primary ClickFix vector. In environments where the “Run” dialog is necessary (e.g., helpdesk, administrators), it is worth implementing monitoring of its usage.
The second control is restricting PowerShell execution through Constrained Language Mode policy or AppLocker/WDAC. Users from finance, HR, or marketing departments do not need to run PowerShell scripts. Restricting this capability to administrators and dedicated service accounts closes one of the most common second-stage ClickFix vectors.
The third control concerns the system clipboard — in high-risk environments (e.g., defense, financial sector), it is worth considering monitoring clipboard copy operations by websites. Browser Isolation or Enterprise Browser solutions can intercept JavaScript attempts to copy content to the user’s clipboard.
The fourth control is enforcing the use of internal DNS resolvers — as described in the DNS monitoring section. Blocking DNS traffic on port 53 to all servers except internal resolvers is a simple firewall rule that eliminates the core of the DNS staging variant.
The fifth control — often underestimated — is regular security awareness training that includes ClickFix scenarios. Traditional anti-phishing training teaches users to recognize fake links and attachments. ClickFix requires an additional module: teach employees that no legitimate website will ever ask them to open the “Run” dialog and paste a command. This simple rule, embedded in organizational awareness, is one of the most effective controls.
What does a ClickFix defense maturity model look like?
Not every organization can immediately implement the full set of controls. The table below presents a maturity model — from basic steps available to any company, to advanced mechanisms for organizations with elevated security requirements.
| Maturity level | Layer | Control | Implementation difficulty | Effectiveness |
|---|---|---|---|---|
| 1 — Basic | User | Training: “Never paste commands into the Run dialog” | Low | High |
| 1 — Basic | Endpoint | Disable the “Run” dialog via GPO for non-admin users | Low | High |
| 2 — Extended | Network | Block DNS on port 53 to servers outside the allow list | Medium | High |
| 2 — Extended | Endpoint | Restrict PowerShell to Constrained Language Mode | Medium | High |
| 2 — Extended | Endpoint | Command-line auditing for cmd.exe and PowerShell | Medium | Medium |
| 3 — Advanced | Network | Full DNS response logging with anomaly analysis | High | High |
| 3 — Advanced | SIEM | Correlation rules: nslookup + external DNS + PowerShell within <60s | High | High |
| 3 — Advanced | Endpoint | AppLocker/WDAC with script interpreter whitelisting | High | Very high |
| 4 — Mature | Network | DNS security with passive DNS and threat intelligence feeds | High | Very high |
| 4 — Mature | Browser | Browser isolation with JavaScript clipboard control | Very high | Very high |
Why does ClickFix change the social engineering defense paradigm?
For decades, the social engineering defense model was based on the assumption that attackers try to convince users to click a malicious link or open an infected attachment. Entire defensive ecosystems were built on this foundation — anti-spam filters, attachment sandboxing, URL rewriting, domain reputation scoring. ClickFix invalidates this assumption.
In the ClickFix model, the user does not click a link to a malicious page in the traditional sense — they paste a command into a system field and run it themselves. They do not open an attachment — they initiate the infection chain themselves through the operating system’s native tools. From a security telemetry perspective, the user’s actions look like conscious, authorized administrative actions.
This forces organizations to shift the defense paradigm from content filtering (what the user receives) to behavior monitoring (what the user does). Instead of asking “is this email safe?”, the system must ask “does this user normally run nslookup from the Run dialog at 9:15 AM?”. This is a fundamentally different detection philosophy — requiring behavior baselining, anomaly analysis, and event correlation in near-real time.
The adoption of ClickFix by APT groups — including APT28, Kimsuky, and MuddyWater — confirms that the technique is effective enough to complement nation-state operation arsenals. Organizations that fail to update their threat models to include the “user runs malicious code themselves” scenario expose themselves to compromise despite having an advanced security stack.
How does nFlo support organizations in defending against advanced social engineering techniques?
Defense against techniques such as ClickFix with DNS staging requires an approach combining network monitoring, endpoint detection, user behavior analysis, and regular resilience testing. nFlo supports clients at each of these levels.
In the area of social engineering testing, nFlo designs scenarios reflecting real-world techniques — including ClickFix variants — and assesses how an organization’s employees respond to lures requiring them to independently run a command. Test results allow precise identification of awareness gaps and targeted training planning where it is most needed.
Security architecture analysis conducted by nFlo considers the DNS layer as a potential attack vector. We verify whether the organization enforces the use of internal resolvers, whether it logs DNS responses, whether firewall rules block unauthorized DNS traffic, and whether the SIEM correlates DNS events with endpoint activity.
As part of incident management, nFlo responds in under 15 minutes, which in the case of ClickFix — where compromise occurs in seconds — can mean the difference between isolating a single workstation and the attacker’s lateral movement across the entire network. Experience from over 500 completed security projects enables the nFlo team to quickly identify behavioral patterns characteristic of new attack techniques.
Frequently asked questions
How does ClickFix differ from classic phishing?
In classic phishing, the user clicks a malicious link or opens an infected attachment — actions that can be intercepted by email filters, sandboxing, and URL rewriting. In ClickFix, the user copies and runs a command in a native system dialog themselves, bypassing most automated protection mechanisms.
Will standard antivirus detect a ClickFix attack with DNS staging?
Standard signature-based antivirus will likely not detect this attack, because the nslookup command is a legitimate system tool and the payload is delivered via DNS, not through an executable file. EDR systems with behavioral detection have a better chance, but require appropriately configured rules.
Which operating systems are vulnerable to ClickFix?
ClickFix in the variant described by Microsoft targets Windows systems, using the “Run” dialog (Win+R) and the nslookup tool. However, ClickFix variants for macOS (using Terminal) and Linux (using terminal with curl/wget commands) were also observed in campaigns from 2025.
What is ModeloRAT and how dangerous is this trojan?
ModeloRAT is a remote access trojan (RAT) written in Python, previously distributed in CrashFix campaigns. It enables attackers to execute arbitrary commands on the compromised system, collect environment information, and maintain persistent access through Windows automatic startup.
Won’t blocking DNS on port 53 disrupt normal network operations?
No, provided proper configuration. Workstations should use internal DNS resolvers (e.g., Active Directory DNS, Pi-hole, or a corporate resolver). The blocking applies only to DNS traffic directed to external servers bypassing internal resolvers — which in a properly configured network should not occur.
How quickly after publication of a new ClickFix technique do campaigns using this variant appear?
Historically — from a few days to a few weeks. Following the publication of the analysis by Microsoft Threat Intelligence, cybercriminal groups should be expected to quickly adopt the DNS staging variant. Organizations should treat this as an urgent signal to implement preventive controls.
Does security awareness training effectively protect against ClickFix?
Yes — training is one of the most effective controls, provided it includes ClickFix scenarios. The key message for employees: no legitimate website will ever ask you to open the “Run” dialog and paste a command. This simple rule eliminates the effectiveness of the social engineering lure.
