SOCLIFE
SOCLIFE

Evidence-led security analysis

Published knowledge

Search SOC//LIFE

ThreatsTHREAT-004

Threat report

EtherHiding in 2026: Smart Contracts as Dead-Drop C2

2026 investigations show EtherHiding moving C2 pointers, executable browser stages, and campaign state into public smart contracts so operators can rotate infrastructure without replacing the initial loader.

Public research

Reported facts and defensive takeaways are labeled separately.

Reviewed

Public reporting

What happened

EtherHiding matured from a niche blockchain-abuse technique into a repeatable infrastructure pattern in 2026. Separate investigations documented compromised websites and malware loaders querying public blockchain RPC services, reading attacker-controlled smart contracts, and using the returned value as a next-stage domain, C2 pointer, or executable browser payload. The public RPC provider is legitimate, while the contract state gives the attacker a durable place to rotate or host the malicious value.

Why SOC teams should care

Traditional blocklists focus on domains, IPs, and hosting providers that can be suspended or replaced. EtherHiding separates the stable resolver from the rotating destination: a public RPC provider can look benign, the contract can persist, and the attacker can update the returned next stage without changing the first loader. Defenders therefore need visibility into who is using blockchain RPC infrastructure, from which process or browser, and what destination or execution follows.

Public reporting

How the attack worked

  1. Initial Access01

    A compromised site or loader reaches the victim

    Current reporting includes compromised WordPress pages and malware loaders as different entry points into EtherHiding-enabled chains.

    Useful logs: Network, Endpoint, Process

  2. Execution02

    Browser or runtime contacts a public blockchain RPC service

    Injected JavaScript, Python loaders, and other execution contexts query legitimate Web3 node infrastructure instead of directly hardcoding the final next-stage destination.

    Useful logs: Network, Process, Dns

  6. Credential Access06

    Delivered malware pursues the campaign objective

    The cited 2026 chains ended in different stealers or payloads, including ACR Stealer, Vidar, and Amatera. EtherHiding is the infrastructure mechanism, not the payload family.

    Useful logs: Process, File, Endpoint, Network

Defensive takeaways

Behavior to watch

Logs that help

Network

Endpoint network and proxy telemetry expose RPC provider access, same-process follow-on destinations, and the handoff from legitimate Web3 infrastructure to attacker-controlled infrastructure.

  • First-seen RPC provider access on ordinary endpoints.
  • Same-process transition from RPC service to a separate destination.
  • HTTP request-body evidence of contract-read JSON-RPC calls where available.

Process

Process lineage distinguishes expected Web3 tooling from malware loaders or suspicious runtimes using blockchain services.

  • Python, Node, PowerShell, script hosts, or native runtimes contacting RPC infrastructure.
  • Contract addresses, selectors, or resolver logic exposed in command lines or scripts.

Dns

DNS provides broad coverage for RPC providers and resolved next-stage domains, including devices with limited endpoint telemetry.

  • Unexpected queries to RPC-provider domains from non-Web3 populations.
  • New destination domains immediately after RPC resolution activity.

Endpoint

Endpoint context connects browser/runtime RPC use with service-worker persistence, payload execution, credential theft, or other post-compromise behavior.

  • Unexpected Service Worker or browser persistence on affected web properties.
  • Stealer, loader, persistence, or credential-access behavior following the resolver sequence.

Threat Intelligence

On-chain analysis can track contract state, wallet relationships, selector reuse, and historical domain rotation after an endpoint candidate is discovered.

  • Known contract/wallet/selector reuse.
  • Contract updates that rotate the returned domain or payload.

Defensive takeaways

How to detect this behavior

Rare runtime RPC access followed by new external communication

Alert when a scripting/runtime process on a device without established RPC history contacts a public RPC provider and the same stable process reaches a separate external destination in a short window.

Logs needed

  • Endpoint network events with stable initiating-process identity.
  • Device-level historical RPC baseline.
  • Environment-maintained public RPC provider category.

Direct contract-read detection where HTTP body is retained

Inspect proxy or packet telemetry for JSON-RPC contract-read methods, contract addresses, and immediate handoff to a separate destination.

Logs needed

  • HTTP request-body or decrypted proxy visibility.
  • URL/FQDN, process/user/device attribution where available.
  • Optional threat-intelligence context for contract addresses.
View detection

Defensive takeaways

How to hunt this behavior

Baseline public RPC usage before hunting malware

Identify approved developer, wallet, analytics, and monitoring populations first, then focus on first-seen RPC use on ordinary endpoints.

What would weaken it

  • RPC activity is confined to approved Web3 systems and expected processes.
  • The device, owner, project, provider set, and follow-on destinations match documented business use.

Correlate RPC access with the next destination

A same-process RPC request followed by a different external destination is a durable way to approximate resolver behavior even when the returned value rotates.

What would weaken it

  • The follow-on service is an approved dependency of the Web3 application.
  • The same sequence is a long-standing baseline for the process and device population.

Use source contracts only as a second-stage pivot

Search source-reported contracts, selectors, and second-stage domains after behavior candidates are identified, then expand to rotated contracts and outputs.

