Two Smart Contracts Reveal Two Ways EtherHiding Sustains Attacks

EtherHiding is often described as a way for attackers to hide malicious infrastructure behind a blockchain smart contract. Source Defense Research found something broader: the contract can become a long-term control layer that attackers continuously update as their infrastructure, code, and delivery methods change.

An analysis of two malicious contracts, one on BSC Testnet and one on Polygon, documented 69 contract-data updates and 46 distinct attacker-controlled domains. The contracts are not attributed to the same threat actor, and they operated very differently. One evolved as a remotely managed JavaScript loader over roughly 495 days. The other acted as a rapid domain-rotation system, directing compromised websites toward newly registered infrastructure that changed approximately every two days.

The comparison shows why EtherHiding should be viewed as more than a technique for concealing a malicious domain or payload. It can give attackers a persistent, remotely editable control point between a compromised website and infrastructure designed to change.

A Deeper Look at Two EtherHiding Operating Models

Source Defense Research analyzed the full transaction histories of two malicious smart contracts: 0xc9233895f25B1135Bd0bd352b4B97A7C7210f33B on BSC Testnet and 0xB6bC9e1D0b2fB96Ab7C47E04Cb0BE477410bC1f2 on Polygon. Together, they recorded 69 data updates and exposed two distinct ways EtherHiding can be used as long-term attack infrastructure.

Both contracts solved the same operational problem: how to keep control of a compromised website without repeatedly modifying the site itself.

A loader on the affected page could query the blockchain, retrieve the current instructions or delivery location, and continue the attack in the visitor’s browser. Once that mechanism was established, the attacker could change what happened next by updating the contract rather than reinfecting every website.

The similarities largely end there.

The BSC Testnet contract behaved like an evolving loader-development channel. Across 25 recorded changes, the attacker modified executable code, obfuscation, transport logic, execution techniques, and command-and-control endpoints.

Most versions reconstructed a concealed WebSocket endpoint, connected the browser to attacker-controlled infrastructure, received additional JavaScript, and executed that code in the page. Twenty-three of the 25 versions relied exclusively on WebSocket. Two later versions experimented with an HTTP Fetch fallback.

The earliest updates were especially revealing. Several different versions appeared within the first 90 minutes, including changes between browser-based JavaScript and server-side PHP injection. Later updates introduced nested Base64 encoding, XOR-encoded character arrays, RC4-style decoding, dynamically generated functions, Blob-based execution, and injected scripts.

The implementation kept changing, but the underlying behavior was much more consistent: establish a connection to attacker infrastructure and execute remotely supplied JavaScript.

That distinction matters for detection. Code hashes, domains, variable names, and obfuscation patterns can change enough to make related samples appear different. Browser behavior is harder to disguise. Dynamic code execution, unexpected WebSocket activity, and scripts retrieving instructions from external infrastructure remain meaningful signals even as the code surrounding them changes.

The BSC contract history also preserved evidence of what appears to be live development and troubleshooting. One deployment contained an apparent variable mismatch that likely prevented the loader from working. Roughly an hour later, the attacker restored the previous version. Later, the attacker introduced a hybrid WebSocket and Fetch design with multiple execution methods, but the HTTP fallback itself appears to have been incorrectly implemented. The design was eventually abandoned in favor of another WebSocket-only loader.

The blockchain therefore recorded more than infrastructure changes. It preserved errors, reversions, experimentation, and architectural decisions that might otherwise have disappeared when a malicious file was overwritten.

The Polygon contract followed a different model.

Instead of storing an executable loader, it stored the current HTTPS delivery address. During approximately 103 days of observed activity, the attacker made 44 content changes and used 36 distinct domains. Forty-one of 43 consecutive transitions changed the domain, and the median interval between changes was approximately 48 hours.

This created a rapidly changing directory for disposable infrastructure. A loader on the compromised website could remain relatively stable while the smart contract supplied a new destination whenever the attacker wanted to move the next stage of the operation.

Domain-registration timing makes that process especially visible. Every domain observed in the contract was registered no more than four days before use. Thirty-two were registered on the same date they were written to the blockchain, while another nine appeared one day after registration.

The pattern suggests an organized infrastructure cycle: register a domain, prepare the server, publish the new address through the contract, direct affected browsers toward it, then replace it shortly afterward.

