Nov 2 2026

ClickFix Malware: Fake CAPTCHAs and Clipboard Commands

We analyzed four ClickFix lures impersonating Booking.com, Google Meet and Cloudflare. Explore clipboard execution, IOCs, MITRE mapping and website defenses.

Inside ClickFix: How Fake CAPTCHAs and Meeting Errors Deliver Malware

Four ClickFix lure implementations reveal how familiar verification screens, clipboard commands, and trusted Windows utilities can turn a website visit into a malware-delivery attempt.

A legitimate CAPTCHA verifies that a visitor is human. It doesn't require that visitor to open Windows Run, paste a command, or launch PowerShell.

That difference is the foundation of ClickFix, a social-engineering technique that disguises a malware-execution request as a routine repair or verification step. Instead of directly exploiting a browser vulnerability, the attacker persuades the user to run a command on their own computer.

We reviewed four ClickFix-style webpage implementations in a technical source report. Two imitate Booking.com verification, one recreates a Google Meet device-error workflow, and one presents a multilingual Cloudflare-style check. They share a common objective but differ in how they retrieve commands, manipulate the clipboard, and conceal the final action from the visitor.

The distinction matters to website owners as much as endpoint defenders. A compromised website can become the delivery surface for a malicious verification prompt even while much of its ordinary content appears unchanged. New Zealand's National Cyber Security Center warned in September 2026 about ClickFix pages being served through compromised websites, including WordPress sites. Microsoft separately documented a TerminalFix campaign in August 2026 that used fake Cloudflare verification on compromised sites to launch a more involved intrusion chain.
Our four samples should not be interpreted as proof of one threat actor, one continuous campaign, or one shared final payload. They illustrate related delivery techniques; the downstream malware was not recovered in the supplied excerpts.

TL;DR

  • ClickFix is a user-execution technique, not a single malware family. The central deception is making a pasted system command look like a legitimate verification or repair step.
  • All four reviewed examples impersonate familiar workflows: hotel booking, video conferencing, or CAPTCHA verification.
  • The variants use different command-delivery methods, including a server-generated response, a hardcoded obfuscated PowerShell string, an mshta.exe command, and a CMD-to-PowerShell chain.
  • Suspicious browser-side clues include clipboard writes near fake instructions, dynamic verification tokens, unwanted navigation when Developer Tools open, and branding that changes based on URL parameters.
  • Website integrity monitoring and endpoint detection address different parts of the attack. Removing an injected website script does not substitute for checking whether visitors' endpoints were compromised.

The Attack Chain: From a Trusted-Looking Page to Windows Execution

The four examples follow the same broad pattern:

Compromised or fraudulent page → Fake verification/error prompt → Command copied to clipboard → Visitor asked to paste into Windows Run or a shell → Windows utility executes or retrieves additional code

The browser page does not simply gain permission to execute arbitrary Windows commands. In this attack pattern, the user's manual action crosses the security boundary: the visitor pastes text into an operating-system execution interface.

That is why a simple-looking instruction can be more important than a complicated exploit. The attacker presents the malicious command as something the visitor must do to proceed with a reservation, join a meeting, or complete a security check.

MITRE ATT&CK maps this behavior directly to T1204.004 — User Execution: Malicious Copy and Paste. Microsoft also describes ClickFix as a technique that uses familiar repair or verification prompts to persuade users to run malicious commands, sometimes delivered through compromised websites or phishing links.

Four Lure Implementations, Four Ways to Build Trust

Reviewed sample

Impersonated experience

Command delivery

Distinctive behavior

Booking.com dynamic check

Hotel-booking verification

Server returns a command as JSON

get_command=1, verification_id, visitor telemetry

Booking.com fixed check

Fake CAPTCHA/security step

Hardcoded, obfuscated PowerShell text

Clipboard copy and an attempted Developer Tools deterrent

Google Meet device error

Microphone/camera troubleshooting

