Executive Summary

A browser reaching several blockchain RPC endpoints within seconds can give defenders a useful starting point for an EtherHiding hunt. Across available endpoint telemetry reviewed from March through September 2026, SRA observed recurring activity consistent with ClearFake and related loaders: browser connections to public blockchain infrastructure, sometimes accompanied by infrastructure associated with fake verification pages and ClickFix delivery. SRA also observed browser RPC activity followed by malicious PowerShell execution and retrieval of an attacker-hosted script. Correlating network and process telemetry distinguished browser exposure from confirmed local execution. Defenders who stop at the network signal will overcount compromise, so pairing RPC activity with process telemetry shows which hosts need incident response.

The strongest leads came from browser connections to BNB Smart Chain testnet and Ethereum Sepolia endpoints. In environments without an established business use for blockchain development, these destinations warrant investigation. Short bursts involving multiple RPC providers helped prioritize the hunt, but single-provider connections also mattered: a loader may retrieve what it needs from one endpoint. By examining browser activity around those connections, SRA identified recurring infrastructure, changing loader hostnames, and potential source websites. The resulting workflow moves from RPC activity to browser context and then to process telemetry, helping defenders identify exposure and determine whether suspicious execution followed.

Why Blockchain Traffic Becomes a Hunting Opportunity

EtherHiding uses public blockchain infrastructure to store malicious code or the information needed to retrieve it. A compromised website runs injected JavaScript that requests data from a smart contract through a public JSON-RPC service. The response can supply a browser stage or a pointer to another location. An attacker can update the content stored by the contract without editing every compromised site individually.

Public reporting describes several implementations. The following sequence explains how the technique can lead from an ordinary website visit to local execution, while identifying where defenders may find evidence.

• A compromised website. The attacker injects a JavaScript loader into a website. In the ClearFake samples analyzed by Expel, the initial JavaScript was embedded directly in the page using Base64 encoding, removing the need for a separate hostname to serve that initial loader. In one SRA incident response engagement, a malicious WordPress must-use plugin suppressed its injected output for logged-in administrators, concealing the content from an owner inspecting the site while authenticated.
• A contract read over public RPC. The loader requests data from a smart contract through public JSON-RPC providers. Expel documented a contract with a public get() function that returned content stored through an owner-controlled set() function. Loaders may contact several providers sequentially or concurrently to improve retrieval reliability. These browser-initiated connections can appear in DeviceNetworkEvents, giving defenders a hunting lead even when the initial script is embedded in the page. The network event alone does not reveal the contract address, RPC method, or returned content.
• A browser stage. The retrieved content may contain encoded JavaScript that the loader decodes and executes, or information used to retrieve externally hosted content. Public analyses describe checks for automated analysis environments, browser identification, and on-chain tracking used to decide whether to display a lure. Randy McEoin’s analysis documents requests to Avast’s geolocation service as part of browser-identification logic. Those requests provide supporting context, but do not independently establish that a verification prompt appeared.
• A ClickFix lure and local execution. The browser presents a fake verification task designed to persuade the visitor to run a command locally. In the Windows flow documented by Expel, the page places a command on the clipboard and instructs the user to open Run, paste, and execute it. This behavior aligns with User Execution: Malicious Copy and Paste (T1204.004). Delivery methods have varied, including PowerShell, mshta, and abuse of SyncAppvPublishingServer.vbs to execute PowerShell indirectly. The transition to endpoint execution requires a separate review of process activity and subsequent downloads.

What SRA Observed

SRA’s review covered available endpoint telemetry between March and September 2026. Relevant browser RPC activity appeared across industries. Potential source websites included small businesses, restaurants, medical practices, university and NGO sites, and personal-interest blogs. This distribution was consistent with opportunistic exposure during ordinary browsing. Identifying a website in the surrounding network activity provided a lead for investigation, rather than proof that it delivered the injection.

Weekly activity remained comparatively low through July, then increased in August and remained elevated over the subsequent review period. This describes the telemetry available to SRA; it is not an estimate of global campaign volume or the number of infected endpoints.

Two patterns appeared in the surrounding browser activity. In one, RPC requests were followed by an Avast geolocation lookup without a recognizable external loader or lure hostname in the review window. That pattern was consistent with publicly documented loaders retrieving browser content from on-chain storage. In the other, RPC activity coincided with traffic-distribution and external loader hosts.

Both patterns appeared on BSC testnet; the external-infrastructure pattern also appeared on Polygon and Base. The blockchain destination alone did not distinguish the delivery variant.

SRA observed delivr lookalikes and mytds infrastructure around BSC testnet activity. Restricting those infrastructure pivots to Polygon or Base would therefore miss relevant leads. Temporal proximity establishes an investigative relationship; captured scripts or request content are needed to establish the precise dependency between requests.

Some windows included requests to ip-info.ff.avast[.]com. McEoin’s September 2026 analysis documents this endpoint in ClearFake’s browser-identification logic. In the context of suspicious RPC activity, the lookup supports comparison with that analyzed behavior. The service is legitimate, and the request alone does not establish that a verification overlay appeared.

