ClickFix on the Blockchain: More Than 5,400 Compromised Sites Distribute Malicious Code

WordPress and PrestaShop Turned Into Distribution Hubs

More than 5,400 compromised websites are participating in a criminal operation that combines ClickFix lures, smart contracts, and WebRTC communications. The activity, analyzed by Netskope and disclosed on September 5, 2026, primarily involves sites built with WordPress and PrestaShop.

The attackers inject a script into the sites that retrieves the next-stage payload from the BNB Smart Chain Testnet. As a result, pages belonging primarily to small businesses become distribution points for remotely controlled code.

It is not known how the initial access to the sites was obtained. Vulnerable components, stolen credentials, or other vectors may therefore be involved, but there is insufficient evidence to determine this. The versions of WordPress, PrestaShop, or any affected plugins have not been disclosed either.

The operation is not associated with a formally identified vulnerability: there are no known CVEs, standardized severity ratings, or entries in CISA’s Known Exploited Vulnerabilities catalog. The issue observed concerns sites that have already been compromised, not a specific flaw attributed to a single product.

The scale is significant. Netskope estimates that more than 300 infected sites are used every day. Since spring, the number of domains contacting BNB Smart Chain Testnet RPC endpoints has grown steadily. In August, the daily average approached 400 sites, with a peak of 536.

EtherHiding Moves the Payload Into a Smart Contract

The script injected into the sites does not necessarily contain the entire malicious chain. Instead, it queries a smart contract hosted on the BNB Smart Chain Testnet through RPC endpoints and retrieves code or configuration data from it.

This technique is known as EtherHiding. The blockchain is used as a persistent distribution layer, while the compromised site acts as the entry point to the victim.

Using the testnet offers several operational advantages. The network is intended for developers, replicates the mainnet’s functionality, and is available free of charge. RPC traffic can also blend in with legitimate activity involving blockchain applications and development tools.

Completely shutting down the campaign therefore requires more than removing a traditional web server. Content accessible through the smart contract remains available on the network, making a centralized takedown more difficult.

The attackers can also modify the content supplied by the contract. This allows them to replace a lure, stager, or configuration without manually reinjecting new code into all 5,400 sites.

That is precisely what happened during the observed activity: the initial ClickFix payload was replaced with a WebRTC Data Channel-based stager.

Fake CAPTCHA Tricks Victims Into Running PowerShell

The first observed variant displays a fake CAPTCHA within the compromised site. It is not a genuine technical verification, but a social engineering instruction designed to persuade users to compromise their own computers.

The victim is instructed to open the Windows Run dialog, paste a PowerShell command, and execute it. The command downloads and runs the final payload.

ClickFix thus bypasses one of the typical obstacles associated with browser-based infections. The site does not necessarily need to exploit an operating system vulnerability: it induces users to enter a command that appears to be necessary to resolve a problem or complete a verification.

The exact nature of the final payload has not been disclosed. No hashes, filenames, or additional indicators are available to associate the chain with a specific malware family.

For users, the clearest warning sign is behavioral. A legitimate CAPTCHA does not require users to open Windows Run, paste commands, or launch PowerShell. Any page that proposes this procedure should be closed without following the instructions.

The WebRTC Variant Executes JavaScript Without Writing It to Disk

In the next phase, the operators replaced the ClickFix content in the smart contract with a JavaScript stager based on a WebRTC Data Channel.

WebRTC is normally used by browsers for real-time communications. In this case, the stager creates a peer connection and data channel, generating a session description similar to the one used during a normal handshake.

The flow is anomalous, however: the stager constructs the response itself and feeds it back into the connection. It therefore avoids a genuine handshake while still opening a data channel to the attacker’s infrastructure.

The JavaScript code is received from a command-and-control address embedded in the stager. The data is buffered in browser memory and then executed when the channel closes or after 10 seconds.

Execution takes place dynamically by adding the code to the head element of the DOM. The content therefore does not need to be saved as a file on disk.

This approach reduces the number of artifacts available to file-focused security controls. It does not make the activity invisible, however: RPC requests, WebRTC traffic, browser behavior, and communications with the C2 remain observable.

The hardcoded command-and-control server address has not been made public. The specific RPC endpoint addresses involved are also unknown, although Netskope has identified a pool of endpoints to block in its recommendations.

Controls to Apply Across Sites, Networks, and Endpoints

Administrators of WordPress and PrestaShop sites should examine pages, templates, and components for injected scripts. The analysis should include requests to BNB Smart Chain Testnet RPC endpoints and comparisons with the site’s expected behavior.

The absence of known vulnerable versions means the response cannot be reduced to applying a single patch. Updating CMS platforms and components remains useful, but it does not prove that an already compromised site has been cleaned up. Direct verification of the code and network calls is required.

For enterprise defenders, Netskope recommends:

• blocking the pool of BNB Smart Chain Testnet RPC endpoints identified by the researchers;
• monitoring non-web UDP traffic associated with WebRTC;
• looking for anomalous RPC requests originating from WordPress and PrestaShop sites;
• detecting PowerShell launched through Windows Run;
• monitoring the dynamic execution of JavaScript in browser memory;
• identifying connections to C2 addresses embedded in the code.

Indiscriminate blocking requires an assessment of legitimate testnet use, particularly in development environments. Where this is not possible, RPC requests should be logged and correlated with the originating domain, browser, process, and subsequent WebRTC traffic.

The most useful indicators are therefore linked together. A visit to a site followed by an RPC call to the testnet and the opening of an unexpected WebRTC channel provides a stronger signal than any of these events considered in isolation.

After Initial Access, Many Actions Remain Unimpeded

The operation shows two distinct levels of compromise. On one side are the site operators, whose infrastructure is used to reach other victims. On the other are the users exposed to PowerShell commands or JavaScript delivered through WebRTC.

No named attribution of the attackers has been provided. The method used to breach the sites and the final destination of all infection chains also remain unknown.

Netskope’s separate reference to the Blue Report 2026 helps put the issue of post-entry activity into context. Based on 338 million simulations conducted in customers’ production environments, the report finds that once valid credentials are used, only 37% of attackers’ actions are blocked.

That figure does not attribute the ClickFix campaign to a specific vector and does not prove that stolen credentials were used. It does, however, highlight the limitations of a defense strategy assessed solely on its ability to stop initial access.

In this operation, detection must follow the entire chain: site compromise, blockchain query, victim interaction, PowerShell or WebRTC, and finally communication with the C2. Stopping any one of these steps can disrupt the attack. Failing to correlate them, however, leaves operators with several alternative paths.