Even the naming strategy changed over time. Early domains favored the .beer top-level domain, while later activity shifted heavily toward .info. The available evidence does not establish why. Cost, availability, reputation filtering, enforcement, or operational preference could all play a role. What the history does establish is that the attacker was adapting the infrastructure strategy itself rather than simply replacing individual domains.

Short reversions and repeated writes also appeared throughout the Polygon history. Some endpoints were restored within minutes, while others were written to the contract more than once within seconds. These patterns could reflect testing, failover, automated deployment, or retries, but the transaction record alone cannot distinguish between them.

The broader infrastructure around the Polygon case also demonstrates why defenders should be cautious about treating one contract address as the full scope of an EtherHiding operation. The contract creator deployed 201 contracts, and Source Defense Research identified additional contracts in that group containing changing malicious domains. Not every contract was confirmed as malicious, so further analysis would be required before assigning a role to the entire portfolio.

Taken together, the two cases expose two distinct ways to use the same blockchain capability.

The BSC Testnet contract allowed the attacker to change the loader itself: its code, obfuscation, execution methods, transport, and destinations.

The Polygon contract allowed the attacker to keep the surrounding loader stable while continuously replacing the infrastructure it contacted.

In both cases, the smart contract separated the compromised website from the infrastructure delivering the next stage. That separation is what gives EtherHiding much of its operational value.

It also exposes its forensic weakness.

Blockchain transactions preserve historical state. Earlier domains, broken deployments, restored versions, changes in obfuscation, infrastructure experiments, and shifts in registration strategy remain visible after the attacker has moved on.

That makes historical contract analysis valuable for threat hunting and incident scoping. Looking only at the contract’s current value can miss much of the infrastructure and behavior associated with the operation.

For client-side defenders, the same principle applies at runtime. Fixed indicators such as a domain, URL, contract address, hash, or encoded string can become stale quickly. The browser behavior consuming those indicators provides a more durable security signal.

Source Defense evaluates what scripts are doing inside the browser and applies policies accordingly. Behaviors such as accessing sensitive data, executing risky actions including new Function, using browser storage, or sending data to unexpected destinations can remain relevant even when an attacker rotates domains or rewrites the surrounding code.

That runtime visibility is particularly useful against a model like EtherHiding, where infrastructure is designed to change without requiring significant changes to the compromised website.

Conclusion

These two contracts show that EtherHiding is better understood as an operating model than as a single implementation.

One contract evolved a malicious loader for almost 500 days. The other rotated through 36 domains in just over three months, with most infrastructure registered immediately before use. Across both cases, the visible details changed repeatedly while the strategic purpose remained stable: preserve a foothold on the compromised website while allowing downstream infrastructure to change through blockchain updates.

For defenders, that makes individual indicators a moving target. Blocking the domain visible today is useful, but the next contract update may point affected browsers somewhere else minutes or days later. Hashes, URLs, contract addresses, and domains can all become stale while the underlying browser behavior remains much more consistent.

This is where Source Defense adds an important layer of protection and visibility. Source Defense evaluates what scripts are doing inside the browser and applies policies accordingly, rather than relying only on fixed infrastructure indicators. In an EtherHiding-style operation, that runtime view can surface behaviors such as Sending data to a blacklisted domain, Loaded from a blacklisted domain, Using 1st party cookies, and Using browser storage when those behaviors are present. Source Defense will proactively detect new scripts as they begin running on your website, flag when they are loaded from recently created domains, and apply runtime policies to control what those scripts can access and do in the browser.

That matters because both contracts in this research were designed around change. The Polygon operation replaced delivery domains approximately every two days, while the BSC Testnet contract repeatedly altered loader code, obfuscation, execution methods, and command-and-control infrastructure. A defense centered only on known domains or static signatures would need to keep catching up.

Source Defense extends that defensive view into the browser, where the attack ultimately executes. Runtime monitoring and control help security teams focus on what scripts are actually doing, while alerts and script-behavior visibility provide signals that can remain relevant even as attackers rotate infrastructure.

The broader lesson from EtherHiding is that the most durable defense is not tied to the attacker’s current domain, loader version, or smart contract value. It comes from combining infrastructure intelligence with continuous visibility into client-side behavior, helping organizations protect customer data as the attack changes around them.