BLOCKCHAIN ABUSE SURGES AS ETHERHIDING CAMPAIGN REACHES 1,000 WEBSITES

Blockchain Abuse Surges as EtherHiding Campaign Reaches 1,000 Websites

Attackers behind a rapidly growing EtherHiding campaign can switch malicious infrastructure across approximately 1,000 compromised websites without changing those sites again. EtherHiding is a technique that uses blockchain smart contracts to store malicious code, infrastructure details, or configuration that compromised websites can retrieve and execute in the browser. In this campaign, BNB Smart Chain Testnet contracts act as a remotely controlled delivery layer: code left on each compromised website retrieves the contract’s current instructions and executes them in the visitor’s browser. In one confirmed case, the same contract switched from dntds[.]shop and sdntds[.]shop to cloudfrontenterprise[.]com within four days while the compromised websites remained unchanged. That is the central danger of EtherHiding: blocking today’s malicious domain does not remove the loader or prevent the attacker from directing the same compromised sites to different infrastructure tomorrow.

Attack details

EtherHiding separates the compromised website from the attacker’s active downstream infrastructure. Instead of hardcoding the current malicious domain into every affected site, the attacker leaves behind code that queries a blockchain smart contract for its latest instructions. The website-side code can remain stable while the data returned by the contract changes remotely.

That capability was observed directly in this campaign. One monitored BNB Smart Chain Testnet contract initially returned JavaScript that contacted dntds[.]shop and sdntds[.]shop. Four days later, the same contract returned different JavaScript pointing to cloudfrontenterprise[.]com.

The contract address did not change. The contract query did not change. Most importantly, no corresponding modification was required on the compromised websites.

The campaign footprint has grown from approximately 395 compromised websites to around 1,000 worldwide, and discovery is continuing. The affected sites observed so far appear to be WordPress websites.

The wider operation has been linked to four BNB Smart Chain Testnet contracts. In the analyzed cluster, attackers used three different ways to place the initial malicious logic on compromised websites.

One method used heavily obfuscated JavaScript embedded directly into the page. Another used locally hosted JavaScript files commonly named bsc-loader.js or css.js. These files searched the page for an inline element called bscSl, which contained the information needed to identify or query the smart contract. A third method loaded JavaScript from cdn.claritydelivr[.]com/mpackage.js.

Although the initial delivery mechanisms differed, the observed paths converged on the same downstream model. The browser queried the same BSC Testnet contract, retrieved its current response, decoded the returned JavaScript, and executed it.

The browser performed this lookup through a public blockchain RPC service using a JSON-RPC eth_call to the contract’s get() function. The returned value was ABI-encoded and contained Base64-encoded JavaScript. The website-side code decoded that value and inserted the resulting JavaScript into the page for execution.

The significance is not the encoding itself. The smart contract acts as a remotely changeable control layer between the compromised website and the attacker’s current infrastructure.

A single update to the contract can therefore change what every connected website delivers.

That is exactly what happened during monitoring. The earlier contract response directed the browser to dntds[.]shop and sdntds[.]shop. Four days later, the same contract supplied code using cloudfrontenterprise[.]com.

The newer code created an external script request to the new infrastructure and also generated an image request containing random and timestamp values. The external script request caused additional JavaScript to execute. The available evidence does not establish a specific purpose for the image request, which may have been used for a check-in, tracking, or another server-side function.

The attackers also used selective-delivery and anti-analysis checks. The initial code examined user-agent strings, referrers, and URLs and attempted to avoid bots, crawlers, scanners, command-line tools, WordPress administration pages, APIs, feeds, static files, and other requests unlikely to represent an ordinary visitor.

These checks mean the approximately 1,000 compromised websites should not be interpreted as 1,000 confirmed victim executions. They represent the observed distribution footprint. Individual visitors may still be excluded by browser checks, operating-system targeting, or additional server-side filtering.

Visitors who pass those checks ultimately reach a Windows-only ClickFix attack. ClickFix is a social-engineering technique that presents a fake browser error, verification prompt, CAPTCHA problem, security warning, or similar message and instructs the victim to open a Windows command interface, paste a command, and execute it.

The victim performs the final execution step. Once that command runs, the attack moves from browser-based delivery into the Windows endpoint, where additional malware can execute outside the normal boundaries of webpage JavaScript.

EtherHiding makes the delivery chain harder to disrupt with static indicators. The browser’s first external interaction may be with legitimate public blockchain RPC infrastructure rather than an obviously malicious server. The malicious destination appears only after the contract response has been retrieved and executed.

More importantly, blocking that destination does not remove the underlying delivery mechanism. The attacker can update the contract and redirect every connected compromised website to new infrastructure without reinfecting the sites or changing the loader already present on them.

How Source Defense protects you

In this attack, Source Defense can identify suspicious browser activity associated with the malicious code and alert security teams when that activity reaches unexpected or known-malicious destinations.

When the code sends data to a destination outside the expected website or script ecosystem, Source Defense can generate a Sending data to other alert. If the destination is already recognized as malicious, Source Defense can generate a Sending data to a blacklisted domain alert.

These behaviors are particularly relevant to EtherHiding because the destination can change while the compromised website remains untouched. A site that previously communicated with dntds[.]shop or sdntds[.]shop can begin reaching cloudfrontenterprise[.]com after a contract update without any corresponding change to the website-side code.

Source Defense surfaces relevant activity through dashboard summaries and the bell notification center. Security teams can review Found in blacklists and Script behaviors when applicable, while email and webhook notifications can support faster investigation of newly observed destinations.

This gives defenders a behavioral signal that does not depend entirely on a malicious domain, URL, filename, or hash remaining unchanged.

Key takeaways

EtherHiding turns a website compromise into a persistent launch point. The attacker does not need to return to hundreds of compromised sites every time infrastructure is exposed or blocked. The website retains the mechanism for retrieving instructions, while the smart contract determines what those instructions are today.

That makes the campaign’s growth particularly concerning. The observed footprint has expanded from approximately 395 compromised websites to around 1,000, and one contract update can potentially change the next stage delivered through every site connected to it.

The live infrastructure change demonstrates the advantage clearly. dntds[.]shop and sdntds[.]shop could be identified, investigated, and blocked, yet the same unchanged loaders could later retrieve instructions pointing to cloudfrontenterprise[.]com.

Domains, URLs, filenames, container IDs, and hashes remain useful indicators, but they describe a specific state of the campaign. They do not neutralize a loader that continues retrieving fresh instructions from an attacker-controlled contract.

Content Security Policy (CSP) and Subresource Integrity (SRI) are browser-enforced controls focused on permitted resources, policy enforcement, and integrity. They can help constrain known resource-loading patterns, but dynamically retrieved instructions create challenges for defenses centered on fixed sources or expected hashes.

WAFs, firewalls, backend logs, and server-side monitoring operate outside the visitor’s browser. They may detect related traffic or changes elsewhere in the environment, but they do not directly observe every action performed by JavaScript inside an individual browser session.

Source Defense adds behavioral detection inside the browser. In this campaign, Sending data to other and Sending data to a blacklisted domain can expose suspicious activity even as attackers rotate the downstream infrastructure supplied through the smart contract.

The defining risk of EtherHiding is resilience: compromise the website once, leave the loader in place, and change the next stage remotely. Taking down yesterday’s malicious domain does not neutralize tomorrow’s attack.