Trackr.Live The landing site for Trackr Services
§ CM

ClickFix’s Cleanest Artifact Is RunMRU. The 2026 Variants Walked Away From It

By AutoCypher ·

ClickFix won by deleting the part of the kill chain your stack was built to watch. No macro-enabled document, no script dropped to disk by a loader, no second-stage download you can catch at the proxy before the user double-clicks. The user opens the Run dialog themselves, pastes a command they were told would “verify” they’re human or “fix” a rendering error, and presses Enter. The execution is hand-delivered by the person sitting at the keyboard, which means your entire malicious-attachment and macro-blocking apparatus never gets a vote. Per ESET’s H1 2025 threat report, ClickFix detections jumped 517% over six months and reached roughly 8% of all blocked attacks, putting it second only to phishing as an initial access vector. That’s not an emerging-threat footnote anymore. That’s a top-of-funnel problem most SOCs are still detecting one variant behind.

The good news, and it is genuinely good for a while, is that the technique leaves a clean artifact. When a user types or pastes into the Run dialog and hits Enter, Windows records the string under HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU. Each entry lands in a lettered value (a, b, c…) followed by a \1 delimiter that Explorer appends, and MRUList holds the ordering. The key records what the user submitted when they hit Enter — what was launched, not whether the payload then ran cleanly — so a working ClickFix execution writes its command string into the registry as plain text. For once the attacker’s own delivery mechanism hands you the indicator of compromise in a parseable field.

So you write the obvious detection. Then you find out where it breaks.

What the registry rule actually catches

The SigmaHQ rule for this watches Sysmon Event ID 13 (registry value set) where TargetObject contains \Explorer\RunMRU\ and Details carries both an HTTP/HTTPS string and a suspicious token — powershell, cmd, mshta, certutil, bitsadmin, curl, or CAPTCHA-flavored words like captcha, verification, botcheck. In Splunk that’s an XmlWinEventLog search on EventCode=13 with a TargetObject filter; the Elastic equivalent keys off registry.path and registry.data.strings in the Sysmon integration index. Either way the logic is sound and the volume is friendly. Most users barely touch the Run dialog from one quarter to the next, so RunMRU writes are low-frequency per host — admin-, IT-, and helpdesk-heavy populations are the exception and want a per-host baseline before you trust the volume — and the subset that also contains a URL plus an interpreter name is small enough that a true hit is rarely buried.

Here’s the first thing that bites you: Sysmon probably isn’t logging the key at all. RunMRU lives under HKCU, and a lot of the community Sysmon configs that shops inherited — the SwiftOnSecurity baseline and its many forks — lean heavily on HKLM registry coverage and either exclude or simply never include per-user Explorer subkeys. If your RegistryEvent section doesn’t carry an explicit include for \Explorer\RunMRU, your beautiful detection is matching against events that never arrive. Check the index before you trust the rule. Run a EventCode=13 TargetObject="*RunMRU*" search over the last 30 days across a populated host group; if it returns zero on machines where people definitely use Win+R, your config is the problem, not the absence of attacks.

The second bite is the whitespace evasion, and this one is deliberate. The clipboard payload is built so the part the victim sees in the Run box reads as something reassuring — a fake “Ray ID” or a checkmark and some verification text — while the actual command is shoved far to the right behind a long run of spaces, or hidden after a comment delimiter. When that string lands in RunMRU, the leading characters are benign and the dangerous token is way downfield. A naive Details match that anchors near the front of the string misses it. SigmaHQ shipped a separate rule specifically for anomalous space-character runs in the RunMRU path for exactly this reason. If you only deploy the keyword rule and not the whitespace-anomaly rule, you’re covering the lazy operators and missing the ones who read the same detection blogs you did.

The 2026 problem: they stopped using the Run dialog

This is the part that matters, and it’s why anchoring your whole ClickFix program on RunMRU is a trap. The artifact is clean precisely because the Run dialog is an old, well-instrumented path — so attackers moved off it.

A variant documented in early 2026 swaps the instruction from Win+R to Win+X, then I, which opens Windows Terminal (wt.exe) directly on Windows 11 — or PowerShell on Windows 10, where that same chord predates the Terminal default. Either way: no Run dialog, no RunMRU write. The user pastes into a terminal instead, and your registry detection sees nothing because nothing touched the registry key. Another strain skips PowerShell entirely, walking the victim through cmdkey to stash a credential and regsvr32 to load a DLL from an attacker-controlled SMB share over a UNC path — living-off-the-land binaries that your powershell-keyword Details filter was never going to flag. There’s also CrashFix, a malicious Chrome extension Huntress flagged in January 2026 that hammers chrome.runtime port connections to wedge the browser as part of the social-engineering setup. The technique mutates monthly. Tie your detection to one input method and you are permanently one disclosure behind.

So RunMRU stays in your kit. It’s cheap, it’s specific, and it catches the high-volume commodity campaigns that still use the Run dialog because it still works on most users. But it is necessary-and-insufficient, and you have to treat it that way in the rule catalog — tagged as a known-narrow signal, not as “ClickFix coverage” with a green check next to it.

The signal that survives the variant churn

