EtherHiding shows how blockchain can support persistent malware

At a glance

What this is: EtherHiding uses blockchain smart contracts to store and retrieve malicious payloads, creating a durable malware delivery path that is hard to remove once published.

Why it matters: IAM and security teams should care because the technique moves payload retrieval outside normal control points, reducing the value of perimeter filtering and pushing visibility into client-side and RPC activity.

Context

EtherHiding is a malware delivery pattern that abuses the permanence and decentralisation of blockchain smart contracts. The security gap is not the blockchain itself, but the way attackers can use it as a retrieval layer that sits outside conventional inspection and takedown workflows.

For defenders, that creates an identity and governance angle wherever systems, endpoints, or automation retrieve code or configuration from Web3 sources. If your monitoring assumes malware lives on attacker-owned infrastructure, this technique breaks that assumption and shifts the control problem to retrieval visibility, allow-listing, and response at the client edge.

Key questions

Q: What breaks when malware payloads are stored on a blockchain?

A: Traditional takedown and blocking assumptions fail because the payload is no longer hosted on a single controllable server. The retrieval source is distributed, durable, and difficult to remove, so defenders need to focus on client-side execution controls, blockchain-aware monitoring, and policy decisions about which RPC or Web3 sources are allowed.

Q: Why does blockchain-based payload retrieval increase persistence risk?

A: Because the malicious content can remain available even after the campaign is discovered. Immutability and consensus make deletion difficult, so the attacker can keep a retrieval path alive while defenders lose the ability to cleanly remove the source. That shifts the control problem from server takedown to retrieval governance.

Q: How can security teams detect Web3 malware delivery in practice?

A: They should correlate blockchain RPC activity, endpoint execution events, and threat intelligence on contract addresses or wallet-linked infrastructure. The key is to detect the handoff from retrieval to execution, because the blockchain interaction itself may look like normal Web3 usage until the payload is run.

Q: What should organisations do when endpoint protection misses blockchain-delivered malware?

A: They should move controls earlier in the chain by restricting approved RPC endpoints, validating retrieved content, and logging Web3 interactions in the SIEM. Endpoint tools still matter, but they are not enough when the payload source sits in decentralised infrastructure that traditional takedown cannot reach.

Technical breakdown

How smart contracts become a malware host

A smart contract is code stored at a blockchain address that can be queried by anyone. In EtherHiding, the attacker places payload data or a pointer to payload data into that contract, then uses chain reads such as eth_call to retrieve it without creating a transaction. Because the data is distributed across consensus-backed nodes, there is no single server to seize or delete. The blockchain is not executing the malware, but it is acting as a durable, decentralised storage and retrieval layer that survives normal infrastructure takedown models.

Practical implication: defenders need to treat blockchain reads as a potential delivery path, not just a harmless lookup.

Why blockchain retrieval bypasses traditional detections

Traditional network controls look for known hosts, domains, or download paths, while AV and EDR often focus on the payload once it reaches the endpoint. EtherHiding weakens both assumptions by separating retrieval from ordinary infrastructure and by staging payloads through smart contract reads that may appear innocuous. The article also notes that the retrieved content can vary by operating system, which makes the final execution path more selective and harder to pattern-match. This is a control-evasion problem as much as a malware problem.

Practical implication: inspection must extend to RPC activity, script behaviour, and endpoint execution context, not only to network destinations.

How decentralised persistence changes the defender's playbook

In a normal compromise, removing the host or blocking the domain can disrupt delivery. With EtherHiding, the attacker can keep the malicious payload accessible even after detection because the blockchain entry is distributed and immutable in practice. That changes containment from infrastructure removal to source-of-retrieval control. It also means threat intel has to track blockchain indicators, wallet-linked infrastructure, and smart-contract addresses as part of the kill chain. The operational issue is not whether blockchain is malicious by design, but whether defenders can distinguish benign Web3 interaction from payload retrieval.

Practical implication: build detection and containment around blockchain indicators, RPC whitelists, and endpoint-side validation of retrieved content.

Threat narrative

Attacker objective: The attacker wants a durable malware delivery and execution channel that survives takedown and supports covert command-and-control.

1. Entry occurs when the victim system or user initiates a Web3-related retrieval that reaches a malicious smart contract on a public blockchain.
2. Credential_harvested is not the primary stage here, because the technique instead abuses decentralised retrieval to pull concealed payloads from the chain.
3. Escalation happens when the retrieved content is executed on the endpoint, sometimes with OS-specific logic that helps the payload adapt to the victim environment.
4. Impact is persistent malware delivery, covert command-and-control, and execution paths that are difficult to take down or block with standard perimeter controls.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

EtherHiding is a persistence problem disguised as a delivery technique. The important shift is not just that malware can be fetched from a blockchain, but that the retrieval source is durable, decentralised, and hard to suppress once published. That makes the control gap one of source-of-retrieval governance rather than classic host removal. Practitioners should reframe Web3 lookups as a potential malware path when the retrieved object is executable or scriptable.

Web3 visibility becomes a mainstream control requirement when retrieval paths move off conventional infrastructure. The article shows that network filtering and AV alone are poorly aligned to blockchain-backed staging, because the malicious content may arrive through RPC reads and then execute on the client. This is exactly where endpoint telemetry, DNS and RPC monitoring, and allow-listing of blockchain interactions become relevant. Practitioners should treat blockchain-aware monitoring as a detection gap, not a niche telemetry project.

Client-side execution remains the decisive trust boundary for blockchain-delivered malware. EtherHiding does not need to make the blockchain itself compromised, only trusted enough to supply a payload that the endpoint will run. That means the security decision point moves to content validation before execution and to the governance of what environments may query public chains. Practitioners should assume that immutability of the storage layer can amplify, not reduce, the risk of malicious content persistence.

Persistent decentralised payloads create a named governance gap we can call blockchain retrieval opacity. This is the condition where defenders can see that a system reached a blockchain, but not easily determine whether the retrieved object is benign data or executable malware. The gap spans threat intel, endpoint policy, and SOC workflow. Practitioners should close it by correlating on-chain indicators with endpoint execution evidence and defined Web3 access policy.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — Key Challenges and Risks

What this signals

Blockchain retrieval opacity: defenders need a specific label for the gap between seeing a chain lookup and knowing whether the retrieved object is safe. That gap matters because the execution decision often happens at the endpoint, after the source has already bypassed traditional infrastructure controls. Security programmes should therefore join chain telemetry to endpoint telemetry rather than treating them as separate domains.

When Web3 is used as a payload host, the control question changes from "Can we block the server?" to "Can we govern retrieval and execution?" That is a material shift for SOC design because detection, policy, and response now need visibility into RPC usage, contract addresses, and the code path that consumes the retrieved object. Programs that cannot do that will keep finding the compromise after the payload has already run.

For practitioners

• Monitor blockchain and RPC retrieval activity Log and alert on client-side requests to public chains, especially eth_call and other read paths that return executable or scriptable content.
• Whitelabel allowed RPC endpoints Restrict blockchain access to approved RPC gateways and block unapproved public endpoints that can be used to pull concealed payloads.
• Correlate on-chain indicators with endpoint execution Feed smart-contract addresses, wallet-linked infrastructure, and blockchain retrieval patterns into SIEM detections tied to execution telemetry.
• Validate retrieved content before execution Require script and binary validation checks on content fetched from decentralised sources, especially when the payload selects code by operating system.
• Update threat intelligence for Web3 abuse Add blockchain indicators, contract addresses, and retrieval patterns to threat-intel workflows so SOC teams can recognise persistence via decentralised storage.

Key takeaways

• EtherHiding turns a blockchain into a durable retrieval layer for malware, which weakens the value of conventional takedown and perimeter filtering.
• The article’s key risk is persistence through decentralised storage, not blockchain compromise in the classic sense.
• Defenders need blockchain-aware monitoring, RPC whitelisting, and endpoint validation of retrieved content to contain this technique.

Key terms

• EtherHiding: EtherHiding is a malware delivery technique that stores malicious payloads or payload references in a blockchain smart contract. The attacker uses the chain as a durable retrieval source, which makes takedown difficult and allows payload access without maintaining a traditional server.
• Blockchain Retrieval: Blockchain retrieval is the act of reading data from a smart contract or chain-based storage location through RPC calls or similar queries. In a defensive context, it matters because the lookup path can deliver executable content without a conventional download host.
• Smart Contract: A smart contract is code stored at a blockchain address that executes according to predefined logic. For defenders, the important point is that contracts can also be used as durable data stores, including for malicious content that attackers want to keep reachable.
• Command-and-control: Command-and-control is the communication channel an attacker uses to issue instructions to malware and receive results back from a compromised host. For XWorm, the channel is encrypted and used for session management, payload delivery, surveillance, and modular expansion of capabilities after compromise.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security teams connect identity controls to broader threat patterns that involve retrieval, privilege, and execution.