ClickFix: the attack that makes the victim run the malware

Defender fired a behavioural alert — a SuspClickFix detection under a user's profile, flagging a blocked PowerShell execution. Defender caught and killed the process automatically, so the headline was reassuring. But "the EDR blocked it" is the beginning of the investigation, not the end: the interesting questions are what did the user actually run, did anything survive, and where else does this identity exist.

01What ClickFix is

Social engineering that outsources execution to the victim.

ClickFix is a technique, not a piece of malware. The victim lands on a page — a fake CAPTCHA, a "your browser needs to be fixed" error, a bogus document viewer — that instructs them to do three keystrokes: press Win+R, then Ctrl+V, then Enter. The page has silently copied a malicious command to the clipboard. The user, believing they're completing a verification step, pastes it into the Run dialog and executes it themselves.

Why attackers love it

It sidesteps a lot of defenses at once. There's no malicious attachment to scan, no drive-by download to block — the user manually launches the command, so it inherits their trust and their session. It defeats "don't open attachments" training because nothing is attached. The entire attack is a person following friendly-looking instructions, which is exactly why it works.

The whole trick is the three keystrokes. Because the user executes the command manually, there's nothing for an attachment scanner or download filter to catch — the malicious step looks like a routine "verify you're human" action.

02The RunMRU artifact — the forensic gold

Windows records what gets typed into the Run box. That's your evidence.

Here's the detail that makes ClickFix investigable: every command run through the Run dialog is written to a registry key, RunMRU (Most Recently Used). So when a user pastes an attacker's command, Windows helpfully keeps a copy of exactly what they pasted. That's your ground truth — it tells you what actually executed, not what you're guessing executed.

# read the Run dialog history — the command the victim pasted lives here
Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU"

# or via reg.exe
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU"

Read the values, capture them as evidence (screenshot / export), and you have the literal payload — usually a heavily obfuscated powershell -enc … or a command that pulls a second stage from a remote host. That string gives you the C2 domains to block and confirms what the payload tried to do. Only after you've preserved it do you clear the entries as part of cleanup.

Preserve before you purge

RunMRU is often the only record of the exact command. Export it before clearing it, and also check %AppData% / %LocalAppData% for dropped folders or staged scripts the command may have written. Wipe the artifact first and you lose the IOCs you need to block the campaign everywhere else.

03Full endpoint remediation

EDR blocked the payload. You still clean the residue and re-verify.

Even with the payload blocked, ClickFix pages frequently ride alongside adware and browser hijackers, and the Run command may have left registry crumbs. The cleanup that actually returns the box to trusted:

# 1. after preserving RunMRU, clear the malicious entries
# 2. remove residual scripts / dropped folders under %AppData% / %LocalAppData%
# 3. run layered scanners, not just the EDR that already fired
-  Microsoft Defender  → full scan (confirm clean)
-  a second-opinion anti-malware pass → quarantine PUPs
   (ClickFix pages often bundle hijacker "browsers" and OEM junk)
-  an adware cleaner → remove heuristic Winlogon entries / OEM utilities
# 4. reboot, then re-scan to confirm nothing re-spawns

The second-opinion pass matters: the EDR catches the sharp end (the PowerShell), but potentially-unwanted programs and hijacker browser extensions that came along for the ride often sit below its threshold. Clearing those is what stops the "it keeps coming back" follow-up ticket.

04Don't stop at the endpoint — harden the identity, in every tenant

The command ran as the user. Treat the account as potentially exposed.

A command executed in the user's session could have touched their credentials or tokens, so the account gets the full hygiene treatment — and here's the trap: many users exist in more than one tenant (an acquisition, a managed-client relationship, a partner org). Hardening only the tenant that alerted leaves a second, identical door open.

# do this in EVERY tenant the identity exists in, not just the one that alerted
- reset the account password
- revoke all active sign-in sessions (invalidate any stolen tokens)
- re-validate MFA methods / security info (remove anything unrecognized)
- audit the mailbox for inbox rules, forwarding, and sweep rules

# retain evidence of each:
- password-reset confirmation · session-revocation log
- MFA/security-info review · mailbox-rule audit result

05Block the campaign network-wide

Turn the payload's domains into tenant-wide blocks.

The domains you pulled from the RunMRU command (and from the second-stage fetch) go into the Tenant Allow/Block List as blocked indicators, so if the same campaign hits another user, the callback fails. Then keep monitoring for re-alerts or fresh outbound attempts to those domains — a clean scan today doesn't retire the IOCs.

The lesson

ClickFix turns the user into the delivery mechanism, so "the EDR blocked it" isn't closure. Pull the RunMRU key to recover the exact command, preserve it before cleanup, sweep the PUPs the EDR ignored, and harden the identity in every tenant it lives in — then block the campaign's domains everywhere. The endpoint is one machine; the identity and the IOCs are the whole estate.