DNS-based ClickFix with nslookup is a newly observed ClickFix variant in which attackers use social engineering to persuade users to initiate execution via the Windows Run dialog while the next stage is delivered over DNS. This increases the likelihood of bypassing traditional web security controls, even though the overall chain still depends heavily on user interaction.

DNS-based ClickFix with nslookup abuses the Windows Run dialog and DNS lookups for malware staging

Recent reports describe a ClickFix variation that retains the familiar pattern of “the user runs an apparent fix” while changing the underlying delivery mechanism. Whereas many ClickFix campaigns rely on web downloads as the next step, DNS-based ClickFix with nslookup brings DNS to the forefront as a staging channel. The Hacker News summarizes this development as a DNS-based ClickFix technique in which a DNS lookup provides the foundation for the next execution stage.

Why ClickFix remains so effective as social engineering

ClickFix is primarily a psychological attack approach. Execution is not forced; it is triggered by a convincingly staged scenario. Victims may see a supposed verification step, an error message, or a seemingly legitimate repair instruction and are then prompted to perform an action themselves. This logic, in which user interaction is the decisive trigger, is explained by Microsoft in its security blog on the ClickFix technique. A key point is that, from the perspective of many security controls, the action initially appears “legitimate” because it is deliberately initiated by the user rather than by a classic drive-by exploit.

Technical core of the new variant

What is new in DNS-based ClickFix with nslookup is the combination of the Run dialog and DNS-assisted staging. In an update, Microsoft Threat Intelligence describes how attackers lead victims to initiate execution that performs a DNS lookup against a hard-coded external DNS server. The output is then processed so that a specific field is extracted from the DNS response and used as the next stage. Microsoft characterizes DNS in this context as a lightweight staging or signaling channel that is less dependent on HTTP/S infrastructure than traditional web retrieval and can blend more easily into “normal” traffic in many environments.

For security teams, it is particularly relevant that the observed variant does not necessarily use the endpoint’s default resolver. That provides a clear discriminator for network and endpoint detection, because direct DNS connections to external resolvers are atypical in well-hardened enterprise environments.

Observed infection chain up to ModeloRAT

According to Microsoft, the chain does not end with DNS staging. In the described campaign, a further download and execution path follows the second stage, including a portable Python environment and additional scripts. Microsoft cites reconnaissance and discovery activity as elements of this chain, along with persistence mechanisms in the user context. A remote access trojan named ModeloRAT is mentioned as the final payload. This makes it clear that DNS-based ClickFix with nslookup is less about a new malware family and more about a delivery and staging mechanism that can bring existing payloads to target systems more reliably.

From a defensive standpoint, it is also relevant that Microsoft notes blocking via Microsoft Defender using a ClickFix-specific machine-learning model. In addition, the description includes example persistence artifacts that may appear in the user profile and in the Startup context. Such artifacts are particularly valuable because they provide indicators of the tactic independent of the specific payload.

Why DNS-based ClickFix with nslookup is harder to spot in enterprises

Over the past few years, many organizations have centralized and strengthened HTTP/S controls, for example through proxy architectures, URL filtering, TLS inspection, or security service edge controls. DNS, by contrast, often remains an area with looser governance, less telemetry, or weaker correlation to endpoint events. DNS-based ClickFix with nslookup can exploit this asymmetry because staging no longer has to occur via web requests. BleepingComputer describes the observed variant as particularly tricky because DNS responses can act as a carrier for the next stage and the content can be swapped flexibly without classic web indicators taking center stage.

A sober assessment is important here. DNS-based techniques are not inherently invisible, but they shift the detection problem into a telemetry layer that often does not receive the same priority in SOC workflows as web or EDR signals. This increases the risk that a campaign initially appears to be merely a “weird DNS anomaly” even though it may already be triggering an execution chain.

Practical detection approaches for SOC and threat hunting

Reliable detection for DNS-based ClickFix with nslookup is built on correlation. A single DNS lookup is rarely meaningful on its own, but the combination of multiple signals often is. Process chains that suggest an interactive context are especially useful, for example when shell and DNS utilities appear in close temporal proximity to user actions. Another strong signal can be DNS activity that does not traverse authorized resolvers but is sent directly to an external server.

On the endpoint side, the combination of command-line telemetry and file system events is worthwhile. Newly created persistence artifacts in the user profile or Startup context are suspicious when they occur shortly after anomalous DNS activity. In addition, the ClickFix baseline pattern remains a key indicator, because many campaigns rely on copy and paste into the Run dialog or a terminal. The ClickFix mechanics described in the Microsoft blog therefore remain a solid foundation for awareness, use-case design, and detection engineering.

Hardening that directly addresses this variant

The most effective technical countermeasure is a strict DNS egress policy. If endpoints are allowed to use only authorized resolvers and direct DNS connections to the internet are blocked, the attack surface for DNS-based ClickFix with nslookup is significantly reduced, or attempts at least become highly visible. In addition, DNS telemetry should be captured in a way that deviations from resolver standards, unusual query patterns, and near-real-time execution events can be correlated.

Because ClickFix still depends on user interaction, awareness remains a core control. Training tends to be most effective when it targets concrete behavior patterns, such as the fact that reputable providers typically do not supply “fix” instructions that require pasting commands from unknown websites into the Run dialog.

Conclusion

DNS-based ClickFix with nslookup illustrates how quickly established social engineering techniques can adapt to modern control landscapes. The variant combines a familiar ClickFix narrative with DNS staging and shifts visibility away from classic web indicators toward DNS and process correlation. Organizations that control DNS egress, correlate endpoint telemetry effectively, and embed ClickFix-style user behaviors into awareness and detection reduce the risk from these campaigns substantially, even as payloads and infrastructure continue to evolve.