From Browser Activity to Confirmed Execution

SRA observed suspicious browser RPC activity followed by explorer.exe launching powershell.exe with a hidden-window option and an execution-policy bypass. The command used an iex(iwr …) expression to retrieve an attacker-hosted PowerShell script.

The linked network and process evidence established malicious PowerShell execution, consistent with a ClickFix hand-off. It did not independently capture the user’s keystrokes or establish every action performed by the downloaded script. Once execution was confirmed, the investigation needed to scope subsequent activity and assess containment.

This finding demonstrates why the hunt continues beyond the browser timeline. The RPC activity supplied the initial lead; the process evidence established the need for incident response.

The Hunt Hypothesis

We began with a narrow question: which endpoints showed browser connections to multiple public RPC providers within a short interval?

A loader can contact several providers sequentially or concurrently to improve retrieval reliability. McEoin’s analyzed ClearFake code issued concurrent RPC requests and used the first valid result. A burst therefore does not, by itself, establish that an earlier provider failed. The useful hunting signal is the cluster of browser-initiated RPC connections, particularly when testnet destinations are involved. However, legitimate Web3 applications can also implement fallback. Viem, for example, provides a transport that attempts another configured endpoint when a request fails. Multiple-provider traffic is therefore a prioritization signal, not a malware verdict.

The next step was to include single-provider testnet connections. Restricting the hunt to bursts would miss single-provider retrievals and cases where telemetry captured only one connection. In practice, the two approaches complement one another: multi-provider activity narrows the initial review, while single-provider testnet activity broadens coverage.

For mainnet services, the business context matters even more. Browser extensions, embedded Web3 components, and approved applications may generate legitimate requests. Record those uses and investigate the remaining activity with the page context intact.

Pivoting into the browser timeline

For each lead, SRA reviewed browser connections from two minutes before the RPC activity to one minute after it. This window was a starting point for reconstructing the visit, not a guarantee that it contained the entire chain.

The first question was which page may have initiated the activity. A nearby website request can identify a candidate, particularly when the same sequence recurs on separate endpoints. It does not prove that the site served the loader. Browser tabs, background requests, advertisements, and extensions can all contribute events to the same timeline. Page source, proxy records, browser history, or a captured script can strengthen the association.

The second question was whether the window contained recurring infrastructure beyond the public RPC providers. SRA observed domains resembling analytics services and CDN hostnames, including webanalytics-cdn[.]sbs and several delivr lookalikes. Other recurring names were associated with traffic distribution or fake verification pages. Their recurrence across unrelated environments made them useful pivots for investigating additional exposure.

The observed infrastructure changed over time. An analytics-themed hostname appeared from March into August, while several CDN lookalikes appeared in August and September. Traffic-distribution domains also changed. The practical consequence is that an IOC list should support the hunt, while the underlying RPC and browser behavior remains part of the detection strategy.

What the evidence can establish

Network and process events should be interpreted together. A connection to an RPC hostname establishes that the endpoint attempted or made that connection, according to the event’s action type. It does not reveal the RPC method, contract address, returned content, or successful execution of a browser stage unless additional telemetry supplies those details.

The same distinction applies to lure-related infrastructure. A request to a known verification hostname can support likely exposure. A subsequent process launch with a suspicious command line can support local command execution. Confirming the payload’s behavior requires reviewing its execution, downloads, child processes, and other available evidence.

This distinction prevents two errors: treating every RPC connection as a compromise, and dismissing a genuine execution event because the initial interaction looked like routine browsing.

Detection and Hunting Opportunities

1. Browser to testnet RPC

This query identifies browser connections to known RPC services whose hostnames contain testnet-related terms. Prioritize unexpected activity in environments without an approved business use. Review ActionType before assessing whether a connection succeeded.

2. Multi-provider RPC burst

This query groups matching RPC connections by device, account, and one-minute time bin, then returns groups containing at least two distinct RPC hostnames. It is a burst-hunting heuristic: it does not establish process-instance continuity, distinct provider ownership, or sequential failure. Legitimate Web3 activity may match, and a burst spanning a minute boundary may be split. Interpret the High and Medium labels as initial triage categories requiring contextual validation.

3. Burst window pivot

This query retrieves browser activity from two minutes before to one minute after the selected burst. It marks configured RPC providers, infrastructure patterns, selected TLDs, and the Avast geolocation endpoint. Review the ordered events to identify candidate source pages and related infrastructure. A nearby hostname, TLD match, or geolocation request supports investigation; none independently confirms a loader stage or a displayed overlay.

4. ClickFix hand-off

This query searches flagged devices for selected interpreters and utilities with suspicious command-line content and specified parents. Investigate matches using the complete process tree, account context, and subsequent activity. The included patterns cover public reporting on SyncAppvPublishingServer.vbs proxy execution and WebDAV/rundll32 delivery. A match is a triage lead; the query is not exhaustive and a negative result does not rule out execution.

5. Full Chain

