Over 5,400 hacked sites serve blockchain-stored ClickFix payloads via BNB testnet

Security researchers have documented a large ongoing campaign in which more than 5,400 compromised websites fetch their malicious components from smart contracts on the BNB Smart Chain Testnet. According to BleepingComputer, citing research from Netskope Threat Labs, the operation pairs the well-known ClickFix social-engineering trick with a second, quieter delivery path built on WebRTC data channels.

How the ClickFix vector works

Attackers planted inline scripts or loader code on legitimate sites, including ones running WordPress and PrestaShop. How those sites were originally breached has not been made public. When a visitor loads an infected page, the loader runs in their browser and sends a JSON-RPC eth_call to a BSC Testnet RPC endpoint, pulling content stored in an attacker-controlled smart contract.

The retrieved content renders a counterfeit verification prompt that coaxes Windows users into pasting a command into the Run dialog, with the command typically placed on the clipboard for them. Running it launches a downloader that uses PowerShell to fetch and execute a final payload. That final stage is not fixed, according to the reporting, so the operators can swap in different malware over time.

Hosting payload components on a blockchain testnet is sometimes called EtherHiding: the content lives on infrastructure the attackers do not have to maintain and that does not disappear when a conventional web host is taken down. Because testnets are free to use and rarely monitored, they make convenient dead-drop storage.

The WebRTC variant

The same contract infrastructure can also return a small JavaScript stager instead of a ClickFix screen. This stager already contains the command-and-control IP address, UDP port, ICE password, and DTLS certificate fingerprint, so it needs no signaling server at all. It generates the browser's connection responses itself and opens a WebRTC data channel directly to the C2.

JavaScript received over that encrypted channel is assembled in memory and injected into the page's DOM, reusing the CSP nonce of a legitimate script to slip past content security policy. When no nonce is available, the stager falls back to Function(). Once the code has run, the stager deletes the injected script element and closes the channel, leaving few traces on the endpoint.

What defenders should watch for

For website administrators, the indicators highlighted in the reporting include suspicious code appended to the end of legitimate JavaScript files, fake plugin directories, and outbound JSON-RPC requests to BSC Testnet endpoints. On the endpoint side, the signals are PowerShell or downloader execution that follows browser activity, clipboard use, and unexpected child processes or downloads. The WebRTC variant is harder to spot because the usual signaling artifacts, such as STUN/TURN traffic, are absent; monitoring raw outbound UDP from browsers to unfamiliar IPs and ports becomes the more reliable tell.

Suggested mitigations include monitoring CMS file and plugin integrity, blocking BSC Testnet RPC endpoints that no business need justifies, restricting unnecessary outbound UDP from browsers, applying application control around PowerShell, and teaching users that genuine CAPTCHAs never ask anyone to paste Windows commands anywhere.

Why it matters

The campaign shows how blockchain infrastructure turns a sprawling set of individual site compromises into a centrally managed distribution network: a single update to one smart contract can change what all 5,400-plus sites serve. The WebRTC path compounds the problem by executing entirely inside the browser context, dodging both file-based detection and traditional network indicators. It is also worth noting the limits of the headline figure, as the reporting makes clear the site count is not a count of infected endpoints, and public information does not confirm which final payloads ran or how many users were actually compromised.