From Magecart to ClickFix: Google Callback Abuse Hits 100+ Websites
More than 100 websites were turned into potential launch points for attacks against visitors’ Windows devices. Source Defense researchers previously documented attackers abusing Google callback weakness to deliver Magecart payment skimmers. In this latest campaign, the same delivery method has been adapted for ClickFix, a social-engineering attack that tricks users into pasting and running a malicious command. The shift significantly broadens the threat: attackers no longer need access to a checkout page because any compromised website can be used to expose Windows visitors to the malware-delivery prompt. The campaign is also difficult to detect and investigate because the malicious code is assembled dynamically, the attacker’s server decides which visitors receive the payload, and many users see no malicious activity at all.
Attack details
The attack begins with a small inline script injected into the compromised website. Rather than containing an obvious payload, this first-party stub performs a few initial checks, builds a WebSocket address at runtime, and connects to an attacker-controlled host. It then transfers the page URL through the WebSocket, and the server responds with an obfuscated loader that is stored in sessionStorage for reuse during the browsing session. Keeping the functional payload outside the static page source makes the injection harder to analyze, while reusing the stored loader reduces repeat communication that could reveal the campaign. Technically, this is a first-party page injection that triggers third-party script activity.
The loader then abuses the Google callback behavior that Source Defense disclosed in late 2024. It encodes the next-stage payload and places it in the callback parameter of a Google OAuth revocation endpoint. Because the endpoint reflects that value into an executable response, the browser treats the code as a script delivered from a trusted Google origin. Many websites allow Google domains through Content Security Policy (CSP) because they depend on services such as Google Analytics, Tag Manager, reCAPTCHA, Sign-In, or Google Pay. The attackers take advantage of that broad allowlist, using an approved origin to execute code that the site did not intend to trust.
From there, execution passes to an attacker-controlled traffic distribution service. The browser sends the compromised website’s hostname and a timestamp, allowing the server to decide whether to continue. macOS visitors typically receive no payload, while selected Windows users are shown a full-page overlay. The overlay uses postMessage to request the legitimate site’s domain and favicon, enabling the same generic lure to imitate whichever website has been compromised.
The final stage presents a fake human-verification prompt designed to trigger a ClickFix infection. The page silently writes a command to the clipboard, then instructs the visitor to open the Windows Run dialog, paste the command, and press Enter. That command launches msiexec, a legitimate Windows installer utility, which retrieves and silently installs a remote MSI package. This living-off-the-land technique moves the final execution step out of the browser and onto the visitor’s device. Per-victim identifiers support tracking, while engagement beacons, status polling, and session-based frequency controls help the attackers measure successful execution and avoid showing the lure repeatedly.
How Source Defense protects you
Source Defense protects users by monitoring and controlling script behavior inside the browser, where this attack is assembled and executed. It can detect connections to malicious infrastructure, unauthorized data transfers, browser-storage use, and risky code execution, even when the functional payload is absent from the static page source. This browser-side protection helps prevent malicious script activity from turning a compromised website into a delivery point for device-level attacks.
How Source Defense alerts you
Source Defense can surface relevant alerts for script activity observed in the browser, including:
- Loaded from a blacklisted domain
- Sending data to a blacklisted domain
- Executing risky actions (such as eval)
Alerts are available through the bell notification center and dashboard summaries. Threat-intelligence matches can appear under “Found in blacklists,” while risky runtime activity is available under “Script behaviors.” Security teams can also configure email and webhook notifications to route relevant findings into existing security and incident-response workflows.
Key takeaways
The Google callback technique identified by Source Defense in 2024 has not disappeared; it has been repurposed. Its earlier use focused on Magecart and payment-card theft, while this campaign uses the same trusted-origin execution path to deliver ClickFix and pursue device compromise. Because the final payload targets the visitor’s Windows device rather than payment data on the website, the attackers do not need to focus on checkout pages. Any compromised site can become a useful delivery point, which helps explain the campaign’s presence across more than 100 websites in unrelated sectors, including sites without payment functionality.
CSP and SRI remain useful browser-enforced controls, but CSP can be weakened by broad trust relationships, and SRI is primarily suited to stable resources with known hashes. WAFs and server-side logging operate outside the browser and may miss dynamically staged activity that never appears in the application’s static source. Source Defense adds browser-side runtime protection, helping organizations detect and control malicious script behavior before a compromised website can expose visitors to malware or become a launch point for a broader attack.
PCI DSS 4.0 makes client-side security a priority.
Source Defense delivers a solution for 6.4.3 and 11.6.1 without adding a burden to your security teams.