Tech & Innovation

ClickFix Moved Into the Browser—and Google Sheets Hid Its Control Channel

|Author: QUASA Editorial Team|5 min read| 1
ClickFix Moved Into the Browser—and Google Sheets Hid Its Control Channel

The September 8, 2026 Talos investigation disclosed a monthslong ClickFix campaign that shifted malicious execution from operating-system commands into Chrome. Targets were persuaded to paste JavaScript into the address bar or install it through Tampermonkey, allowing code retrieved from public Google Sheets to manipulate cryptocurrency transactions inside the browser.

Google Sheets served as a concealed command-and-control channel in this campaign; the available evidence does not indicate that attackers compromised the service itself. A September 8 Threat Radar record summarizes the same central chain: a fabricated exchange vulnerability led to browser code execution, Google-hosted payload retrieval, altered deposit information and clipboard replacement.

The lure made the target execute the attack

A fake cryptocurrency vulnerability report directs the reader to execute browser JavaScript for a nonexistent bonus.

The operators circulated a Google Docs file styled as a leaked vulnerability report through Telegram, DarkForums and comments on paste sites. It falsely claimed that an obsolete or hidden API function at a cryptocurrency swap service could produce a larger payout or loyalty bonus.

An early version instructed the target to copy code from a paste site and place it in Chrome’s address bar with a javascript: prefix. A later version told the target to install the legitimate Tampermonkey extension and add a supplied userscript.

That instruction was the decisive trust transition. The target was not simply opening a document or following a link: they were granting unknown JavaScript permission to execute in the context of a cryptocurrency service. Tampermonkey added persistence because its userscript could activate again when the configured trading site was revisited.

Google Sheets concealed the second-stage code

Chrome retrieves obfuscated ClickFix payload fragments from a public Google Sheet and reconstructs them in the browser.

The first-stage loader constructed a request to the Google Visualization API and retrieved obfuscated JavaScript fragments from two cells in a publicly published spreadsheet. It joined those fragments, reconstructed the second-stage payload and injected the result into the active browser session.

The campaign abused a legitimate, read-only method for querying published spreadsheet data; it did not depend on a vulnerability in Google Sheets or the Visualization API. Because Chrome made the HTTPS request to docs.google.com, the retrieval could resemble ordinary browser traffic to a trusted Google service.

The operators made the code harder to notice by formatting spreadsheet text white on white and placing it far down the document. They also changed obfuscation keys and randomized names between versions, producing different-looking samples without materially changing the payload’s behavior.

The injected script changed responses, pages and copied addresses

Injected browser code replaces a cryptocurrency deposit address, changes the clipboard value and displays a false bonus.

Once active on a targeted exchange page, the second stage behaved like a web skimmer. It overrode the browser’s fetch function, inspected JSON responses associated with wallet or deposit endpoints and substituted an attacker-controlled Bitcoin address before the response reached the visible interface.

A MutationObserver watched the page for changes and helped the script rewrite relevant elements as the interface updated. Counterfeit bonus controls and modified transaction amounts supported the lure’s story, making the unauthorized changes appear to be part of a special exchange feature.

The script also intercepted copy actions. When a target copied a displayed deposit address, the clipboard could receive an attacker-controlled address instead. Comparing the compromised page with a value copied from that same page was therefore not an independent check: both could present the malicious destination.

In the Tampermonkey variant, closing the tab did not remove the loader. The userscript remained assigned to the targeted site and could retrieve and inject the payload during a later visit.

Four checks break the campaign’s trust chain

The attack requires several voluntary actions, so it can be interrupted before a cryptocurrency transfer. These checks follow from the documented mechanics; an unfamiliar script or changed interface is not, by itself, proof of this particular campaign.

  1. Reject any forum post, private message or shared document claiming that a hidden exchange bonus requires pasted JavaScript, developer features or a browser userscript.
  2. Review the Tampermonkey dashboard for unknown userscripts, unexpected update addresses and rules that match cryptocurrency sites. Disable unexplained scripts before returning to those services.
  3. Before transferring funds, compare the complete destination address with one obtained through a separate trusted path, such as the receiving wallet on a clean device. Do not rely on agreement between one browser page and its clipboard.
  4. Stop if a familiar exchange displays an undocumented bonus panel or changed transaction amount after a script was installed. Preserve the userscript and relevant browser details for investigation rather than testing the promised transaction.

Managed environments can also restrict extension installation by role. Browser traffic to docs.google.com is not inherently suspicious, but a spreadsheet request during an unrelated cryptocurrency session warrants closer inspection when it coincides with an unknown userscript or altered transaction interface.

The operator and full losses remain unknown

The campaign had already survived disruption attempts before publication. A September 8 SiliconANGLE account says the operators returned with a new spreadsheet within a week of an April takedown; it also lists 49 identified Bitcoin addresses, payments to 24 of them totaling 0.159 BTC, and Google documents that remained active when checked on August 11.

Those figures do not establish the campaign’s total victim count or losses because investigators could not recover every earlier payload and may not have identified every wallet. No named operator has been attributed to the browser campaign. The observed operation focused on cryptocurrency communities and two trading services; reuse of the technique against other browser applications remains a plausible risk rather than a documented expansion of this operation.

Also read:

Share:

Subscribe to our newsletter

Get the latest Web3, AI, and crypto news delivered straight to your inbox.

0