As reported by BleepingComputer, researchers at Netskope have uncovered a sprawling campaign of over 5,400 compromised websites delivering ClickFix social-engineering payloads with a critical twist: the malicious code is stored in smart contracts on the BNB Smart Chain (BSC) Testnet, a technique dubbed EtherHiding. This convergence of social engineering and blockchain-resilient infrastructure marks a significant evolution in delivery-chain architecture that defenders need to understand.
Why Blockchain-Based Payload Hosting Changes the Game
The core threat here is not the ClickFix lure itself — fake CAPTCHA pages instructing users to run PowerShell commands are well-documented. The innovation is the infrastructure resilience model. Traditional C2 endpoints can be seized, sinkholed, or blocked at the network edge. Smart contracts on a public blockchain cannot be unilaterally removed by any single party, including the exchange or law enforcement. This gives attackers a persistent, mutable payload repository that is effectively untouchable through conventional takedown procedures.
The BSC Testnet specifically is attractive because it mirrors mainnet functionality at zero cost. The threat actor can update the smart contract to swap payloads on the fly — as observed when they shifted from a standard ClickFix PowerShell dropper to a WebRTC data-channel stager that executes code in-memory without touching disk. That in-browser execution via a self-completed WebRTC handshake is particularly notable because it bypasses many endpoint detection rules that look for process spawning from browser sessions.
Who Is Most at Risk
The WebRTC Evolution Signals Sophistication
The shift from a standard ClickFix PowerShell dropper to a WebRTC data-channel stager that fabricates its own handshake response indicates the threat actor is actively iterating to evade detection. In-memory DOM injection means no filesystem artifacts — a significant challenge for traditional EDR workflows.
This evolution suggests the operator is monitoring defender responses and adapting. The self-handshaked WebRTC channel is clever: it avoids a real peer negotiation while still opening an encrypted data path to the attacker's C2. Security tools that inspect WebRTC signaling traffic for anomalies may not flag a connection that appears to complete a legitimate negotiation.
Shield53 Recommendations
- Block BSC Testnet RPC endpoints at your egress proxy, firewall, and DNS filtering layers. The Testnet has no legitimate business use for the vast majority of organizations.
- Audit CMS platforms — prioritize WordPress and PrestaShop installations for integrity checks. Look for injected scripts loading external resources, especially anything referencing blockchain RPC endpoints.
- Deploy browser isolation for high-risk user groups to neutralize in-browser payload execution techniques like the WebRTC stager.
- Update EDR detection rules to flag PowerShell execution originating from browser processes, clipboard-paste-driven command execution, and anomalous WebRTC data-channel connections from browser contexts.
- Educate users on the ClickFix pattern specifically — no legitimate CAPTCHA requires opening a Run dialog or pasting commands into a terminal.
- Monitor DNS logs for queries to known BSC Testnet RPC domains and treat hits as potential compromise indicators on the source host.
The broader implication is clear: defenders are now facing infrastructure that was designed to be censorship-resistant being repurposed as attack infrastructure. Expect this pattern to expand to other chains beyond BSC. The security community needs to develop blockchain-monitoring capabilities that treat smart contract code storage as a potential threat vector, not just a cryptocurrency concern.
