Common signs include fake browser errors, CAPTCHA or verification prompts, instructions to open PowerShell or the Windows Run dialog, and HTML attachments that claim to fix a document or software issue. Other clues are copied commands that include encoded scripts, references to common enterprise tools, and requests to manually paste commands from a webpage.
How ClickFix campaigns reveal themselves before the user ever runs a command
ClickFix works because it looks like routine troubleshooting, so the earliest signs are usually social and visual rather than purely technical. Watch for browser pages or attachments that try to normalise an error, redirect the user into a “verification” flow, and then move them toward manual command execution. The lure is usually designed to bypass caution, not to exploit a browser bug.
One of the strongest indicators is the sequence itself: a fake prompt, followed by an instruction to open a system utility, followed by pasted or copied commands. That pattern is especially suspicious when the page claims to fix a document, video, printer, login, or software issue, because the objective is to shift the victim from passive viewing to active execution.
HTML attachments and web pages that present copy-and-paste recovery steps are also important clues, particularly when the text uses urgency, time pressure, or “help desk” language. A legitimate support flow usually does not require the user to paste an encoded script into PowerShell or the Windows Run dialog. When the instructions ask for manual execution, the page itself is part of the attack chain.
What makes the lure technique distinctive?
ClickFix campaigns are notable because the malicious content is often less about exploit code and more about instruction design. The attacker wants the user to execute the payload willingly, so the page may mimic CAPTCHA checks, browser security messages, or enterprise software notifications. That makes the campaign easy to miss if teams only look for traditional phishing markers such as credential fields or malicious links.
Another clue is the presence of commands that appear copied from a webpage, especially when they include encoded strings, obfuscated PowerShell, or references to common Windows tooling. The content may look like normal troubleshooting text until the user follows the command verbatim. That is why analysts should treat “copy this command” instructions as a primary signal, not a minor anomaly.
For a fuller breakdown of the lure pattern, delivery methods, and Windows-side detections, NHIMG’s ClickFix and Fake CAPTCHA Paste-and-Run Attacks Guide covers the mechanics that make these campaigns effective. The broader Phishing Guide is also useful because ClickFix often behaves like phishing with an execution step added after the lure succeeds.
What to look for in content, endpoints, and user reports
Security teams should pay attention to user reports that mention fake CAPTCHA checks, browser error loops, unexpected verification prompts, or being asked to press Win+R, open PowerShell, or paste a command from a web page. Those reports often arrive before endpoint telemetry makes the campaign obvious. The page may also reference legitimate products or enterprise tools to look credible, which can make the lure feel operationally familiar.
On the endpoint side, hunting value often comes from artefacts around user interaction rather than the final payload alone. Clipboard-driven execution, browser-to-shell transitions, suspicious use of encoded scripts, and repeated attempts to open the Run dialog are all consistent with a ClickFix-style flow. If the page or attachment is asking the user to “repair” something manually, the question is not whether the instruction looks technical, but whether the user should ever be asked to execute it at all.
If you need a second reference point for the downstream payload risk, NHIMG’s Infostealer Threat Guide and Lumma Stealer Guide show why these lures matter operationally: ClickFix is often a delivery path for infostealers that harvest sessions, tokens, and other secrets after the user executes the pasted command.
Risk and Threat Considerations
ClickFix is dangerous because it collapses the trust boundary between a browser page and the local execution environment. The lure can bypass web filtering and traditional phishing cues by converting the victim into the execution mechanism, which raises the odds of malware installation, session theft, and broader compromise.
Failure mechanism: The attacker gains execution by persuading the user to run a copied command, often after a fake error or verification step, so detection can be delayed until malicious code has already executed.
Impact: This can lead to infostealer infection, token or cookie theft, lateral movement through stolen credentials, and follow-on ransomware or account abuse if the initial execution is not contained quickly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1204.004 — User Execution: Malicious Copy and Paste | ClickFix relies on users pasting and running attacker-supplied commands. |
| Recommendation — Map pasted-command lures to T1204.004 and hunt for user-executed shell activity. | ||
| CIS Controls v8 | CIS-9 — Email and Web Browser Protections | ClickFix commonly arrives through browser-delivered lures and attachments. |
| CIS-10 — Malware Defenses | These campaigns frequently deliver infostealers after user execution. | |
| Recommendation — Harden browser and web filtering controls to block malicious lure pages and attachments. Use malware defenses to detect and contain payloads launched after the lure succeeds. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Endpoint monitoring is needed to spot shell execution after deceptive prompts. |
| SI-3 — Malicious Code Protection | ClickFix often ends in malware installation or infostealer deployment. | |
| Recommendation — Monitor for suspicious PowerShell and Run dialog activity tied to user-driven execution. Block known malicious payloads and script activity before they can execute. | ||
Practitioner Guidance
What to verify: Treat any support-like page that asks a user to paste a command into PowerShell or the Run dialog as suspicious until proven otherwise. Validate whether the help flow is legitimate, whether the command is signed or documented by the vendor, and whether the user should ever be executing recovery steps manually.
Common mistake: Teams often over-focus on the final payload and under-focus on the lure pattern that enabled it. If users keep reporting fake CAPTCHA pages or “fix this error” instructions, that is already an incident signal even before malware is confirmed.
Practitioner takeaway: The decisive clue is not just that a page looks fake, but that it tries to convert the user into the shell launcher. Once you see the browser-to-command-line handoff, treat the campaign as an execution and exposure problem, not a simple phishing page.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org