ClickFix Forensics: Proving Execution Beyond the Browser
A deep dive on ClickFix, mapping fake CAPTCHA lures to endpoint code execution, covering investigation, response, and preventative controls.
The Attack Explained.
ClickFix, sometimes described as “fake CAPTCHA” execution, is a social engineering technique where the attacker deliberately moves the critical step of the intrusion onto the user.
Instead of exploiting a vulnerability automatically, the attacker convinces the victim to run the payload themselves, most commonly by opening the Windows Run dialog and pasting a command presented as a “verification” step.
This user driven execution is a large part of why ClickFix has been effective against organisations with otherwise mature controls.
What ClickFix actually is.
At a high level, ClickFix is an interaction pattern, not a single malware family. The attacker’s objective is to get a user to perform a sequence of actions that results in code execution under the user’s context. The lure is usually presented as a familiar web experience such as a CAPTCHA prompt, an “I am not a robot” verification, or a fake error banner that claims a quick manual fix is required.
ClickFix is described as an attack chain that commonly begins with phishing, malvertising, or a compromised website, then leads the user to a visual lure that instructs them to run a command, specifically because that user interaction can bypass some conventional automated detections.
Why it works so well.
ClickFix succeeds because it exploits normal problem solving behaviour. The page looks like a legitimate friction point that users are conditioned to complete quickly, and the instructions are presented in a “helpdesk style” voice that implies compliance is routine.
Technically, it also shifts the attacker’s risk. If the user runs the command, the execution often happens in a way that looks like legitimate administrative activity, especially in environments where PowerShell is widely used and script execution is not tightly controlled.
The ClickFix Execution Pathway In Windows.
Although the exact payload varies, many ClickFix chains have a similar structure:
The site presents a prompt that encourages a copy and paste action. The copied content is a command, or a small “stager” that pulls the real payload from the internet. This is frequently designed to blend in with normal Windows tooling, using legitimate signed binaries that can execute script content.
In real incidents, you’ll often see execution via PowerShell, cmd, rundll32, or mshta. mshta is particularly notable because it is a Windows native binary designed to execute HTA script content and has been repeatedly abused as an execution proxy.
Once the initial command runs, typical next steps depend on the operator and payload, but commonly include downloading a second stage, establishing persistence, credential access, browser data harvesting, and then lateral movement or cloud pivoting where possible.
Detection.
RunMRU (Most Recently Used).
RunMRU (Most Recently Used) is a Windows registry key that stores a list of the last 26 commands entered in the Run dialog (Win + R) on a per-user basis. The command’s execution order can be obtained from the “MRUList” value in the key. It keeps an ordered list (left being most recent) of recently used commands (hence the name MRU).
To confirm whether code was actually entered and executed into Run, you can check Run history in the registry:
NTUSER.dat\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RunMRU
Review the most recent entries. If they followed the prompt, you will typically see something like PowerShell, cmd, mshta, rundll32, or a base64 encoded one liner recorded there. If you are logged in as the user:
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU
If you are inspecting another profile, load NTUSER.dat and check:
HKU\<SID>\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU
This is useful because it shows what was entered, not just what was clicked in the browser. The MRUList (REG_SZ) string tells you the order in which the commands were entered.
If you do see a malicious record, treat this as one input, not the conclusion. You still need to tie it to process execution, network activity, and post execution actions to understand impact.
What To Expect After Execution.
If you are investigating a suspected ClickFix event, it helps to think in terms of what an operator needs immediately after they land:
They need reliability, so they often use short stagers and then pull the rest from the network.
They need stealth, so they often use built in tooling and reduce on disk footprint.
They need access, so they will frequently attempt credential theft, token theft, or session hijacking, especially if the user has privileged access.
This is why a ClickFix investigation should not stop at “did something run”. The deeper question is what access was gained, what was touched, and what capability was established afterwards.
Investigation.
Step 1: Establish scope and time boundaries.
Start with time anchoring. Determine when the user saw the prompt, when they took the action, and what device they used. If you have EDR, this becomes an initial timeline exercise: browser process, clipboard related activity if available, then the first suspicious child process and any outbound connections that follow.
Where possible, treat this as an incident until you can prove otherwise. ClickFix is designed to create uncertainty and urgency.
Step 2: Identify the first execution and the parent chain.
The most useful early signal is the process tree. You are looking for an unusual transition from a user initiated action into a scripting or execution host.
In many environments, you will see one of two patterns:
A browser process that leads quickly into script execution via a Windows binary.
A user opened execution path such as the Run dialog followed by a scripting host.
At this stage, capture command line arguments, parent process, network connections, and any spawned child processes. This is where you often find the “stager” that reveals the next infrastructure and payload stage.
Step 3: Collect endpoint evidence that reflects user driven execution.
This is where Windows artefacts matter. You want artefacts that record what the user actually typed or pasted, rather than what the browser displayed.
Step 4: Hunt for follow on behaviours, not just the first command.
Once you identify the first execution, pivot into “what changed” and “what persisted”.
Look for new scheduled tasks, new services, unusual registry autoruns, newly dropped executables in user writeable locations, unusual PowerShell usage patterns, and outbound connections to new domains or IPs. If your EDR supports it, hunt for unusual child processes of common scripting hosts.
If mshta is present in the chain, treat it as higher risk because it can execute script content embedded in HTML and is frequently used as a proxy for code execution.
Step 5: Expand to identity and cloud where applicable.
ClickFix is often the first step, not the final objective. If the compromised user has access to Microsoft 365 or other SaaS platforms, you should treat identity as in scope immediately.
This typically means reviewing sign in activity, risky sign ins if you have them, unusual OAuth consent grants, mailbox rules, forwarding changes, unusual file sharing activity, and new devices or tokens. The exact telemetry depends on your stack, but the principle is consistent: verify whether the attacker converted endpoint execution into durable access elsewhere.
Responding to an attack.
A solid ClickFix response usually needs to cover containment, credential and session hygiene, eradication, and resilience.
Containment should focus on isolating the affected endpoint and limiting further outbound access where feasible, especially if you have evidence of a live second stage.
Credential and session hygiene should assume the user context is compromised. Password reset alone may not be sufficient if tokens were captured, so you should revoke sessions where your identity platform allows it and ensure privileged access is reviewed.
Eradication should remove persistence mechanisms, remediate dropped binaries, and validate that the initial execution vector is no longer present.
Resilience should include closing the specific execution pathways and tightening controls that make ClickFix succeed in the first place.
Prevention Controls That Meaningfully Reduce ClickFix Risk.
ClickFix relies heavily on built in tools being available for arbitrary execution. The most effective prevention work therefore tends to reduce easy execution paths and strengthen detection where you cannot remove them.
Microsoft Defender for Endpoint Attack Surface Reduction rules are a strong baseline in many Windows estates, especially where Office based initial access is common. These rules are documented and can block common child process creation patterns that attackers rely on.
Beyond ASR, consider application control approaches such as allow listing for scripting hosts, restrictions on LOLBins that are rarely used in your organisation, and tighter PowerShell governance through logging, constrained execution, and script signing where it is practical. Pair this with web filtering, stronger browser controls, and user education that explicitly calls out the “copy and paste a verification command” pattern.
The important point is that ClickFix is not beaten by a single setting. It is reduced by layered friction: fewer execution paths, stronger visibility, and faster containment when the tactic slips through.
You could also consider blocking the Run Dialog for end users, if it isn’t needed.
Closing Thoughts.
ClickFix is a reminder that some of the most damaging intrusions still begin with persuasion, not exploitation. If your investigation approach centres on process trees, endpoint artefacts, and follow on behaviours, you can move from uncertainty to clarity quickly, and you can shape controls that make the tactic far less reliable for attackers.