What every one of these variants shares is the shape underneath the input method: a GUI-interactive, user-facing process spawning a command interpreter that then reaches the network. Explorer, a browser, or wt.exe as the parent. powershell.exe, cmd.exe, mshta.exe, regsvr32.exe, rundll32.exe as the child. Outbound egress or a UNC mount shortly after. That ancestry is the durable thing, and it’s where I’d put the weight of the detection budget instead of the registry key.

The catch is that this signal is loud where RunMRU is quiet. explorer.exe spawning powershell.exe is a thing that happens all day in a shop with any meaningful population of developers, IT admins, or packaged software that shells out. Run a raw Sysmon Event ID 1 (or Windows 4688 if you don’t have Sysmon — make sure command-line process auditing is turned on first, or the stacked conditions below have nothing to match) query for ParentImage ending in explorer.exe and Image ending in powershell.exe and you’ll get a wall of results, most of them an admin pasting ipconfig or a dev launching a build script. That’s the false-positive engine, and it’s why you can’t ship the bare ancestry rule into the notable-event pipeline without flooding the SOC.

Make it survivable by stacking conditions instead of relying on the parent-child pair alone:

  • Command-line content that smells like a downloader or obfuscation: -w hidden, -nop, -enc, IEX, DownloadString, iwr, or a curl/certutil reaching an external host. One of these alongside the GUI-to-interpreter ancestry is far more specific than the ancestry by itself.
  • Egress to a freshly-seen or low-reputation domain within a short window of the spawn. If your EDR exposes the process network events, correlate the child interpreter to its first outbound connection and weight on domain age or rarity.
  • A RunMRU write or, for the terminal variants, a PowerShell console-history or script-block-logging artifact in the same session — PSReadLine’s ConsoleHost_history.txt or Event ID 4104, since Windows Terminal emits no standardized “paste” event — when present, as a confidence booster rather than a gate, so the rule still fires on the wt.exe variant that writes no registry key.

Risk-based alerting is the right home for this. Don’t make any single condition a standalone notable. Attach a modest risk score to the GUI-spawned interpreter, a larger one to the obfuscated command line, another to the rare-domain egress, and let the per-host risk total cross a threshold before anything pages a human. As a starting anchor to argue with — say 10 for the GUI-spawned interpreter, 40 for the obfuscated command line, 30 for the rare-domain egress, paging at 60 — then pick your own number, watch it for a week, move it. The first tuning round will be dominated by your own build agents, packaging tools, and the three power users who live in PowerShell. Carve those out by host and signed-binary parentage, not by suppressing the rule. Expect the initial noise to be ugly and the post-tuning volume to be a small fraction of it; the exact ratio depends entirely on how dev-heavy your fleet is and whether your EDR gives you reliable parent-process trees (in some VDI and thin-client deployments the parent-process data is patchy, and you’ll want to confirm coverage before you trust an absence of alerts).

Where it maps, and the part the SOC can’t fix alone

ClickFix is a monitoring-and-hardening problem with a real human-layer dependency, and the control mapping reflects that — this isn’t a patch-and-done CVE. The controls below map to NIST SP 800-53 Rev. 5.

Control What it does for ClickFix
SI-4 The detections above — registry, process ancestry, egress correlation. System monitoring is the core control.
SI-3 Malicious code protection: EDR behavioral blocking on the spawned interpreter and downloaded second stage.
AU-2 / AU-12 Audit generation. PowerShell script block logging (Event ID 4104) and Sysmon registry/process events are the evidence the detections run on. Without script block logging you’re blind to the encoded payloads.
CM-7 Least functionality. Disabling the Run dialog via Group Policy (the “Remove Run menu from Start Menu” policy under User Configuration\Administrative Templates\Start Menu and Taskbar, which sets NoRun under HKCU\...\Policies\Explorer) where it isn’t needed kills the commodity variant outright. The blunt instrument that actually works on locked-down user populations.
CM-6 Configuration settings. PowerShell constrained language mode and AllSigned execution policy raise the cost of the payload stage — but execution policy is not a security boundary on its own, so enforce constrained language mode through WDAC or AppLocker if you want it to actually hold.
AT-2 Awareness training, specifically social-engineering recognition. ClickFix targets the user’s instinct to self-fix. This is one of the rare cases where user training is a load-bearing control, not a compliance checkbox.

The CM-7 line deserves emphasis because it’s the one defenders underuse. If you run a tiered or otherwise locked-down user population — call center, clinical workstations, anything that isn’t a developer’s daily driver — disabling the Run dialog through GPO removes the commodity attack path with zero detection overhead. It does nothing for the wt.exe or browser-paste variants, and your power users will revolt if you push it fleet-wide, so it’s a scoping decision, not a global switch. But on the right hosts it’s the cheapest win available.

RunMRU is a good detection that ages badly. Deploy it, log the key your Sysmon config is probably dropping, and label it for what it is: a narrow catch for last season’s variant. Then put your real engineering effort into the ancestry-plus-egress signal that doesn’t care which keyboard shortcut the victim was told to press. The input method is the attacker’s variable. The GUI-process-spawns-interpreter-spawns-network shape is the constant, and constants are what you build detections on.

Sources