Clipboard delivery of an mshta.exe invocation

Fake meeting interface and device-error modal

Cloudflare-style check

Human verification

CMD stages text for subsequent PowerShell processing

Language selection and ?site=-based domain display


The shared visual strategy is authority borrowing. The page looks like a familiar service, so the requested action seems less unusual. But the implementation details matter because each variant leaves different evidence for an investigator.

Booking.com: Dynamic Verification with a Remote Command Source

The first template retrieves its command from a relative web endpoint rather than embedding one fixed command in the page.

The relevant request contains:
?get_command=1
The response is parsed as JSON. The page checks a status field and, when the response indicates success, uses a returned command and verification_id. The page also renders that verification token.

This is a notable design choice. A server-supplied command can be changed without editing the lure's visible JavaScript. A blocked response can suppress the workflow for some visits, although the supplied code does not establish whether that decision is based on geography, browser profile, or another condition.

The template also collects a small group of browser and visit attributes: the verification ID, page hostname, referring URL, and user-agent string. It submits them to a same-origin web endpoint.

The source report labels this component as Telegram telemetry. The supplied JavaScript demonstrates a web POST, not a direct Telegram API call. A backend might forward that data elsewhere, but that path is not visible in the excerpt.

For defenders, the most useful combination is a suspicious verification UI together with a command-fetch request, a generated verification token, and subsequent visitor telemetry.

Booking.com: Fake CAPTCHA with Obfuscated PowerShell

The second template carries its command inside the page and copies it through the browser clipboard API when the user clicks a control.

The key browser operation is:
navigator.clipboard.writeText(command);
That API call is legitimate in ordinary applications. Here, its significance comes from what it copies and the instructions that follow.

The command text in the reviewed sample uses shortened PowerShell syntax and fragmented construction to obscure remote script retrieval. Its reported destination is gaowvdoxh[.]com. The page adds reassuring language about an anti-bot check and a Ray ID, borrowing terminology that a visitor might associate with genuine website security infrastructure.

The sample also loads a disable-devtool library and attempts to navigate the page to about:blank when browser inspection tools are opened. This may interrupt casual examination, but it is not a reliable barrier to controlled forensic analysis.

The detection lesson: do not treat clipboard access, anti-bot text, or an inspection-deterrence library as definitive on their own. Combined with instructions to run PowerShell and a remote download source, they become far more significant.

Google Meet: A Fake Hardware Problem

The third implementation takes advantage of another familiar moment: joining a video call and encountering an apparent microphone or camera failure.

Its page presents a meeting-style interface. Clicking certain microphone or camera controls can trigger a decoy modal that claims something needs to be fixed. The copyPleaseFix function prepares a command that invokes Windows mshta.exe against a remote destination reported as driver-issues[.]com.

mshta.exe is a legitimate Windows component that can run HTML Application content. In the wrong context, it can also execute code obtained from an attacker-controlled location.

The source shows a fallback mechanism for copying text when the modern clipboard API is unavailable. This helps attackers because a page can preserve the same social-engineering workflow across different browser conditions.

Independent research has documented similar fake Google Meet lures. Sekoia's Phantom Meet analysis describes meeting-error pages used to distribute information-stealing malware. That research supports the broader pattern, but it does not prove that the particular destination in our sample belongs to Sekoia's tracked cluster.

Cloudflare: A Multilingual Fake Verification Page

The fourth template localizes its lure, selecting Russian for browsers reporting a Russian language preference and English otherwise.

It also reads a site URL parameter and uses that value when displaying domain information on the page. This lets a reusable template appear tailored to whatever website the visitor expects to verify.

The execution chain described in the source combines Windows CMD with PowerShell. Its intended flow stages a short script under %TEMP%\a.txt, reads it back, and evaluates its contents. The remote location supplied in the sample is installjournaltrace.nocheat[.]sbs.

The appearance of a temporary text file reminds us that ClickFix is not inherently fileless. Depending on the command, it can generate disk artifacts, run code in memory, or do both.

