Eduardo Callejas

Blocking a domain or taking down a server remains one of the main ways to disrupt an attack. The aim is to break communication between the malware and its command-and-control (C2) server, from which malicious actors send instructions and manage compromised devices. That model, however, is evolving. Some campaigns replace the fixed address embedded in the malware with a reference stored in a Polygon smart contract. If the infrastructure becomes unavailable, the attacker can update that reference and redirect already deployed malware to a new C2. This technique, known as EtherHiding, is not exclusive to Polygon. Nor does it turn the network itself into malicious infrastructure or mean that the entire attack takes place on the blockchain. Instead, it uses a legitimate capability to make the mechanism used by the malware to locate its C2 more resilient, which can complicate some detection and response activities. EtherHiding makes it possible to change the C2 reference without modifying malware that has already been deployed. Why Polygon PoS is useful for EtherHiding Polygon PoS is a public network compatible with the Ethereum Virtual Machine (EVM), an execution environment compatible with Ethereum. Smart contracts are programs that can store data and respond to queries. This capability makes it possible to create decentralised applications and other blockchain-based services, but it can also be used to publish information that another application can retrieve when needed. Three characteristics are particularly relevant to this type of campaign: compatibility with Ethereum tooling, RPC providers that allow applications to query the network, and relatively low transaction costs for write operations. This means threat actors can deploy contracts, query their data and update specific values without relying on a single domain. Read operations are generally performed via RPC without creating a transaction or paying the network fee known as gas. Deploying a contract or changing its values, however, does require a transaction and payment of that fee. This interest does not stem from a vulnerability in Polygon. As with other digital services, a legitimate capability can be used both legitimately and maliciously: in this case, the contract can expose server addresses, domains or other data required by a campaign. ■ For Cybersecurity teams, the implication is that the contract acts as a lookup point that the attacker can maintain and update with the information required at different stages of a campaign. When the malware is designed to retrieve that information, changing a domain or address may not require a new version of the malicious code. The difference becomes clearer when compared with a C2 model based on a fixed reference. How EtherHiding replaces a fixed C2 reference In a traditional model, the malware contains a domain or IP address used to locate the C2 server, which is typically hosted by a hosting provider. This fixed reference gives defenders a point of intervention: if they block the domain or the server becomes unreachable, they can disrupt communication with compromised devices and reduce the attacker's ability to control them. EtherHiding changes that point of dependency. Instead of embedding a fixed address, the malware or another component queries a Polygon smart contract to retrieve the current C2 reference. If the C2 or external infrastructure becomes unavailable, the attacker can update the value in the contract and redirect components that have already been deployed. The blockchain records the transactions used by the operator to update the state of the contract, but not every read query. At the same time, the contract logic can authorise an account to modify specific values. This design makes lasting disruption more difficult, but other intervention points remain, including the RPC services being used and the external infrastructure referenced by the contract. The contract makes it possible to update the reference; communication with the C2 remains external to the blockchain. How EtherHiding works through smart contracts In an EtherHiding-based campaign, the smart contract acts as a source of information that operators can update. The malware or another component of the attack queries the contract to retrieve the C2 address, a domain used to download the next stage or specific instructions. This read operation does not change the contract state or create a new blockchain transaction in itself: operators update the values and compromised components then retrieve the updated information. The smart contract acts as an updatable lookup point, not as the attack's entire infrastructure. Documented EtherHiding cases: DeadLock, Aeternum and ClickFix Documented cases show that this mechanism can serve different purposes within a campaign: DeadLock uses Polygon contracts to distribute and rotate the addresses of proxy servers that provide access to its victim communication infrastructure. The botnet Aeternum stores plaintext or encrypted instructions in Polygon contracts, which infected devices retrieve, decrypt where necessary and execute. In some ClickFix campaigns, a Polygon contract returns the domain from which the next stage is downloaded after the user executes the malicious command. Why EtherHiding makes C2 infrastructure harder to block The three cases above show a common advantage for their operators: the contract allows them to modify the information retrieved by different components of the campaign without replacing code that has already been deployed. When that information is a reference to a server, the operator can change it if the infrastructure becomes unavailable. This mechanism reduces reliance on fixed indicators and makes it harder for a single blocking measure to disrupt the campaign. Even so, other intervention points remain: the destination infrastructure remains outside the blockchain, many implementations rely on third-party RPC providers, and queries may be visible in network telemetry or in logs from the service being used. What changes for detection and response Blocking a domain or IP address remains useful for containing a specific infrastructure component. However, the effect may be short-lived if the attacker quickly updates the reference stored in the contract. In addition, queries to public RPC providers may blend in with legitimate traffic and make malicious activity harder to identify. For this reason, it is important to correlate infrastructure indicators with behavioural signals: anomalous processes and commands, connections to RPC providers, queries to contracts associated with known campaigns, and subsequent communications with the destinations retrieved. No single signal confirms malicious activity on its own. Combining them helps prioritise investigations and enables teams to respond with more context. Blocking the C2 is not enough: defenders also need to understand how the malware locates it and what activity it triggers. A context-aware response In these campaigns, smart contracts make it possible to update the C2 reference quickly and increase the resilience of this coordination mechanism. They do not hide the rest of the operation or eliminate other points at which defenders can intervene. For businesses, the lesson is clear: identifying the C2 is not enough. It is also important to understand how the malware locates it and what activity it subsequently triggers on the compromised device. Combining the blocking of known domains, IP addresses and servers with analysis of these signals provides greater context for investigating infrastructure that may change rapidly, without assuming that blockchain provides a level of invisibility it does not actually offer. ______ Cybersecurity AI & Data Hiding malware in Blockchain: Free hosting and takedown testing November 1, 2023