Skip to content

EtherHiding: Malware in Plain Sight

EtherHiding: Blockchain-Based “Bulletproof” Payload Delivery — and Where WCS Stops It

EtherHiding is a malware delivery technique where attackers store malicious code (or the next-stage “loader” instructions) inside public blockchain smart contracts (commonly Ethereum or BNB Smart Chain), then retrieve it at run time from a compromised website or injected web script. Because the payload can be pulled via read-only blockchain calls (e.g., JSON-RPC eth_call), the attacker can “host” malware without relying on a traditional web server that defenders can easily seize or block. (Google Cloud)

Payload Delivery Details

For payload delivery details see EtherHiding: Blockchain-Based “Bulletproof” Payload Delivery — and Where WCS Stops It

How EtherHiding Allows Hackers to Deploy Malicious Code

A typical EtherHiding chain looks like this:

  1. Compromise a legitimate site (often at scale—e.g., WordPress sites) or inject a malicious script into web content. (Google Cloud)
  2. The injected script contacts a blockchain node/provider and uses a read-only call to fetch a blob of encoded JavaScript or a configuration “pointer” from a smart contract. (Censys)

  3. The script decodes + executes that payload, which may:

    • present a “fake update / verification” lure to trick the user into running something locally, or
    • drop/launch additional tooling (infostealers, RATs, backdoors). (HHS)

Benefits to Hackers

EtherHiding is attractive because it gives adversaries “bulletproof-ish” hosting characteristics:

  • Resilience / anti-takedown: the data lives on a decentralized ledger—there’s no single origin server to seize. (Censys)
  • Easy payload rotation: they can update what victims fetch (new stage, new config, new obfuscation) without standing up new infra the normal way. (Google Cloud)
  • Abuse of trust in legitimate sites: compromised “normal” websites reduce suspicion and help initial delivery. (Google Cloud)
  • Lower signal for defenders: read-only calls can be harder to spot than classic “download EXE from bad domain” patterns. (Blackpoint)

Why Traditional AV and “NextGen AV” Often Miss It

EtherHiding shifts the problem from “detect a known bad file hosted on a known bad server” to “detect dynamic code assembled at runtime”:

  • No stable hosting IOC: there may be no malicious domain to reputation-block—payload retrieval happens through public blockchain infrastructure and standard APIs. (Censys)
  • Fileless / staged behavior: the initial component can be just web script that pulls the real content later. (Menlo Security)
  • High variability: attackers can change the encoded payload frequently, reducing signature usefulness. (Picus Security)
  • Read-only calls leave less “traditional” trail: retrieving payload via read-only blockchain calls doesn’t look like a normal malware download and may not produce the same artifacts defenders expect. (Blackpoint)

(This doesn’t mean endpoint detection is impossible—only that the technique is designed to reduce the reliability of classic “known-bad file/known-bad host” controls.)

Why Law Enforcement Can’t Easily “Take Down the Malware Deployment Infrastructure”

With classic malware hosting, LEOs can pursue domain seizures, hosting-provider takedowns, and server confiscation. EtherHiding breaks that playbook:

  • No single provider controls the data: smart-contract content is replicated across a network; there’s no central host to compel to remove it. (Google Cloud)
  • Infrastructure is “public utility”-like: blocking all blockchain access can be operationally unrealistic for many orgs (and attackers can switch providers). (Picus Security)
  • Takedown ≠ removal: even if a specific web injector is cleaned, the on-chain payload can still exist and be reused elsewhere. (Google Cloud)

How White Cloud Security Blocks the Malicious Payloads by Default

White Cloud Security’s default-deny model stops EtherHiding where it matters most: on the endpoint at execution time.

  • EtherHiding’s strength is delivery and resilience—but the delivered payloads are still “new, unapproved executables/scripts” on the endpoint.
  • WCS blocks them by default because they do not match an approved entry in the White Cloud Security 6-Factor Approved Handprint list (i.e., they’re never pre-approved).
  • This remains true even if the attacker’s “hosting” is untake-downable, because WCS enforcement does not depend on taking down attacker infrastructure—it depends on whether the exact payload is explicitly approved to run.

Bottom line: EtherHiding makes payload hosting harder to disrupt. WCS makes payload execution unnecessary to “disrupt” — because unknown payloads never get to run in the first place.