ClickFix moves into the browser: Cryptocurrency theft with Google

- Cisco Talos is tracking a cryptocurrency-stealing campaign that abuses the Google Visualization API for command and control (C2), retrieving obfuscated JavaScript from a publicly published Google Sheets document and injecting it into the victim's browser session. - The actors use a variation on ClickFix social engineering. Instead of convincing targets to run commands against the operating system, they convince targets to paste JavaScript into the Chrome address bar or install it into the Tampermonkey browser extension, which also provides persistence. - The lure poses as a leaked vulnerability report describing a nonexistent API flaw at cryptocurrency swap services, and is aimed at users willing to exploit it for financial gain. Talos observed lures distributed through Telegram, DarkForums, and paste sites. - The injected script functions as a web skimmer. It hooks the browser's fetch API, replaces cryptocurrency deposit addresses in server responses and the user's clipboard, and displays counterfeit "bonus" interface elements. Cisco Talos has recently observed a criminal campaign that leveraged an interesting twist on what we refer to as “legitimate service abuse.” In this monthslong campaign, the criminal actors used the Google Visualization API as part of a scheme to inject malicious JavaScript into two cryptocurrency trading websites. This campaign uses a twist on the tactics associated with “ClickFix” social engineering attacks, in which targets are manipulated into copying and pasting PowerShell or other commands and executing them to launch malware. Rather than targeting the victim device’s OS, the actors behind this campaign aim to convince the user to inject malicious code into their own browser session. Early versions of this campaign began in early October 2025. The social engineering lures used initially focused on getting targets to paste a code snippet directly into the Chrome web browser’s navigation bar; the latest version relies on a legitimate Chrome plugin, Tampermonkey, to inject a loader script pasted in by the user and provide persistence across sessions with the current targeted site. In March 2026, the actors behind the campaign began using the Google Visualization API to deliver malicious scripts stored in a Google Sheets document. In July, after frequent disruption of their posts on shared text sites, the actors moved to hosting all the components of their campaign in Google Docs and Google Sheets. So far, the actors behind the scheme have largely targeted individuals who frequent web discussion boards and forums focused on cryptocurrency trading, software development, basic cybersecurity, and hacking. The lure used in the campaign is designed to appeal mostly to would-be cybercriminals looking to make a quick profit off an “API vulnerability” that doesn’t exist to get bigger payouts on cryptocurrency trades. While this campaign doesn’t pose a specific threat to most organizations, the approaches that the actors here are using do. These techniques and tools could be leveraged in other malware and web attacks with much wider impact, including supply-chain attacks on e-commerce sites and other customer-facing systems. Just Google it Google application abuse for C2 is not new by any stretch of the imagination. There have been multiple cases of state-sponsored actors using Google Sheets APIs, Google Drive, and other Google cloud services to help control deployed malware, concealing communications within traffic to otherwise trusted network spaces. Hunting for these threats usually requires examination of DNS traffic and the processes that are making the requests to reach these destinations — like a random executable making a DNS request for “docs.google[.]com”. But when the requests are made from within a browser session, that makes detection much more difficult. The Google Visualization API is a feature of Google Docs that is almost as old as the platform itself. Initially introduced in 2008, the API provides free, unauthenticated read-only access to the contents of any Google Sheets spreadsheet that has been publicly published to the web via queries embedded in a URI. These queries result in delivery of data from within the spreadsheet in JSON format or as an HTML table. A Visualization API request URI looks like this: https[:]//docs.google[.]com/spreadsheets/d/[document identifier] /gviz/tq?[query language input formatted for HTTP] The API’s query language is very similar to Structured Query Language (SQL). For example, to get all of the content from a sheet’s column B returned as a JSON object, the query portion of the URI would be: /gviz/tq?tqx=out:json&tq=SELECT%20B API responses in JSON are returned in the format like the one below, ready to be parsed by the calling JavaScript application: This is a read-only API, so it can’t be used by an application to alter the data in the spreadsheet. However, an application could append to the data to a spreadsheet connected to a Google Forms page by sending an HTML POST request. Presto! A full C2 system hidden within HTTPS traffic to a trusted domain. The campaign Talos observed used the Visualization API to retrieve two cells from a remote spreadsheet containing obfuscated JavaScript, which were injected into the web browser session of a target. Used in combination with other abused legitimate services, the actors behind this campaign could modify the query used to change which cells were retrieved and injected, or if necessary change the spreadsheet targeted by the query — which they did after we disrupted their operations the first time. Phishing for sharks The actors behind this scheme are looking for a very specific kind of mark: someone who is willing to commit fraud using technical means that they don’t clearly understand. Early versions of their phishing campaign documented by researchers used email, carrying links to a Google Docs document purportedly leaked security report. Actors also used comments on Pastebin and other text-sharing sites and direct messages in various forums to post links to versions of the Docs file. In January, operators of the most recent incarnation of the scheme set up a Telegram account to facilitate the scam. The Telegram channel only allows posts from the channel administrator, and the threat actors delete older posts each time a new version of the lure is published to disguise the fact that they’re essentially just reposting the same fictional “exploit” over and over again. Talos found multiple lures related to this Telegram channel posted in dark web forums, including the cybercrime-focused DarkForums. Lures were also posted in the comments on text files shared on Pastebin and a number of other text-sharing sites. Some (like the one above) directed recipients to a Telegram channel, while others linked directly to a Google Docs document promoted in the Telegram channel. Waves of these messages were sent out at least twice a month, coinciding with new postings on the Telegram channel. Baiting the hook Talos saw two variants of the Google Docs document linked in the phishing messages. Both used the same “docs.google[.]com” URL and the same file name (“API Logic Flaw”). The first was active from April 12 – 16, 2026; the second was active starting at least as early as April 19 and remained active as of July 22, despite it being reported to Google through multiple channels. The initial version we observed targeted the cryptocurrency trading site “SwapZone[.]io”. It was formatted in the style of a vulnerability report and discussed a purported weakness in an older version of the ChangeNOW cryptocurrency exchange’s API allegedly still exposed through SwapZone; if accessed, the report claimed, it would result in “~38% higher payouts” on trades of Bitcoin for other cryptocurrencies. All the reader had to do to leverage this mythical old API, according to the lure document, was copy the script shared through a “paste[.]sh” link into the navigation bar of the Chrome browser preceded by “javascript:”. On April 18, Talos observed a new revision of the lure document. The new lure used the same “docs.google[.]com” URL as the previous lure but was rewritten to target a different trading site — “SimpleSwap[.]io”, another cryptocurrency trading aggregator. The fake exploit this time was a flaw in a “loyalty bonus” function that allegedly triggered a 25% boost in the value of the trade, according to the updated lure document. This wasn’t the only revision to the lure. In the new version, instructions were given to install the Tampermonkey browser extension from the Chrome Web Store to activate the “bonus.” The instructions then directed the targets to a link to a new source script on “paste[.]sh” to be added to the plugin (“https[:]//paste[.]sh/dQfdExjo#AqjB4BBt]lwLt2NKrlC0x8J9O”). The plugin would activate the script whenever the user visited “SimpleSwap[.]io”. Reeling them in: First-stage scripts Aside from their means of being executed by the user, both versions of this campaign’s first-stage loader script contained strings that do essentially the same thing. They both connected to the same Google-hosted spreadsheet via the Visualization API, retrieving blocks of code from different pairs of cells within the sheet. The initial version of the script depended on direct user execution of the script within Chrome. Targets were instructed by the lure to copy the script from the “paste[.]sh” URL and paste it directly into Chrome’s navigation bar preceded by “javascript:” which results in the execution of the script within the context of the current web page. The address of the Google Docs spreadsheet is plainly visible in the sample, and the JavaScript containing it swaps it for the fictitious vulnerable API’s URL to construct the Visualization API URL to retrieve the second stage script from: This results in the Visualization API call to: The script used in the second version of the lure was intended to be pasted into the Tampermonkey browser plugin’s configuration. It was somewhat more obfuscated than the first: In this script, the URL needed for the visualization API call is hidden within the fake SimpleSwap API address, encoded in Base64: When decoded, the block of text after “bonus” becomes: In both cases, the generated request for the site comes from the Chrome browser and would have appeared as legitimate web traffic. Both scripts then concatenate the retrieved blocks of JavaScript, reconstruct the full second-stage JavaScript payload, and inject into the browser session. In the first version, this is a bit more involved: The script explores the document object model of the web page looking specifically for script elements associated with browser extensions. If it finds more than one script associated with Chrome extensions, it picks a random one to inject the payload into. If no extensions are found, it picks a random object within the page as the location for injection of the payload. The method used in the second lure makes injection much easier for the attacker, as it uses an installed browser extension (Tampermonkey) to host the injected code. The script added to the extension assembles the payload code and appends it to the SimpleSwap web page’s code when the site is loaded. This also provides persistence, as the code will be loaded every time the target navigates to the SimpleSwap site. Landing the catch: The second-stage payload Over the course of our investigation, Talos saw the actors behind this campaign change the the payload delivered by the first stage script multiple times, which all did essentially the same thing: They decoded JavaScript code to inject into the targeted web pages to create the “exploits” they used to steal Bitcoin from victims. We collected 21 unique samples of the second-stage payload from the spreadsheet referenced by the API call. These included scripts for both versions of the lure, as the scripts for SwapZone were left in the spreadsheet after the actors shifted to SimpleSwap. To conceal the contents of the spreadsheet from casual analysis, the actors hid the text containing payload data by formatting the text as white on a white background. As revisions were made to the sheets to add new versions of the script, more rows were added to push the hidden cells further down the sheet, making them only discoverable through a text search or with the API query. The payload within each pair of rows was heavily obfuscated JavaScript. Except in two cases, all the obfuscation was based on converting the functional script in the payload into arrays of hexadecimal pairs that had been XOR encoded. The rest of the script was math functions to render the code and additional garbage math to conceal the actual XOR key used. One sample used Base64 encoding along with conversion of characters to Unicode values (e.g., converting “A” to “\x41”). Another paired XOR with the use of Unicode escaping for the apostrophes used to contain each array element, further impeding analysis. Revisions of the scripts over the course of Talos’ observation used different XOR keys each time to change the signature of the code and used different random strings for variable and function names, consistent with output from “Obfuscator[.]io” and similar Javascript obfuscation tools. However, it was clear that there were no actual changes to the scripts being obfuscated after they were initially coded for each targeted site. Both the SwapZone and SimpleSwap scripts targeted cryptocurrency transaction interfaces of the sites, creating new user interface elements and altering existing functions. The scripts performed the following key actions: - DOM and UI manipulation: The script monitors the page using MutationObserver and dynamically replaces displayed deposit addresses in the interface. The malware script also modifies displayed transaction amounts to deceive targeted users into believing that they have received a “bonus” on their transactions. HTML rendered by both versions of the script presents counterfeit “hidden functionality” within the site, as shown in Figure 12. - Network interception: The script overrides the browser’s fetch API to inspect and modify responses related to wallet or deposit endpoints. When JSON responses containing cryptocurrency deposit addresses are returned, the script replaces legitimate addresses with attacker‑controlled addresses. Based on decoded UI selectors and identifiers found in the script, the malware intercepts the contents of elements in forms on the targeted websites such as: - data-testid="recipientAddressContainer" - data-testid="depositAddress" - data-testid="currencyList" - data-testid="cryptoExchangeTab" - data-testid="mainExchangeForm" - Clipboard hijacking: The malware monitors UI elements used to copy cryptocurrency addresses. When a user attempts to copy a deposit address, the script replaces the copied value with an attacker’s wallet address. A rotating list of Bitcoin Bech32 wallet addresses was embedded in the code of each script; these were selected randomly for substation. - Persistence: The script conducts periodic DOM scanning to ensure the malicious replacements persist during page updates. Further persistence is provided in the second version of the attack using the Chrome extension-based loader. Cashing in Talos identified 49 BTC wallet addresses that were used in the campaign. The majority of the samples we de-obfuscated (from April to the end of June) used an identical set of 30 addresses. Of these, 24 received funds from victims of the scheme, totalling 0.159 BTC (approximately $10,000 at early August 2026 valuations of Bitcoin). There was likely more collected, as we were unable to find samples from prior to April and may not have captured the wallets used by all variants. It’s difficult to tell how much the actors behind this campaign have been able to extract from their scam-driven malware. Funds were routed out through 30 more wallets, sometimes using multiple counterparties within the set. From there the funds were moved in highly complex transactions involving a total of over 3,000 additional addresses—likely related to a Bitcoin “mixing” operation to hide the funds’ destinations. Still, this has been a very lucrative operation for relatively little investment for the actors behind it. And it has been difficult to disrupt the operation. In April, we shared information about the campaign with both the targeted websites and with Google, and the documents acting as lure and C2 components were blocked; a week later, the campaign was back with a new Google sheet and another paste[.]sh script, and back in business at a slightly reduced rate of victim recruitment. Paste[.]sh’s administrator took action to automatically detect new scripts matching the first-stage script’s signature in July. The actor then updated the lure and added a Google Docs document containing the script. As of August 11, the Google documents have again been reported but are still active. Beyond dishonor among thieves It is hard to be sympathetic to victims of crimes that preyed on their own willingness to essentially be criminals, but the capabilities demonstrated in this campaign could have a much more widespread and damaging impact in the wrong hands. The techniques used here are a variation on classic web skimming approaches. Other web skimming attacks, such as Magecart web skimming campaigns, depend largely on supply chain compromise to infect legitimate sites, injecting code through compromised dependencies — third party services, Node Package Manager distributions, and other external sources integrated into web pages to add features or provide application support. With a rise in supply-chain attacks by groups such as TeamPCP, which has sold access to other cybercriminals, the methods used in this cryptocurrency-stealing campaign could be used to leverage stolen access across large numbers of web applications dependent on compromised code bases. An actor leveraging this sort of access to gain additional targeted access or steal other information from web-based applications could use the techniques used in this campaign to selectively alter functionality of user interfaces with code from what would look to defenders to be legitimate application traffic. Malicious and fraudulent browser plugins already alter content in web pages and redirect traffic; a subtle corruption of an existing browser plugin update using a Google document for C2 could make detecting malicious activity from network telemetry much more difficult for defenders. Additionally, other social engineering attacks could leverage the Visualization API for opportunistic attacks on organizations much in the way other ClickFix-style attacks have managed to convince users to execute malicious code. To defend against these real and potential threats, organizations should take the following steps: - Manage users’ browsers, limiting use of developer-level functionality and deployment of browser extensions based on role. - Monitor for HTTP requests to “docs.google[.]com” from unknown applications or in the context of browser sessions that do not include other Google Docs activity. - Test and sanitize third-party dependencies in employee and customer-facing web applications regularly, checking for obfuscated script that appears out of place in JavaScript-based web and mobile applications. - Warn employees and customers of social engineering techniques and the dangers of modifying browser behavior through copy-and-paste code. Coverage The following ClamAV signature detects and blocks this threat: - Win.Backdoor.BadDav-10060502-0 - Win.Backdoor.GoProxShell-10060503-0 - Win.Malware.AmateraStomper-10060507-0 - Win.Backdoor.BadNetSup-10060508-0 - Js.Downloader.ClickFix-10060510-0 IOCs The IOCs for this threat are available at our GitHub repository here. Integrated Coverage Web Security Web Filtering