Chrome's New ClickFix Warnings: Defending Endpoints Against Copy-Paste Social Engineering in 2026

Google announced this week that Chrome is rolling out improved safeguards specifically designed to disrupt ClickFix attacks for users who have Enhanced Protection enabled in Safe Browsing. For defenders, this is a significant signal: a browser vendor is engineering mitigations against a social engineering technique that has become one of the most effective initial-access vectors we've dealt with over the past 18 months — precisely because it bypasses virtually every traditional control.

ClickFix (also tracked as ClearFake and paste-and-run) doesn't exploit a vulnerability. There is no CVE, no zero-day, no malformed file. The attack weaponizes the user: a fake CAPTCHA, a bogus "browser update required" prompt, or a counterfeit error message instructs the victim to open the Run dialog (Win+R), a terminal, or PowerShell, and paste a clipboard payload the page silently copied for them. The user is the exploit. That's why EDRs struggle — from a telemetry standpoint, a user-typed command executed via explorer.exe looks legitimate. Google's move to warn users at the moment of the paste confirms what we've seen in IR engagements: this technique is delivering infostealers, loaders, and ransomware access brokers at scale in 2026.

No CVE is associated with this news item — this is a detection-engineering and hardening problem, and it belongs in every SOC's hunt rotation this quarter.

Technical Analysis

Affected products and platforms

Google Chrome (all supported desktop channels) — the new warnings apply when Safe Browsing Enhanced Protection is enabled. The warnings are rolling out server-side as of the announcement.
Windows is the primary target of ClickFix payloads (Win+R, PowerShell, mshta, cmd), but we've also confirmed campaigns targeting macOS via Terminal and Linux via bash in some intrusions.

