ClickFix is a delivery technique, not a piece of malware: a fake verification prompt (a bogus CAPTCHA, browser update, or DocuSign viewer) tells the visitor to open the Windows Run dialog, paste a clipboard-injected command, and press Enter. The victim executes the payload themselves, so there is no exploit and no download for antivirus to scan.
- ClickFix needs a user to manually paste and run a command, so it works without a browser exploit or admin rights.
- North Korea-linked crews have built it into fake recruiter and technical-interview lures, a pattern UAE hiring pipelines already sit inside.
- File-based antivirus rarely catches the first stage, because nothing is downloaded until after the command already runs.
- Stopping it is mostly a detection-tuning and staff-training problem, not a product you can buy outright.
How the ClickFix Lure Actually Works
A visitor lands on a compromised website, a malicious ad, a fake DocuSign or Zoom error page, or increasingly a GitHub issue, an npm package README, or a job posting. A script on the page renders something that looks exactly like a CAPTCHA challenge or a "your browser needs verification" notice, then walks the user through three steps: press Windows+R, paste, press Enter. On the Mac variant the instructions point at Terminal instead. Behind the scenes the page has already written a command to the clipboard using the browser's clipboard API, so the user does not actually know what they are about to run.
The pasted line almost always calls a binary that is already trusted on the machine: mshta.exe, powershell.exe with an encoded argument, certutil.exe, or curl.exe. That first command usually does one thing: fetch a second-stage payload from attacker infrastructure over plain HTTPS, which blends into normal browsing traffic and gives nothing to scan until the download actually happens. There is no exploit, no macro, no email attachment. The user supplies the execution step themselves.
Why It Slips Past Standard Defences
Email security stacks never see it, because the lure lives on a web page rather than in a message: DMARC checks, attachment sandboxing, and URL rewriting have nothing to inspect. Browser download protections do not see it either, because nothing passes through the browser's download manager; the browser's only job was to put text on the clipboard. Endpoint tools tuned to flag suspicious downloads or macro execution are also looking in the wrong place, because the process tree here is explorer.exe spawning powershell.exe or mshta.exe directly from the Run dialog, a pattern enough legitimate admin activity also produces that a blunt "block mshta" rule tends to generate enough false positives that it gets rolled back.
The social engineering is also sharper than a typical phishing pretext. Asking someone to prove they are not a robot, or to fix a "verification error," matches an interaction people already perform many times a week on genuine sites. It does not trip the "why is this so urgent" instinct that most awareness training drills into staff, because it never claims urgency and it never arrives by email.
Why UAE Organisations Specifically Should Pay Attention
Two things push this past a generic threat note for the region. First, financially motivated crews and North Korea-linked operators have folded ClickFix into fake recruiter and technical-interview flows: a "hiring manager" sends a coding assessment or a link to a "video call troubleshooting page," and the candidate pastes the fix themselves. Dubai and Abu Dhabi tech and fintech hiring runs heavily on remote interviews and outsourced contractor placements, the same pipeline already flagged around fake recruiter and laptop-farm schemes targeting UAE businesses. A ClickFix page is the next stage of that playbook: it gets the candidate, and whichever corporate laptop or VPN profile they carry, to run the first-stage loader on its behalf.
Second, developers here work constantly in GitHub issues, npm packages, and community support channels, all of which have been used to host ClickFix pages disguised as a fix for a build error. A developer holding production credentials or CI secrets is a far better payoff than a random consumer machine, which is exactly why this deserves attention beyond the general staff-awareness deck.
What Good Detection Actually Looks Like
Stopping ClickFix is a detection-engineering question before it is a product question. The controls that matter:
- Alert on explorer.exe or the Run dialog spawning powershell.exe, mshta.exe, cmd.exe, or wscript.exe with encoded or obfuscated arguments, not only on file execution.
- Look specifically for the clipboard-to-Run-dialog pattern. Several EDR platforms now ship detections tuned to this exact chain rather than generic living-off-the-land rules, which is worth asking about by name in any EDR evaluation, alongside how the candidate handles attack surface reduction rules in Defender for Endpoint if that product is already in the stack.
- Restrict or at least log Run-dialog and PowerShell execution policy at group-policy level for roles that do not need local scripting, rather than trying to block every possible payload domain one at a time.
- Treat the browser as a delivery channel in its own right. Web proxy and DNS filtering categories that flag newly registered domains and known fake-CAPTCHA infrastructure catch a meaningful share of these attempts before a user ever reaches the paste step.
Building It Into the Response Plan
The awareness-training fix is narrow and specific: tell staff that no legitimate verification, update, or meeting-fix process ever asks them to open the Run dialog and paste something. That one sentence, repeated at onboarding and in phishing-simulation debriefs, closes most of the human side of this. It works better than generic "don't click suspicious links" messaging because it names the exact action to refuse.
On the technical side, this belongs in the same incident response plan as any other initial-access vector: define what containment means when the alert is a single PowerShell execution rather than a spreading worm, decide in advance who can isolate a host without waiting on approval, and make sure whoever triages EDR alerts knows to pull the full command line rather than just the alert summary, since the second-stage URL is usually sitting there in plain text.
Assessors working to UAE frameworks such as NESA or the NCA's ECC rarely ask about ClickFix by name. What they expect is evidence of detection coverage for living-off-the-land execution, and evidence that your incident response plan has been tested against an initial-access scenario that involves no malicious attachment at all. ClickFix is simply the clearest current example of why that coverage needs to exist independently of email security.
Where to Start This Week
Pull your EDR's alert history for the last ninety days and search for Run-dialog-spawned PowerShell or mshta activity that was suppressed or auto-closed. If that search returns nothing, treat that as a finding in itself: it usually means detection was never tuned to look, not that nothing happened. Pair it with one line added to your next phishing-awareness refresh: real verification never asks anyone to paste something into Run. Both take an afternoon, and together they close more of this gap than another point product will.
