Malware on the Blockchain: An Ongoing Campaign’s New WebRTC Twist

EtherHiding, a technique that uses blockchain smart contracts as takedown-resistant payload storage, has been seen across more than 5,400 compromised websites in the last few months. The compromised websites have little in common beyond being small businesses (clinics, plumbers, e-commerce shops) with no shared industry, region, or owner. These compromised sites include either an inline script or a spoofed package that calls the BSC testnet and downloads a ClickFix overlay as the next step of the attack, which instructs visitors to run a command on their PC. We also observed a newer variant that, instead of a ClickFix overlay, opens a covert WebRTC data channel for Command and Control.

What we observed

Netskope telemetry flagged thousands of small-business websites making the same unusual request, a JSON-RPC call to a BNB Smart Chain (BSC) testnet endpoint. The victims had little in common beyond being small-business websites. Where we examined individual sites, they were most often WordPress, and sometimes PrestaShop. How the sites were initially compromised is currently unknown. Each site carried a small injected script that reads its next payload from a smart contract and executes it in the visitors’ browser when loaded. The blockchain acts as the dead drop: the operator can change what every compromised site delivers by updating a single contract, and each visitor retrieves the new version on the next page load. Across our observation window, we counted more than 5,400 distinct compromised sites beaconing these endpoints, spanning more than 2,200 organizations worldwide, with several hundred active on any given day. The daily volume has trended steadily upward since the spring, and we are currently seeing more than 300 sites each weekday, as pictured in the figure below.

Why testnet rather than mainnet

BSC (BNB Smart Chain) runs smart contracts, small programs that operators use to hold and serve the payload. Its production chain, mainnet, charges real BNB for every transaction, including contract deployments, and updates. Testnet is a parallel copy of that chain, meant for developers. It behaves just like mainnet, but its BNB has no monetary value and is handed out for free by faucets, so developers can deploy and rewrite contracts without spending anything.

That free developer sandbox is exactly what makes testnet attractive for threat actors. They get the same smart-contract hosting and the same takedown resistance as mainnet at no cost, repurposing free developer infrastructure as a durable, hard-to-remove payload host.

The delivery chain

The chain is short and the same everywhere it starts:

1. A compromised site carries an injected loader. The loader can either be an inline script or a spoofed package.

2. The loader makes a JSON-RPC eth_call to a BSC testnet smart contract. It returns a second-stage script stored on-chain, which the loader runs.
3. That script is a ClickFix lure: running it blurs the page behind a fake CAPTCHA overlay that tells the visitor to open a Run dialog and paste a command.

4. The pasted command is a downloader that pulls and runs the final payload.

The final payload is not fixed. Because the operator controls the contract, the same delivery primitive can lead different visitors to different endings.

A WebRTC data-channel variant

While decoding the chain on a sample of sites, we found a different variant that delivers something besides ClickFix, and we pulled it apart line by line: a WebRTC data-channel stager. The eth_call hands the browser a small block of JavaScript whose entire job is to open a covert channel to the cyberattacker and run whatever comes back through it.

WebRTC powers browser-based video calls and peer-to-peer data. Normally, two peers exchange connection details through a signaling server: each offers a session description (a standard message containing the call details, IP address, credentials, and a certificate fingerprint for authentication), the other answers, and only then does a channel open. This handshake leaves observable artifacts for defenders to see (DNS lookup for the server, STUN/TURN traffic to known providers, DTLS handshake packets), but this variant bypasses the handshake process entirely.

The script creates a peer connection and a data channel, then generates the required session description offer just like a normal WebRTC handshake. But instead of sending that offer anywhere and waiting for a real reply, it hand-writes the answer itself and feeds it straight back into the connection. This way, no handshake happens, but a data channel to the cyberattacker still opens:

Every value a real answer would negotiate is hardcoded instead: the C2’s IP (built from separate numbers so it never appears as a string), the UDP port, the ICE password, and the server’s DTLS fingerprint. Since the stager already knows the fingerprint, the encrypted channel opens on the first packet, with no certificate exchange, and no signaling traffic to observe. The browser thinks it got a valid answer, but really it was talking to itself until it reached out to the cyberattacker over UDP.

Once the channel opens, the C2 streams its code over it. The stager buffers every message that arrives, then executes the reassembled result the moment the channel closes (or after a ten-second backstop):

Nothing is written to disk and no eval string touches the network. Instead, the code is executed by appending it to the head of the DOM. To satisfy the site’s Content Security Policy, the stager lifts the nonce from a legitimate script already on the page and reuses it on its own injected <script>, so the browser treats the cyberattacker’s code as authorized (if no nonce exists, it falls back to Function()). The script node is removed immediately after it runs, and the channel is torn down, leaving little behind.

Conclusion

This campaign shows how far cyberattackers will go to make their delivery infrastructure durable. By reading payloads from a BSC-testnet smart contract, the operator gets a dead drop that no host or registrar can take down, and that can be rewritten for every victim from a single contract. Across our observation window, that reach extended to more than 5,400 compromised sites, and it is still growing. The WebRTC variant pushes the same idea onto the command channel: by hand-writing its own answer, it skips the signaling handshake entirely and opens an encrypted channel that is harder for a web proxy to inspect. We expect to see more attacks that combine takedown-resistant storage with these harder-to-inspect transports.

Netskope Threat Labs is tracking this campaign and continues to update detection coverage for the RPC endpoints, delivery infrastructure, and payloads described here. Customers can reduce their exposure today by blocking the full BSC-testnet RPC pool rather than the primary endpoint alone, and monitoring non-web traffic for the WebRTC channel that HTTP inspection does not see. Site owners should integrity-check their CMS assets, since the loader is appended to a legitimate JavaScript file or placed in a fake plugin directory.

Indicators of compromise

The full list of indicators for this campaign is published in the Netskope Threat Labs IOC repository.