The page is impersonating a Cloudflare-style security challenge. There is no evidence that Cloudflare provided or endorsed the malicious instructions.

What Makes These Pages Effective?

The four templates rely on different interface details, but the same trust failures recur.

They turn an expected task into a prerequisite. The visitor believes they cannot book, join, or continue until the purported error has been resolved.

They disguise operating-system execution as verification. Real CAPTCHA interactions occur in the browser or application interface. Requiring a visitor to paste code into Windows Run, Command Prompt, or PowerShell is a major warning sign.

They separate the visual message from the command. In some variants, the payload is fetched dynamically; in others, it is embedded but copied into the clipboard so that the visitor may never inspect it.

They can adapt the visible experience. A verification ID, domain name, or localized language can make the same lure look relevant to different visitors.

They may hide from simple inspection. Conditional content or inspection-deterrence scripts can make a malicious page behave differently during automated or manual review. This connects to the broader problem we explored in Website Cloaking and Scanner Evasion.

The technical boundary remains important: JavaScript clipboard access alone does not mean that a web page has silently executed a system command. In the ClickFix pattern described here, execution depends on a further action by the user.

What Makes These Pages Effective?

The values below come from the four source excerpts. They are sample-level indicators, not a current blocklist. Domains are defanged intentionally. No live-host status or downstream payload hash was independently validated for these samples.

Indicator

Associated sample

Interpretation

gaowvdoxh[.]com

Booking.com fixed-command lure

Reported remote PowerShell script source

driver-issues[.]com

Fake Google Meet lure

Reported remote mshta.exe destination

installjournaltrace.nocheat[.]sbs

Fake Cloudflare-style lure

Reported script retrieval location

get_command=1

Booking.com dynamic lure

Relative endpoint requests command data

verification_id

Booking.com dynamic lure

Response token displayed in the page

/wXz3eMKh7MHhLrpvUxB1jfCeD-aDrlArB4OXuD_ohZo

Booking.com dynamic lure

Relative backend endpoint used by the sample

copyPleaseFix

Fake Google Meet lure

JavaScript function associated with clipboard staging

%TEMP%\a.txt

Fake Cloudflare-style lure

Reported temporary command-staging artifact; generic filename

?site=

Fake Cloudflare-style lure

URL parameter used to adapt the displayed domain

disable-devtool

Booking.com fixed-command lure

Inspection-deterrence dependency; not malicious by itself


A JavaScript token such as navigator.clipboard.writeText is too common to treat as an IOC by itself. Likewise, %TEMP%\a.txt and ?site= are not intrinsically suspicious. The investigation should combine code context, unexpected verification instructions, endpoint telemetry, and network activity.

The source report also lists additional IP addresses and domains but does not show their relationship to the four code excerpts. We have omitted those values from this publishable indicator table pending corroboration.

MITRE ATT&CK mapping

Technique

ATT&CK ID

Observed or supported behavior

User Execution: Malicious Copy and Paste

T1204.004

The central ClickFix mechanism: a person is persuaded to paste and execute attacker-supplied text

Command and Scripting Interpreter: PowerShell

T1059.001

PowerShell-based execution paths in the Booking.com and Cloudflare-style samples

Command and Scripting Interpreter: Windows Command Shell

T1059.003

CMD-based staging in the Cloudflare-style sample

System Binary Proxy Execution: Mshta

T1218.005

mshta.exe appears as the execution vehicle in the Google Meet sample

Obfuscated Files or Information

T1027

The obfuscated command in the Booking.com fixed-command sample


Further mapping, including the precise next-stage download and command-and-control techniques, should follow recovery of the subsequent payloads rather than be inferred from the landing pages alone.

Detection: Defending the Website and the Endpoint

ClickFix crosses two environments. The website or phishing page delivers the deception; the visitor's computer performs the requested execution. A useful defense must account for both.

For Website Owners and Hosting Providers