This query combines testnet hits and RPC bursts with surrounding browser events and later process matches. It uses a six-hour process-correlation window and joins the stages by device. Review account and process context to distinguish related activity from unrelated events in that interval. A device with overlapping anchors may produce repeated evidence rows. Confidence labels and stage labels organize triage; they do not independently establish maliciousness or successful completion of the chain.

Recommendations

• Alert on unexpected browser connections to testnet RPC endpoints. In environments without an approved use for blockchain development, these connections warrant investigation. Include single-provider activity as well as bursts, baseline legitimate use, and scope exceptions narrowly.
• Block infrastructure confirmed to be malicious. Apply proxy and DNS controls to validated loader, traffic-distribution, lure, and payload domains. Use the burst-window pivot to identify emerging domains as infrastructure changes.
• Investigate mainnet RPC bursts in context. Polygon, Base, and BSC activity may originate from legitimate Web3 applications or browser components. Review surrounding connections and approved uses before escalation. A burst accompanied by known malicious infrastructure or suspicious execution warrants higher priority.
• Restrict unnecessary execution paths where business requirements allow. Review application-control coverage for mshta, PowerShell, and the proxy-execution utilities seen in documented ClickFix delivery. Restrictions on Run or a particular utility can interrupt specific paths, but should be part of a broader control strategy. User guidance should address websites that ask visitors to paste commands into Run or a terminal to complete verification.
• Respond according to the evidence. A network hit alone does not establish endpoint compromise or rule out subsequent execution. Review process activity, downloads, and other available telemetry before determining the response. Confirmed malicious execution warrants containment and incident response, including assessment of credential or session theft where supported by the observed behavior.

For website owners

• Patch WordPress core, plugins, and themes, and remove unused components. Where compromise is suspected, investigate how the attacker gained access; patching alone does not remove an existing injection or restore trustworthy application files.
• Audit wp-content/mu-plugins/ alongside ordinary plugins and themes. Must-use plugins load automatically and appear in a separate Must-Use section rather than the default plugin list. In one SRA engagement, a malicious plugin suppressed its injected output for administrators, making an authenticated site check insufficient.
• Review the page delivered to a logged-out visitor, including unexpected scripts added through wp_head or other injection points. Differences between authenticated and unauthenticated output can be legitimate. The relevant finding is unexpected malicious content or logic that conceals it from administrators.
• Inspect unfamiliar REST routes and their authorization checks. The malicious plugin SRA investigated exposed update, status, and removal functionality protected only by a hardcoded key, allowing the attacker to maintain the injection remotely.
• For a confirmed compromise, remove the attacker’s access, restore trustworthy application files, review affected credentials, and validate the public-facing site. Where the integrity of the installation cannot be established, rebuild from a clean installation and a verified backup.

IOCs

Recurring infrastructure

Single-Use Stage Domains

Potential Source Websites

The following websites appeared in browser network activity immediately before RPC bursts observed by SRA. They are potential source-site leads, not confirmed attacker infrastructure. SRA has not retrieved their page source to verify an injection, and network proximity alone does not establish which page was active or whether a site delivered the loader. Sites are grouped by the strength of the observed association, including repeated appearances and accompanying attacker infrastructure.

RPC endpoints observed

These are legitimate public services abused by the loader.

• BSC testnet: bsc-testnet-rpc.publicnode[.]com, bsc-testnet.bnbchain[.]org, bsc-testnet.drpc[.]org, bsc-testnet-dataseed.bnbchain[.]org, data-seed-prebsc-1-s1.bnbchain[.]org, data-seed-prebsc-2-s1.bnbchain[.]org, bsc-prebsc-dataseed.bnbchain[.]org, data-seed-prebsc-1-s1.binance[.]org, data-seed-prebsc-2-s1.binance[.]org, bsc-testnet.public.blastapi[.]io, bsc-testnet.blockpi[.]network, bsc-testnet.4everland[.]org, bnb-testnet.api.onfinality[.]io
• Sepolia: ethereum-sepolia-rpc.publicnode[.]com, sepolia.drpc[.]org
• Polygon: polygon.drpc[.]org, polygon-bor-rpc.publicnode[.]com, polygon-public.nodies[.]app, polygon.gateway.tenderly[.]co, polygon-mainnet.public.blastapi[.]io, polygon.lava[.]build, rpc-mainnet.matic.quiknode[.]pro, polygon.rpc.subquery[.]network, api.zan[.]top, polygon-rpc[.]com, polygon-mainnet.gateway.tatum[.]io
• Base: base.drpc[.]org, base.publicnode[.]com, base-rpc.publicnode[.]com, base.gateway.tenderly[.]co, base-mainnet.public.blastapi[.]io, mainnet.base[.]org
• Multi-chain gateways: rpc.ankr[.]com, 1rpc[.]io, endpoints.omniatech[.]io

Supporting Indicator

• ip-info.ff.avast[.]com: Legitimate Avast geolocation API documented in ClearFake’s browser-identification logic. A request within a suspicious testnet RPC burst window provides supporting context consistent with that behavior; it does not establish that a verification overlay appeared or that malicious execution followed.