How a ClickFix attack chain works (defender's view)

Lure: User lands on a compromised or attacker-controlled site (malvertising, SEO poisoning, phishing links, compromised WordPress properties).
Clipboard poisoning: JavaScript on the page uses navigator.clipboard.writeText() or the legacy document.execCommand('copy') path to place a malicious command on the user's clipboard — often without any visible download or file write to disk.
Instructional social engineering: A fake verification prompt ("Verify you are human") walks the user through Win+R → Ctrl+V → Enter. Because the pasted string is typically obfuscated (leading spaces, invisible characters, or a seemingly benign one-liner), the user can't easily see what they ran.
Execution chain: The pasted command commonly follows this pattern: mshta <url>, powershell -e <base64>, or a download cradle (curl/Invoke-WebRequest piped to iex). This spawns from explorer.exe — a parent process most allowlist logic trusts implicitly.
Payload: Second-stage retrieval of infostealers (Lumma, Vidar families), RATs, or loader frameworks that stage ransomware access.

Exploitation status

This is confirmed active, in-the-wild exploitation at scale — not theoretical. ClickFix-derived intrusions have been a top-three initial access vector in our ransomware response caseload this year. There is no CISA KEV entry because there is no software vulnerability; the abuse surface is user behavior plus legitimate OS binaries (LOLBins). Chrome's new warning interstitial is a compensating control, not a patch.

Why Chrome's control helps — and where it stops

The Enhanced Protection warning interrupts the clipboard-to-execution loop at the browser layer, which is the right choke point. But defenders must assume partial coverage: warnings only fire for Enhanced Protection users, users routinely click through interstitials, and ClickFix lures also arrive via email, QR codes, Discord, and fake update banners outside Chrome's visibility. Endpoint detection remains mandatory.

Detection & Response

The most reliable detection pivot for ClickFix is the process ancestry anomaly: interactive shell or LOLBin execution with explorer.exe as the parent (the Run dialog / paste-and-run signature) combined with network-download or obfuscation indicators in the command line. A second high-fidelity pivot is the RunMRU registry artifact, which records exactly what was typed or pasted into Win+R.

Sigma

YAML

---
title: ClickFix Paste-and-Run LOLBin Execution from Explorer
description: Detects common ClickFix payload execution where a LOLBin (mshta, powershell, curl, wscript) is spawned by explorer.exe, consistent with commands pasted into the Windows Run dialog or an interactive shell after clipboard poisoning.
references:
  - https://thehackernews.com/2026/10/google-chrome-adds-clickfix-warnings-to.html
  - https://attack.mitre.org/techniques/T1204/002/
  - https://attack.mitre.org/techniques/T1059/001/
author: Security Arsenal
date: 2026/10/28
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith: '\explorer.exe'
  selection_child:
    Image|endswith:
      - '\mshta.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\curl.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\cmd.exe'
  selection_cli:
    CommandLine|contains:
      - 'http://'
      - 'https://'
      - ' -e '
      - '-enc'
      - '-w hidden'
      - 'iex'
      - 'Invoke-Expression'
      - 'DownloadString'
      - 'bitsadmin'
  condition: selection_parent and selection_child and selection_cli
falsepositives:
  - Legitimate IT administration via Run dialog (rare in most environments)
  - Software deployment tools launching scripted installers interactively
level: high
---
title: Suspicious RunMRU Entry Indicating Pasted Malicious Command
references:
  - https://thehackernews.com/2026/10/google-chrome-adds-clickfix-warnings-to.html
  - https://attack.mitre.org/techniques/T1204/002/
description: Detects write activity to the Windows Run dialog MRU registry key containing obfuscation or download-cradle patterns characteristic of ClickFix paste-and-run commands.
author: Security Arsenal
date: 2026/10/28
status: experimental
logsource:
  category: registry_set
  product: windows
detection:
  selection_key:
    TargetObject|contains: 'Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\RunMRU'
  selection_value:
    Details|contains:
      - 'powershell'
      - 'mshta'
      - 'curl '
      - ' -e '
      - '-enc'
      - 'iex'
      - 'certutil'
      - 'regsvr32'
      - 'rundll32'
  condition: selection_key and selection_value
falsepositives:
  - Administrators testing commands via the Run dialog
level: medium

Microsoft Sentinel / Defender KQL

This hunt surfaces the ClickFix execution signature across your estate: explorer-spawned LOLBins with network or obfuscation indicators in the command line. Pivot on the initiating account to find the lure page URL in browser telemetry.

KQL — Microsoft Sentinel / Defender

let Lolbins = dynamic(["mshta.exe", "powershell.exe", "pwsh.exe", "curl.exe", "wscript.exe", "cscript.exe", "cmd.exe", "certutil.exe", "bitsadmin.exe", "regsvr32.exe"]);
let SuspiciousCli = dynamic(["http://", "https://", " -e ", "-enc", "-w hidden", "iex", "Invoke-Expression", "DownloadString", "DownloadFile", "FromBase64String"]);
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName =~ "explorer.exe"
| where FileName in~ (Lolbins)
| where ProcessCommandLine has_any (SuspiciousCli)
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine,
          InitiatingProcessCommandLine, ProcessId, SHA256, FolderPath
| order by TimeGenerated desc

Velociraptor VQL

Use this artifact for fleet-wide sweeping during an IR engagement or scheduled hunt. It enumerates running processes with explorer.exe as parent and flags LOLBins whose command lines contain download-cradle or obfuscation patterns.

VQL — Velociraptor

-- Hunt ClickFix-style execution: LOLBin children of explorer.exe with suspicious command lines
SELECT Pid,
       Ppid,
       Name,
       Exe,
       CommandLine,
       Username,
       CreateTime,
       get(field='ParentExe') AS ParentExe
FROM pslist()
WHERE ParentExe =~ 'explorer\.exe$'
  AND Name =~ '(?i)(mshta|powershell|pwsh|curl|wscript|cscript|cmd|certutil|bitsadmin|regsvr32)\.exe$'
  AND CommandLine =~ '(?i)(https?://|-enc| -e |iex|Invoke-Expression|DownloadString|FromBase64String|-w hidden)'

Remediation & Hardening Script (PowerShell)

This script enforces Chrome Enhanced Protection via policy (so users cannot silently downgrade to standard protection), enables PowerShell Script Block Logging to capture ClickFix payloads post-execution, and audits the RunMRU key for evidence of prior paste-and-run activity. Run elevated; the RunMRU audit section should run in the context of the user being investigated.

PowerShell

# 1. Verify Chrome version and Safe Browsing enforcement capability
$chromeExe = "$env:ProgramFiles\Google\Chrome\Application\chrome.exe"
if (Test-Path $chromeExe) {
    $ver = (Get-Item $chromeExe).VersionInfo.ProductVersion
    Write-Output "[+] Installed Chrome version: $ver"
} else {
    Write-Output "[!] Chrome not found at default path"
}

# 2. Enforce Safe Browsing Enhanced Protection via machine policy
#    0 = disabled, 1 = standard, 2 = enhanced (required for ClickFix warnings)
$policyPath = 'HKLM:\SOFTWARE\Policies\Google\Chrome'
New-Item -Path $policyPath -Force | Out-Null
New-ItemProperty -Path $policyPath -Name 'SafeBrowsingProtectionLevel' -PropertyType DWord -Value 2 -Force | Out-Null
Write-Output "[+] SafeBrowsingProtectionLevel set to 2 (Enhanced) at $policyPath"

# 3. Enable PowerShell Script Block Logging (captures deobfuscated ClickFix payloads)
$sblPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging'
New-Item -Path $sblPath -Force | Out-Null
New-ItemProperty -Path $sblPath -Name 'EnableScriptBlockLogging' -PropertyType DWord -Value 1 -Force | Out-Null
Write-Output "[+] PowerShell Script Block Logging enabled"

# 4. Audit RunMRU for pasted malicious commands (run in target user context)
$mru = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU'
if (Test-Path $mru) {
    $suspect = 'powershell|mshta|curl|certutil|regsvr32|rundll32|iex| -e |http'
    (Get-ItemProperty $mru).PSObject.Properties |
        Where-Object { $_.Value -match $suspect } |
        ForEach-Object { Write-Output "[!] Suspicious RunMRU entry: $($_.Name) = $($_.Value)" }
}

Remediation

Because there is no CVE, "remediation" here means layered compensating controls. In priority order:

Enable and enforce Chrome Enhanced Protection enterprise-wide. Deploy SafeBrowsingProtectionLevel = 2 via GPO/MDM (or chrome://settings/security for unmanaged users). Without it, users do not receive the new ClickFix warnings. Validate rollout with Chrome Browser Cloud Management or your MDM compliance reporting.
Update Chrome to the latest stable channel. The ClickFix warning logic ships server-side but assumes a current client; keep the fleet on the current stable build. Reference: https://chromereleases.googleblog.com/ and the Safe Browsing policy documentation at https://chromeenterprise.google/policies/.
Constrain LOLBin execution. Where feasible, apply AppLocker or WDAC rules blocking or constraining mshta.exe, wscript.exe, and cscript.exe for standard users, and enforce PowerShell Constrained Language Mode on non-admin workstations. Most ClickFix payloads die here.
Harden the human layer. Update phishing simulations and security awareness content to specifically cover paste-and-run lures: fake CAPTCHAs, "press Win+R and paste," and bogus browser update prompts. Users should be trained that no legitimate website will ever ask them to paste a command into their operating system.
Deploy the detections above. Ship the Sigma rules to your SIEM, schedule the KQL hunt daily, and add the VQL artifact to your Velociraptor hunt schedule. Tune the explorer-parent rule against your IT admin baseline first — in well-managed environments this rule should be near-silent.
Enable PowerShell Script Block Logging and Module Logging fleet-wide (Event IDs 4104, 4103) and forward to your SIEM — this captures the deobfuscated ClickFix payload even when the initial command line is Base64-encoded.
Network-layer backstop. Alert on mshta.exe, powershell.exe, and curl.exe making outbound connections to recently registered or uncategorized domains — the second-stage retrieval is almost always the noisiest part of the chain.

If you discover confirmed ClickFix execution on an endpoint, treat it as a full intrusion: isolate the host, acquire triage (RunMRU, clipboard history if enabled, browser history/cache, PowerShell 4104 events), hunt laterally for the second-stage payload, and reset credentials for any session tokens or browser-stored secrets on the affected machine — infostealers typically exfiltrate within minutes of execution.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub