3,000-Site ClickFix Campaign Built for Rapid Domain Rotation

Source Defense Research identified more than 3,000 compromised websites participating in an active ClickFix campaign that can move between newly registered delivery domains while continuing to serve the same attack. Behind the fake Google reCAPTCHA is a coordinated malware-delivery framework that filters automated analysis, tracks visitors across sessions, runs randomized A/B tests, measures victim interactions, and hides the lure from authenticated WordPress administrators.

Attack details

Source Defense researchers identified the affected websites through a recurring script element designed to resemble a legitimate Google Analytics component. Historical web data connected this common injection to more than 3,000 websites across multiple countries and industries.

The campaign does not depend on one fixed delivery domain. Researchers observed affected websites loading malicious scripts from different domains over time, including newly registered replacements.

The first-stage loader helps make that infrastructure portable. Rather than hardcoding the locations of subsequent components, it derives the origin from its own script URL and retrieves the analytics and ClickFix components from that same origin.

Comparisons across different delivery domains confirmed that the analytics and ClickFix files were byte-for-byte identical to earlier versions. Only the campaign or website tracking identifier in the initial loader changed. At the same time, the observed final malware download location remained unchanged.

This means the operators can deploy the same attack package on fresh infrastructure and update the malicious script reference on compromised websites. The evidence demonstrates active delivery-domain rotation, although it does not establish exactly how the operators maintain the ability to update affected sites. Persistent backdoors, stolen credentials, malicious WordPress plugins, compromised management systems, or automated reinfection are possible mechanisms, but none has been confirmed. 

The attack begins with a small JavaScript loader embedded in the compromised website. Before presenting the lure, it checks the browser’s user-agent string and excludes search engines, social-media preview bots, commercial scanning tools, and AI crawlers including GPTBot, ChatGPT, ClaudeBot, and Anthropic.

Visitors who pass the filter are randomly assigned to variant A or B, and that assignment is stored in the browser so they continue receiving the same version. The loader then retrieves a visitor analytics component and the assigned ClickFix variant.

Analysis of both variants confirmed that this is a genuine A/B experiment rather than operating-system routing. Both target desktop Macintosh browsers, exclude iPhones and iPads, display the same fake reCAPTCHA interface, provide the same Spotlight and Terminal instructions, copy the same type of Bash command, download the same next-stage payload, and support the same multilingual content.

The primary difference is telemetry. Both variants track core interactions with the lure, while variant B records additional events that provide greater visibility into whether the fake CAPTCHA appeared, whether the visitor clicked inside it, and where the visitor abandoned the process.

The analytics component creates a persistent 64-character visitor identifier and stores it in local storage and a browser cookie. It records information including the compromised page URL, referring page, visitor identifier, campaign or website identifier, assigned variant, and interaction stage.

The first visit event is sent using the browser’s Beacon API, which can help telemetry reach the server even if the visitor quickly leaves the page. Later interaction events are generally sent using fetch, with Beacon available as a fallback.

The campaign also verifies that the lure was genuinely visible. The scripts check whether the document is visible, the browser has focus, the overlay has measurable dimensions, and most of it intersects the visible page. This lets the operators distinguish between JavaScript that simply executed and a lure that was actually displayed to a person.

The ClickFix components also look for signs of automated analysis, including headless browser and testing indicators. They additionally search for a WordPress logout link commonly present when an administrator is authenticated. If that element is detected, the fake CAPTCHA is suppressed.

As a result, an ordinary visitor may receive the malicious overlay while a website owner inspecting the same site while logged in sees nothing unusual.

Eligible macOS visitors receive a full-screen overlay impersonating Google reCAPTCHA. The lure supports numerous languages and tells the victim to open Spotlight, search for Terminal, paste the copied command, and press Return.

When the visitor clicks the fake verification control, the script first attempts to place the malicious command on the clipboard using the modern Clipboard API. If that fails, it uses a hidden text field and an older browser copy mechanism. If neither method works, it displays the command so the victim can copy it manually.

The clipboard contains a complete shell instruction with a Base64-encoded Bash script. Once the victim pastes and runs it in Terminal, the script saves the compromised page URL in an environment variable called SRC_URL, changes to /tmp, downloads an additional payload from attacker-controlled infrastructure, saves it under a randomized hidden filename, and executes it with Bash.

The wrapper then removes the downloaded file, runs the payload in the background, suppresses standard output and errors, clears the Terminal screen and scrollback, attempts to remove the command from shell history, redirects the active history file to /dev/null, and displays a green “Verification successful” message.

The downloaded Bash payload itself was not available in the JavaScript chain analyzed by Source Defense, so its final capabilities cannot be confirmed from this research.

How Source Defense protects you

Source Defense provides runtime protection, control, and visibility inside the browser, where this campaign’s malicious JavaScript executes and interacts with visitors.

For the observed delivery infrastructure, Source Defense identifies the malicious domains through blacklist intelligence and can block scripts loaded from them before the ClickFix code executes in the browser.

Source Defense also highlights newly introduced scripts and other changes in the client-side environment. A new script arriving from a recently created domain is a strong risk signal in a campaign like this and can be surfaced as suspicious for review and recommended blocking. For customers using Source Defense’s automated protection capabilities, that script is blocked automatically.

This is particularly valuable when attackers rotate infrastructure. Even before a replacement domain becomes a familiar indicator, the introduction of new code from newly created infrastructure can draw attention to the change, while runtime analysis continues to evaluate what that script is doing in the browser.

Source Defense evaluates script behavior and applies policies accordingly, providing protection that combines threat intelligence, change visibility, and runtime control rather than depending on a single static indicator.

How Source Defense alerts you

Relevant alerts for this campaign include:

• New script found – with new domain
• Loaded from a blacklisted domain
• Sending data to a blacklisted domain
• Using 1st party cookies
• Using browser storage

Source Defense surfaces these findings through the bell notification center, dashboard summaries, “Found in blacklists,” “Script behaviors,” and “Domain info” with email and webhook notifications available for relevant events.

Key takeaways

This campaign is more than a fake CAPTCHA distributed across thousands of unrelated infections. The operators have built a coordinated malware-delivery framework that can move between newly registered domains, reuse the same attack components, maintain persistent visitor identities, run randomized experiments, measure conversion and abandonment, filter automated analysis, and hide the attack from authenticated WordPress administrators.

Source Defense can block the known malicious scripts when their delivery domains are identified through blacklist intelligence. It also helps surface newly introduced scripts, especially when they arrive from recently created domains, giving security teams an earlier signal that the client-side environment has changed in a suspicious way. Where automated protection is enabled, the script would be blocked automatically.

The campaign’s rapid domain rotation also shows why fixed indicators should be combined with runtime visibility. Domains, URLs, hashes, and tracking identifiers can change, while the underlying attack behavior remains consistent.

Content Security Policy (CSP) and Subresource Integrity (SRI) are browser-enforced controls focused on source restrictions, policy enforcement, and resource integrity. WAFs, firewalls, backend logs, and server-side monitoring operate at the server, network, or application layer rather than evaluating JavaScript behavior inside each visitor’s browser.

Source Defense combines threat intelligence, visibility into script changes, and runtime control inside the browser. That allows organizations to stop known malicious scripts while continuing to identify and control suspicious new activity as attackers rotate infrastructure.