Inspect the actual page visitors receive. Check newly injected JavaScript, unexpected iframes, remote scripts, and verification overlays that were not deployed by the site owner. Review the rendered page as well as stored source files.

Investigate changes and entry points. Compare files and deployment artifacts against a trusted baseline. Review CMS updates, plugins, administrator access, compromised accounts, and writable directories. If a malicious verification page is being served, determine whether the source is an injected script, a redirect, an altered template, or a separate lookalike domain.

Test for selective delivery. Compare behavior across fresh sessions, visitor characteristics, and relevant URLs. Some malicious pages condition their response on request parameters or environment signals.

Remove the compromise, not just the overlay. Cleaning up the visible fake CAPTCHA without closing the original compromise path risks reinfection. The New Zealand NCSC guidance makes that distinction explicit.

For Security Operations Teams

Correlate browser activity with process execution. Look for unexpected powershell.exe, cmd.exe, or mshta.exe invocations after suspicious browsing activity, especially with remote retrieval or expression-evaluation arguments. Process ancestry alone is not decisive; normal Windows workflows can also invoke these utilities.

Review network and PowerShell telemetry. Correlate process creation, command lines, PowerShell script-block events, file creation, and outbound requests. MITRE publishes a specific detection strategy for T1204.004.

Restrict risky utilities where appropriate. Application control, endpoint detection, browser isolation, DNS filtering, and controls around mshta.exe or risky PowerShell behavior can reduce exposure. Test restrictions against legitimate administrative workflows before enforcement.

Treat executed commands as an incident. If a user followed the prompt and ran the command, investigate the endpoint for payload execution, credential access, persistence, and unauthorized network connections. Simply closing the browser tab is not a sufficient response.

For Employees and Website Visitors

The rule is straightforward: a website verification, reservation check, or meeting error should never require you to paste an unfamiliar command into a system execution window. Stop and verify through a trusted channel instead.

Why ClickFix Is Also a Website-Integrity Problem

The most consequential role of the compromised website is not necessarily to run malware on its own server. It may be to convince visitors to compromise their own devices.

That exposes two groups at once. Visitors can face credential theft or further malware delivery, while website operators may lose trust, face support incidents, suffer reputational harm, and receive possible warnings against their domain.

An application can still show its expected homepage while altered JavaScript changes what particular visitors see or do. We discussed this gap in Client-Side JavaScript Security & Web Integrity. ClickFix demonstrates why those checks should include unauthorized page overlays, surprising redirects, and suspicious browser interactions—not only visible defacement.

At Quttera, we address the website side of this problem through ongoing monitoring, malicious-code analysis, and website-integrity investigation. ThreatSign Website Security provides continuous website security monitoring and additional protection capabilities depending on the deployment and plan.

For hosting providers and security platforms that need to integrate website risk findings into their own workflows, the Quttera Security and Compliance API provides structured website security evidence.

Neither website monitoring nor an API scan replaces endpoint investigation once a visitor has executed the malicious command. Those are complementary parts of the defense.

Conclusion: The Dangerous Step Looks Like a Routine Fix

The four ClickFix templates reviewed here do not need the same attacker, domain, or final malware to demonstrate the same failure mode.

Each creates a familiar pretext, puts an execution command within reach of the clipboard, and asks the visitor to complete the final step. One uses a booking verification ID, another deters inspection, a third creates a meeting-device error, and the fourth localizes a fake security check.

The visible design can change quickly. The core behavior remains recognizable: a website asks a human to perform an operating-system action that the website itself should never need.

For website owners, the essential question is no longer only whether the site loads correctly. It is whether the site is asking visitors to do something it was never supposed to ask.

Technical References and Further Reading

Build Web Integrity Intelligence Into Your Platform

Use Quttera’s Website Security and Risk Intelligence API to automate malware detection, blacklist intelligence, integrity analysis, compliance evidence, and machine-readable website assessment across digital assets.