Back to Intelligence

Defend Against DNS-Based ClickFix: Abusing Nslookup for Payload Staging

SA
Security Arsenal Team
February 23, 2026
5 min read

Defend Against DNS-Based ClickFix: Abusing Nslookup for Payload Staging

Social engineering remains the most effective initial access vector for cybercriminals, but the tactics are evolving rapidly. At Security Arsenal, we are closely tracking a new mutation of the "ClickFix" campaign recently disclosed by Microsoft. This variant abandons traditional malicious links in favor of abusing a built-in Windows administrative tool: nslookup.

By coercing users into performing a DNS lookup themselves, attackers are bypassing traditional email filters and leveraging the trust placed in fundamental network protocols to stage malware.

The Threat: Living Off the Land via DNS

The core of this attack remains the familiar "ClickFix" ruse. A target receives a phone call or sees a browser pop-up claiming their computer is infected or needs an update. The urgency prompts the victim to open a command-line interface.

However, instead of asking the user to download a file, the attacker provides a command string involving nslookup. This tool is standard on every Windows machine for querying Domain Name System (DNS) servers to resolve domain names to IP addresses.

The Attack Vector Explained

  1. The Hook: The attacker convinces the user to run a specific command, ostensibly to "verify the connection" or "check the license key."
  2. The Lookup: The command forces the user's machine to query a malicious domain controlled by the attacker. Crucially, they are looking for TXT records or specific subdomains that contain encoded data.
  3. The Staging: The response from the DNS server isn't an IP address—it is the next stage of the attack. This could be a Base64 encoded PowerShell script, a malicious URL, or a command fragment.
  4. The Execution: The attacker instructs the victim to copy the resulting text string and paste it back into the PowerShell terminal to execute it.

This technique is insidious because it uses a "Living off the Land" (LotL) binary. Since nslookup is a legitimate administrative tool, it is rarely blocked by firewalls or application allow-listing policies. Furthermore, because the traffic travels over port 53 (DNS), it often slips through network perimeter defenses that scrutinize HTTP/HTTPS traffic but treat DNS as benign infrastructure.

Technical Analysis and TTPs

From a threat-hunting perspective, this behavior deviates significantly from standard nslookup usage patterns.

  • Parent Process: Legitimate nslookup is rarely spawned directly from explorer.exe or by non-administrative users in a corporate environment without context.
  • Command Line Arguments: Standard lookups are simple (e.g., nslookup google.com). Attackers use flags to specify specific record types (e.g., -type=TXT) and obscure domains.
  • Payload Size: DNS TXT records have size limits, meaning attackers may fragment payloads or use them as pointers to download larger payloads from web servers once the foothold is established.

Detection and Threat Hunting

To identify this activity within your environment, we recommend deploying the following queries and scripts. These focus on identifying anomalous usage of nslookup and suspicious DNS record requests.

KQL Query (Microsoft Sentinel / Defender)

This query looks for nslookup processes spawned by the Windows shell, specifically checking for arguments that request TXT records (often used for data exfiltration or staging).

Script / Code
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName == "nslookup.exe"
| where ProcessCommandLine has "-type" or ProcessCommandLine has "-querytype"
| extend ParentProcess = InitiatingProcessFileName
| where ParentProcess in ("cmd.exe", "powershell.exe", "explorer.exe")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, ParentProcess, FolderPath
| order by Timestamp desc

PowerShell Script (Local Analysis)

SOC analysts can use this script on potentially compromised endpoints to parse the local DNS client cache for suspiciously long TXT records, which might indicate remnants of a ClickFix attack.

Script / Code
function Get-SuspiciousDnsCache {
    $dnsCache = Get-DnsClientCache
    
    foreach ($entry in $dnsCache) {
        # Filter for TXT records (Type 16) or suspiciously long data entries
        if ($entry.Type -eq 16 -or $entry.Data.Length -gt 50) {
            [PSCustomObject]@{
                Entry       = $entry.Entry
                Name        = $entry.Name
                Type        = $entry.Type
                DataLength  = $entry.Data.Length
                Data        = $entry.Data
                TimeToLive  = $entry.TimeToLive
            }
        }
    }
}

Get-SuspiciousDnsCache | Format-Table -AutoSize

Bash Command (Linux DNS Log Check)

For environments utilizing BIND or similar DNS servers, checking your query logs for high volume of TXT requests to non-internal domains is a strong indicator of this activity.

Script / Code
grep "TXT" /var/log/named/query.log | awk '{print $1, $6, $8}' | grep -v "IN	TXT\t"*"yourdomain.com" | tail -n 50

Mitigation Strategies

Preventing these attacks requires a defense-in-depth approach that combines user awareness with technical controls.

  1. Application Control (AppLocker/WDAC): Strictly control which users can run nslookup.exe. In most standard user workflows, there is no need for a marketing or HR employee to perform manual DNS lookups via the command line. Create a policy that blocks nslookup.exe for non-administrative users.

  2. DNS Filtering: Implement DNS-layer security solutions (such as Cisco Umbrella or Microsoft Defender DNS) that can identify and block requests to domains known for hosting malicious TXT records or command-and-control (C2) infrastructure.

  3. Attack Surface Reduction (ASR) Rules: Enable ASR rules in Microsoft Defender to block Office apps from creating child processes and abusing Win32 API calls, limiting the initial blast radius if a user is tricked into opening a malicious document that tries to automate this process.

  4. User Education: While technical controls are vital, the human element is the primary vector here. Train employees to recognize the "Tech Support Scam". Emphasize that legitimate IT support will never ask them to run obscure command-line tools like nslookup, certutil, or regsvr32.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub

socmdrmanaged-socdetectionclickfixdns-tunnelingsocial-engineeringthreat-hunting

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.