ClickFix Turns the Browser Into a Cryptocurrency Skimmer

A ClickFix campaign analyzed by Cisco Talos demonstrates how social engineering can turn a victim’s own browser into a cryptocurrency theft tool. Rather than persuading users to execute PowerShell or another operating-system command, the operators convinced them to paste JavaScript into Chrome or install code in the Tampermonkey browser extension.

The campaign used a fabricated vulnerability report promising unusually high returns from cryptocurrency trading services. Behind that lure was a browser-side skimmer that altered trading interfaces, intercepted network responses, replaced wallet addresses, and tampered with clipboard contents. Cisco Talos also found that the campaign used publicly accessible Google Sheets and the Google Visualization API to retrieve obfuscated JavaScript, allowing command-and-control activity to blend into traffic to a widely trusted cloud service.

Talos reported the activity in its analysis, “ClickFix moves into the browser: Cryptocurrency theft with Google-hosted C2”. The organization assessed with moderate confidence that the operation was not aimed at one specific organization, but instead targeted people active in cryptocurrency, software development, cybersecurity, and hacking forums.

A lure built around an imaginary opportunity

The campaign’s social engineering depended on greed and technical curiosity. Its documents were presented as leaked security reports describing a nonexistent API weakness at cryptocurrency trading or swap services. The supposed flaw allegedly enabled enhanced payouts or a loyalty bonus. The instructions then directed the reader to copy code and run it in the browser, or to install Tampermonkey and add a script to the extension.

Talos observed the lures distributed through Telegram, DarkForums, Pastebin and other text-sharing sites, as well as forum messages and earlier email-based distribution. The operators periodically refreshed their posts and removed older Telegram content, helping conceal that substantially the same fictional exploit was being promoted repeatedly.

Two principal lure versions were documented. The first focused on SwapZone and instructed the target to paste a script into Chrome’s address bar with a javascript: prefix. The later version targeted SimpleSwap and used Tampermonkey as the execution mechanism. The extension-based approach was more durable because the injected code could run whenever the user visited the targeted site.

These details are important because the user’s action was not an incidental step in a conventional malware infection. It was the execution mechanism. The victim was persuaded to authorize code in a trusted browser context, where ordinary network controls and process-based detections have less visibility.

Google-hosted retrieval concealed the delivery channel

The campaign’s first-stage scripts contacted a publicly published Google Sheet through the Google Visualization API. That API provides unauthenticated, read-only access to data in publicly published spreadsheets through an HTTPS request. In this case, the scripts queried selected cells, retrieved fragments of JavaScript, concatenated them, and injected the resulting payload into the active web page.

Cisco Talos described this as a form of legitimate-service abuse. The traffic originated from Chrome and went to docs.google[.]com, making it appear similar to ordinary browser activity involving Google Docs or Sheets. The operators could change the queried cells or move the content to a different spreadsheet. Talos observed that the campaign shifted infrastructure after earlier documents and scripts were disrupted.

The first loader contained the spreadsheet information directly. The later loader hid the relevant data inside a fictitious API address using Base64 encoding. This was not sophisticated cryptography, but it made the script less immediately readable and helped conceal the retrieval logic from casual inspection.

The spreadsheet itself was also arranged to discourage casual review. Payload text was formatted in white on a white background, and newer rows were added to push hidden content farther down the document. Talos collected 21 distinct second-stage samples from the spreadsheet, including versions associated with both targeted services.

The use of Google-hosted infrastructure does not mean that Google services were themselves the source of the malicious behavior. The reported activity involved criminals abusing publicly available functionality and cloud-hosted documents. This distinction matters for defenders: broadly blocking Google services would create operational disruption while still failing to address the user action and browser behavior that enabled the theft.

What the injected code changed

Once assembled, the second-stage JavaScript operated as a web skimmer inside the cryptocurrency site. Talos identified several related behaviors.

• Interface manipulation: The code monitored the page with MutationObserver and replaced displayed deposit addresses. It also created counterfeit interface elements and altered displayed transaction amounts to make a supposed bonus appear real.
• Network-response modification: The script overrode the browser’s fetch API. When responses contained cryptocurrency deposit addresses, the code substituted attacker-controlled addresses before the information was presented to the user.
• Clipboard interception: When a user copied a deposit address, the script replaced the copied value with an address selected from a rotating list embedded in the payload.
• Persistence within the targeted site: Periodic page scanning reapplied malicious changes after interface updates. In the Tampermonkey variant, the extension loaded the code whenever the victim returned to the targeted site.

