Cyber Crime Smart Contracts for C&C: How ClearFake Hid in Plain Sight on BSC Testnet TrendAI™ Research analyzed an intrusion where threat actors used the EtherHiding technique to route ClearFake payload delivery through smart contracts on the BNB Smart Chain testnet. The attack chain ended with two simultaneously deployed stealers, SectopRAT and ACRStealer alongside an on-chain execution tracker that confirmed each victim compromise in real time. By: Ryan Soliven May 26, 2026 Read time: ( words) Save to Folio Key takeaways: Threat actors used EtherHiding to store ClearFake payload, routing instructions inside BNB Smart Chain testnet smart contractsmaking an immutable, free to operate infrastructure that cannot be taken down due to the nature of a blockchain network. The attack chain delivered two simultaneous payloads, SectopRAT (a .NET-based RAT capable of browser session hijacking), and ACRStealer (a C++ infostealer) via a ClickFix social engineering overlay, with separate payloads for Windows and macOS victims routed by OS detection. An on-chain execution tracker embedded in the smart contract confirmed each victim compromise in real time. Four smart contracts shared a single deployer wallet, with the oldest deployed nearly a year before analysis, confirming that this blockchain C&C has been a long-running, actively maintained campaign, not a one-off experiment. TrendAI™ Research analyzed in May 2026 an intrusion where threat actors used a technique known as EtherHiding to store payload routing instructions inside BNB Smart Chain (formerly Binance Smart Chain or BSC) smart contracts. Unlike traditional command-and-control (C&C) infrastructure, this routing layer cannot be altered, suspended, or seized by security vendors, registrars, or law enforcement due to the immutable nature of the blockchain. TrendAI™ found that the injected JavaScript on compromised websites queried these contracts to retrieve and route victims to the next stage of the attack chain. Blockchain as command-and-control infrastructure Smart contracts are self-executing programs on blockchain networks that enable trustless transactions without central intermediaries, forming the backbone of decentralized finance. BNB Smart Chain is an Ethereum-compatible network where contracts with arbitrary data are written in Solidity and compiled to bytecode that runs identically across every node. The EtherHiding technique was first documented by Guardz in October 2023 where threat actors injected a JavaScript loader into compromised websites that retrieves malicious next-stage payload data directly from a BSC contract via a standard eth_call request. This bypasses URL-based blocking entirely since no payload URL exists in any static file. The ClearFake campaign refined this technique by storing the entire payload JavaScript on-chain rather than just a URL, so malicious code is returned in full and executed in the victim's browser with no external hosting required. Google's October 2025 research confirmed that North Korean state-sponsored actors ( UNC5342 ) have since adopted the same technique, indicating that blockchain C&C has now been adopted by nation-state capability. Blockchain C&C is operationally attractive for cybercriminals because it is immutable, decentralized, and cost nothing: Payload data written to a blockchain cannot be sinkholed, deleted or seized. It is replicated across thousands of nodes with no central server to take down. By operating on the BNB testnet, threat actors pay nothing because test BNB has no monetary value and is freely available from public faucets. The contract architecture This analysis began as a TrendAI Vision One™ Managed Detection Response (MDR) case, where a customer organization had one employee browsing a legitimate recreational website and then ended up with a multi-stage compromise that included a silently installed full Python-based Remote Access Trojan, an attempted shellcode injection, and browser credentials targeted. It should be noted that all filtering, dispatching, and overlay rendering happened client-side in the victim's browser after retrieval from the contracts, not within the contract logic itself. During analysis, TrendAI™ Research identified four distinct smart contract addresses across the attack chain, each discovered one stage deeper than the last: 0xA1decFB75C8C0CA28C10517ce56B710baf727d2e was found in the Stage 1 JavaScript injected into the compromised website. It holds base64-encoded JavaScript for an anti-analysis dispatcher. This blog refers to it as Smart Contract A . 0x46790e2Ac7F3CA5a7D1bfCe312d11E91d23383Ff was found in the Stage 2 JavaScript decoded from that contract's storage. It is a Windows-specific ClickFix overlay. This blog refers to it as Smart Contract B . 0x68DcE15C1002a2689E19D33A3aE509DD1fEb11A5 was found in the Stage 2 JavaScript decoded from that contract's storage. It is a macOS-specific payload. We will refer to this as Smart Contract C . 0xf4a32588b50a59a82fbA148d436081A48d80832A was found in the Stage 3 JavaScript decoded from the Windows payload contract. It stores conversion states, polled by the overlay JavaScript to detect when the victim had executed the payload. This blog will refer to it as Smart Contract D . The Solidity contract deployed for this campaign implements three functions. The set() function ( selector 0x4ed3885e ) is restricted to the contract owner via an address equality check and accepts a string payload. It writes that string directly into the contract's own on-chain storage. The get() function ( selector 0x6d4ce63c ) is publicly callable with no access control and returns the stored string directly from contract storage. This is what the victim's browser calls via eth_call . The owner() function returns the deployer's wallet address. The contracts contain no complex logic; each is a minimal key-value store. A payload update requires a single on-chain transaction calling set() and then propagation to every site querying the contract is immediate. Smart Contract A is the entry-point contract used in this campaign and operates exactly on this model. The threat actor called set() once to write the base64-encoded Stage 2 JavaScript payload into the contract's on-chain storage. From that point, any caller anywhere in the world including the victim's browser could call get() to retrieve the full payload string. Crucially, no server hosts the data; it lives inside the contract storage on every BSC node simultaneously and cannot be removed due to the nature of a blockchain. On-chain verification of all four contracts confirms they share a single deployer wallet: 0xd71f4cdC84420d2bd07F50787B4F998b4c2d5290 . The deployment timeline establishes the campaign's operational history: The Stage 1 entry-point contract Smart Contract A was deployed on May 26, 2025 The Windows and macOS payload contracts Smart Contract B and Smart Contract C were deployed on September 24, 2025 and September 30, 2025 respectively The execution confirmation tracker Smart Contract D was on June 18, 2025 BSCScan transaction data confirms the campaign was actively updating payload contracts and recording new victim executions at the time of this analysis. Attack analysis Figure 1. Attack Diagram Initial access: The compromised watering hole The victim browsed a legitimate Swiss recreational activity site running on WordPress where 22 scripts loaded by the page were legitimate WordPress and plugin resources, but one was not. A <script src="data:text/javascript;base64[REDACTED]"> tag had been injected at line 146 of the page's <head> section. The payload was delivered as inline data, a URI with no external domain reference and no URL to block. The base64-decoded content revealed the ClearFake Stage 1 loader. Figure 2: View-source of the Swiss website showing the injected ClearFake Stage 1 loader Stage 1: The injected JavaScript and blockchain query Decoding the injected <script src="data:text/javascript;base64[REDACTED]"> tag revealed an obfuscated JavaScript file. The obfuscation uses a standard anti-static-analysis technique with two components: A string-array rotation pattern, where a function (_0x4e2e()) returns all plaintext strings as an indexed array. A runtime rotation where a self-invoking function shuffles that array at runtime until an integer checksum validates. Deobfuscation by resolving the string-array indices reveals the following plaintext strings embedded in the script: hxxps://bsc-testnet-rpc.publicnode[.]com/: A BSC RPC endpoint eth_call: A JSON-RPC method Smart Contract A : The Stage 1 contract address 0x6d4ce63c: The function selector for get() application/json: A request Content-Type result, json, slice, fromCharCode, apply: The response decoding chain The core logic, once deobfuscated, is the async load_() function shown below: Figure 3. The deobfuscated Stage 1 load_() function, the async blockchain query that constructs an eth_call JSON-RPC request to Smart Contract A on the BSC testnet At this stage, three points are forensically significant. The ABI (Application Binary Interface) decoding is done entirely in custom JavaScript. The script manually parses the EVM ABI-encoded string response (32-byte offset, 32-byte length, then raw string bytes) rather than using a Web3 library, minimizing dependencies and keeping the script self-contained. In the context of Ethereum and EVM-compatible blockchains, ABI defines the standard that function calls and data are encoded when communicating with a smart contract. The contract is called on the BNC Smart Chain testnet (not mainnet), an operational choice that makes the infrastructure cheaper to deploy and harder to attribute. The error handler is a silent empty function .catch(() => {}) , no user-visible error if the call fails, ensuring the compromise is invisible to the victim. Stage 2: Sandbox detection and payload routing During analysis, TrendAI™ Research found that the attack implemented two environment