What would weaken it

  • No source artifacts appear and the observed RPC use is fully explained by approved tooling.
  • On-chain values are historical and no longer overlap the candidate timeframe.
View threat hunt

Public reporting

Indicators reported by the source

Values are defanged and are not live links.
Polygon smart contract reported by Cribl in the August 2026 EtherHiding investigation.1 values
  • Other0x0C7Cb01C83203aC0a50Abc3a9AFF3c9Ca727eF55
Creator wallet reported by Cribl for the Polygon contract used in the investigated resolver chain.1 values
  • Other0x2f9091ab4ec91c0daa67a7660c81a922328a8096
Method selector embedded in the malicious script documented by Cribl and used in the source-reported contract call.1 values
  • Otherb68d1809
Malicious second-stage domain decoded from the Polygon contract response in Cribl's investigation.1 values
  • Domainthu-ipad-03[.]cfd
Legitimate Polygon RPC endpoint referenced as a fallback by the malicious script in Cribl's investigation; the service itself is not asserted malicious.1 values
  • Domainpolygon-public[.]nodies[.]app
Legitimate Polygon RPC endpoint used by the malicious script in Cribl's investigation; the service itself is not asserted malicious.1 values
  • Domainpolygon[.]gateway[.]tenderly[.]co
Legitimate Polygon RPC endpoint listed in the malicious script analyzed by Cribl; presence alone is not malicious.3 values
  • Urlhttps[:]//1rpc[.]io/matic
  • Domainpolygon[.]drpc[.]org
  • Domainpolygon-bor-rpc[.]publicnode[.]com
Malicious Service Worker filename reported by the Israel National Digital Agency for the Base-hosted EtherHiding variant.1 values
  • Filenamenochain-sw.js
Dynamic traffic-distribution pointer reported by the Israel National Digital Agency for the Polygon resolver variant.1 values
  • Domainveralok[.]click

Review record

Sources and limitations

Reviewed
Reported window
April 2026 – August 2026

Observation basis

Microsoft observed ACR Stealer activity from late April through mid-June with a blockchain dead-drop variant, while Cribl, the Israel National Digital Agency, and Netskope published additional first-party EtherHiding findings in August 2026. The window represents the cited reporting, not one continuous campaign.

Confidence in this conclusion

Multiple independent first-party 2026 investigations document the same defensive behavior across different delivery chains and EVM networks: legitimate public RPC access, attacker-controlled smart-contract state, and dynamic resolution or hosting of the next stage. The reports do not support attribution to one actor or one universal contract/provider set.

Limitations

  • EtherHiding is a technique used by different activity sets and is not attributed here to one actor.
  • Public RPC providers listed in source reporting are legitimate services and should not be labeled malicious solely because attackers used them.
  • The Polygon, Base, BNB, browser, and Python-loader examples are distinct implementations and are not combined into one fictional universal chain.
  • INDA's near-10,000-site figure is a technique footprint across public scanning and likely spans multiple clusters; it is not a count for one operator.
  • A contract address, method selector, wallet, or returned domain can rotate, so source indicators are retrospective pivots rather than durable detection logic.
  • The SOC//LIFE Detection and Hunt are publication-safe defensive patterns and are not evidence that these events were observed in a customer environment.

What changed in 2026

Microsoft documented ACR Stealer intrusions in which a Python loader used public blockchain RPC and Web3 infrastructure as a dead-drop resolver for follow-on payload or C2 information.

Cribl later traced a live Polygon-based chain from a compromised WordPress site to multiple public RPC endpoints, a specific smart contract, an encoded contract response, and a malicious second-stage domain. The same report documented repeated domain rotation through contract updates.

The Israel National Digital Agency described a broader 2026 ecosystem: one Polygon implementation used the chain only as a pointer, while a Base implementation stored the second-stage browser logic on-chain and paired it with malicious Service Worker persistence. Their public-scanning hunt surfaced close to 10,000 compromised sites exhibiting the broader EtherHiding/ClickFix pattern and a ClearFake tracking contract with more than 64,000 logged infections.

Netskope independently reported a Base-based WordPress chain using a rogue plugin, Service Worker persistence, smart-contract payload delivery, ClickFix, and Amatera.

Defensive lesson

Do not turn the list of public RPC providers into a malicious-domain blocklist. The durable question is whether an endpoint that normally has no Web3 role suddenly uses an RPC provider from an unexpected process or browser and then transitions into attacker-controlled execution or infrastructure.

The smart contract is useful threat intelligence. The resolver behavior is the better detection surface.

  1. Malware-On-The-Blockchain: How Attackers Build Infrastructure That Can't Be Taken Down

    Israel National Digital Agency

  2. Cribl SecOps uncovers EtherHiding malware campaign on the blockchain

    Cribl

  3. ACR Stealer: Two observed intrusion chains amid increased threat activity

    Microsoft Security

  4. EtherHiding in the Browser: ClickFix Chain Ends in Amatera

    Netskope Threat Labs

  5. Web Service: Dead Drop Resolver

    MITRE ATT&CK

Supporting context

ATT&CK mappings

Behavior comes first. These mappings do not imply attribution or complete coverage.
Page navigation

Sections