Talos found that the payloads were heavily obfuscated. Most converted functional JavaScript into hexadecimal arrays protected with XOR operations, with additional mathematical code and irrelevant calculations intended to obscure the key and logic. Other samples used Base64, Unicode escapes, or combinations of these methods. Variable and function names also changed across revisions.

Although the samples were revised frequently, Talos reported that the underlying behavior did not materially change after the scripts were initially created for each targeted service. The apparent variety therefore served primarily to alter signatures and complicate analysis.

Observed financial impact and campaign resilience

Talos identified 49 Bitcoin wallet addresses associated with the campaign. Of the samples available to the researchers, 24 wallets received funds from victims, totaling 0.159 BTC, which Talos valued at approximately $10,000 using early August 2026 Bitcoin valuations. The organization cautioned that the total amount collected was likely higher because earlier samples and potentially other wallet variants were not available to investigators.

The funds were subsequently moved through additional wallets and highly complex transactions involving more than 3,000 addresses. Talos said those transactions were likely connected to a Bitcoin mixing operation, but the ultimate destination of the funds was not established in the supplied research.

The campaign also showed operational resilience. After Talos shared information with the targeted sites and Google, the original lure and command infrastructure were blocked. The operators returned approximately a week later with a new Google Sheet and another script hosted through a text-sharing service. After the text-sharing site began detecting related scripts, the actors moved additional components into Google Docs. As of the status described by Talos, the reported Google documents remained active despite further reporting.

Why browser-based C2 changes detection

Traditional investigations of Google-hosted command-and-control activity may begin with DNS requests and the processes responsible for them. A suspicious executable resolving docs.google[.]com can be a useful lead. In this campaign, however, the requests came from the browser that the user was already using to access a cryptocurrency service.

That makes process-based filtering less useful and increases the importance of browser telemetry. Security teams should consider which users, extensions, tabs, and web origins are associated with requests to Google document services. A request to docs.google[.]com is not inherently malicious, so detection should focus on context rather than the domain alone.

The campaign also illustrates a wider risk identified by Talos. The same browser-side techniques could be adapted for attacks against other web applications, including customer-facing services or systems affected by compromised third-party code. The research does not report such a broader attack here; it presents that possibility as an assessment of how the demonstrated methods could be reused.

What organizations should do now

• Manage browser extensions: Restrict extension installation by role, review existing extensions, and pay particular attention to extensions that can modify page content or run user-supplied scripts. Tampermonkey should not be treated as inherently malicious, but its use should be governed according to business need.
• Monitor browser context: Alert on unusual requests from browser sessions to docs.google[.]com, especially when the user is not otherwise using Google Docs or Sheets. Combine URL telemetry with the initiating browser profile, extension inventory, visited site, and recent clipboard or page-script activity where available.
• Detect suspicious client-side behavior: Investigate unexpected overrides of browser APIs such as fetch, scripts that repeatedly scan the DOM, and JavaScript that modifies wallet addresses, transaction fields, or clipboard data.
• Protect web applications: Regularly test and sanitize third-party dependencies in employee- and customer-facing applications. Review obfuscated JavaScript that appears unrelated to a component’s documented purpose, particularly when it changes form behavior or transaction data.
• Train users against copy-and-paste lures: Explain that security reports promising effortless profits, bonuses, or hidden functionality are warning signs. Users should never paste unreviewed code into a browser address bar or extension configuration because a page appears credible.
• Use layered controls: Browser management, endpoint monitoring, web filtering, application integrity checks, and user education should reinforce one another. Blocking every request to a legitimate cloud provider is unlikely to be proportionate or effective.

Incident responders should preserve the relevant browser history, extension configuration, page source or script evidence, and wallet addresses displayed during the suspected activity. They should also determine whether other users accessed the same lure and whether the affected browser profile was used for additional sensitive services. The supplied research does not establish credential theft, compromise of the trading services themselves, or a particular organizational victim.

Conclusion

Cisco Talos’s investigation shows how ClickFix-style manipulation can move the execution boundary from the operating system into the browser. Public Google documents supplied obfuscated code, while Chrome and Tampermonkey provided the execution context and, in the later variant, persistence across visits. The resulting skimmer changed what users saw, what the browser received, and what the clipboard supplied.

The immediate campaign focused on cryptocurrency users, but its most important lesson is broader: trusted cloud infrastructure and legitimate browser features can conceal malicious client-side behavior. Defenders should therefore monitor not only processes and network destinations, but also browser extensions, page scripts, API overrides, clipboard activity, and the social engineering that causes users to authorize them.

Sources

• Cisco Talos: ClickFix moves into the browser: Cryptocurrency theft with Google-hosted C2