Detecting Aeternum's Polygon RPC command channel

Contribution

This post adds an original Microsoft Defender XDR hunt for Aeternum's most durable local signal: a non-browser process reaching public Polygon RPC services. It also separates native-loader C2 from browser-based EtherHiding, a distinction that matters because the same blockchain infrastructure can carry very different attack paths.

The pattern

Aeternum is a Windows loader that reads commands from a Polygon smart contract rather than an attacker-controlled C2 server. The contract is public and replicated across the chain. Taking down a domain does not remove it, and the operator can update the stored command with an on-chain transaction.

The mechanics are unusually concrete. Ctrl-Alt-Intel's reverse engineering found a hard-coded contract address and a list of public Polygon RPC services in the loader. Every one to three minutes, with jitter, the sample sends an HTTPS POST containing a JSON-RPC eth_call. The call reads the contract's getDomain() function through selector 0xb68d1809. Its request shape is specific:

{"jsonrpc":"2.0","method":"eth_call","params":[{"to":"0x4d70C3393C5d9EC325Edf8b3f289cFA9777e64B0","data":"0xb68d1809"},"latest"],"id":1}

The returned value contains an encrypted instruction. The researchers found that the contract address supplies both password and salt for the PBKDF2-derived AES key. Anyone who knows the address can therefore decrypt the command history. Their examination recovered instructions to download PowerShell, DLL and executable payloads, sometimes for every infected host and sometimes for one host ID.

That public history is useful for incident reconstruction, but it is not the endpoint detection surface. A read-only eth_call is not a blockchain transaction. It leaves no record that identifies the victim making the request. Defenders see the retrieval in endpoint network telemetry, DNS logs, an egress proxy or an inspection sensor. The ledger shows what the operator wrote; the victim's network shows who read it.

Unit 42's later analysis ties the Polygon channel to three related malware cases. Its native loader copies itself beneath the user's AppData\Local directory, writes a shortcut into the Startup folder and contacts public RPC services for commands. Other samples add Telegram C2, XWorm, XMRig and data theft. Those cases show why the blockchain lookup cannot be treated as the whole incident. It is a durable control link inside a conventional malware chain that still creates processes, files, persistence and outbound transfers.

The distinction from browser-led EtherHiding is important. The Israel National Digital Agency's incident research describes compromised WordPress pages whose scripts query several public RPC providers before presenting ClickFix lures. Aeternum reaches similar infrastructure from a compiled Windows process. A detector that alerts on any Polygon RPC hostname will mix malware, compromised websites and legitimate Web3 software into one noisy queue. Process attribution turns the same network destination into a much sharper signal.

Why it matters to cloud defenders

Windows systems in cloud estates are not limited to servers. Build hosts, jump boxes, virtual desktops and developer workstations often carry cloud credentials or access paths to production. If Aeternum runs on one of them, the immediate event is endpoint execution, but the payoff can cross into the cloud through cached credentials, local configuration files or an authenticated browser session. The cited research does not claim a specific cloud-account theft sequence, so defenders should not conclude that one occurred from the Polygon traffic alone. The point is exposure: a compromised system with privileged access deserves faster triage than an isolated test device.

Public RPC services also frustrate destination-only policy. They are legitimate infrastructure, use HTTPS and may be needed by blockchain development teams. A static blocklist can age quickly because the loader carries several providers for redundancy. The stronger question is whether this device and this process should be making blockchain calls at all.

That leads to a practical segmentation model. Most corporate subnets have no business need for public blockchain RPC. Deny that traffic at egress there. Put approved Web3 workloads in named groups with explicit destinations and owners. On mixed developer networks, retain process-linked endpoint events so an analyst can tell a signed browser or approved client from an unfamiliar binary under AppData.

TLS creates a second boundary. Microsoft Defender for Endpoint records the remote URL or FQDN and the initiating process in DeviceNetworkEvents, but it does not expose the HTTPS request body. The precise eth_call, contract address and selector are available only where an authorised proxy or network sensor inspects payloads. Do not claim selector-level detection from flow logs, DNS logs or Defender URL fields. Those sources can identify the RPC service and process, not the encrypted request content.

Cloud network flow logs have the same limitation. AWS VPC Flow Logs, Azure virtual network flow logs and GCP VPC Flow Logs record connection metadata rather than decrypted application bodies. They can support a coarse hunt for repeated outbound connections to resolved RPC addresses, but shared hosting and changing provider addresses make that weaker than endpoint attribution. Use cloud flow data to widen scope after a confirmed endpoint signal, not as the sole proof of Aeternum.

ATT&CK mapping

Aeternum's Polygon retrieval is best mapped to T1071.001, Application Layer Protocol: Web Protocols. The loader sends JSON-RPC over HTTPS and disguises the request with a browser-like user agent. The web protocol is the observable transport; the fact that the destination serves blockchain data does not create a separate protocol.

MITRE's T1102.003, Web Service: One-Way Communication, adds useful context because the compromised host reads instructions from a legitimate external service without sending command output through the same channel. It stays in prose rather than frontmatter because the current a13e technique surface does not have a hand-authored answer box for that sub-technique.

After command retrieval, the chain branches by payload type. Ctrl-Alt-Intel observed reflective DLL loading, PowerShell and executable downloads, deletion of Mark-of-the-Web data and parent process ID spoofing to explorer.exe. A command can also request persistence. The native loader itself copies into AppData\Local and creates a Startup-folder shortcut, which maps to T1547.001, Registry Run Keys / Startup Folder. That persistence mapping also stays in prose to avoid pinning a thin technique page.

The initial delivery route for the native sample was not established in the cited research, so it would be wrong to invent phishing or exploitation as the entry technique. The downstream payoff varies too. Unit 42 saw XMRig, XWorm and exfiltration in related cases, while Ctrl-Alt-Intel recovered several payload URLs and targeted host commands. Treat command retrieval as the stable middle of the chain. Use the actual payload and host evidence to map execution, credential access or exfiltration during each investigation.

Detection guidance

Start with a process-attributed network hunt. The following KQL uses documented DeviceNetworkEvents fields in Microsoft Defender XDR. The RPC list is deliberately transparent and should be maintained from threat research and the organisation's own DNS or proxy records.

let PolygonRpcHosts = dynamic([
  "polygon-rpc.com",
  "polygon.drpc.org",
  "polygon-bor-rpc.publicnode.com",
  "polygon.lava.build",
  "polygon-public.nodies.app",
  "polygon-pokt.nodies.app",
  "polygon.gateway.tenderly.co",
  "gateway.tenderly.co",
  "rpc.ankr.com"
]);
DeviceNetworkEvents
| where Timestamp > ago(14d)
| where RemotePort == 443
| where RemoteUrl has_any (PolygonRpcHosts)
| extend Process = tolower(InitiatingProcessFileName)
| where Process !in~ ("chrome.exe", "msedge.exe", "firefox.exe", "brave.exe")
| summarize
    FirstSeen=min(Timestamp),
    LastSeen=max(Timestamp),
    RpcHosts=make_set(RemoteUrl, 20),
    ConnectionCount=count(),
    CommandLines=make_set(InitiatingProcessCommandLine, 10)
  by DeviceId, DeviceName, Process,
     InitiatingProcessSHA1, InitiatingProcessFolderPath,
     InitiatingProcessAccountName
| order by ConnectionCount desc

This is a hunt, not a verdict. A legitimate node client, wallet, indexer or development tool can match. The first tuning step is an allowlist tied to the process hash or signer, device group and owner, not a blanket exclusion for an RPC domain. A familiar provider contacted by an unfamiliar process is exactly the boundary under examination.

The browser exclusion separates the native Aeternum hypothesis from browser-driven EtherHiding, but it must not discard the browser events. Route them to a separate analytic. A browser contacting several Polygon or Base RPC providers within a short interval, followed by PowerShell, mshta.exe, rundll32.exe or another command interpreter, fits the ClickFix pattern described by the Israeli government research. A non-browser process beneath a user-writable directory, especially with one-to-three-minute repetition, fits the native-loader path more closely.

For deployments with TLS inspection, add a payload analytic for HTTPS POST bodies where method is eth_call and data is 0xb68d1809. Pair it with the contract address when hunting this known deployment. Keep the selector as the stronger behavioural element: operators can deploy a new contract address while reusing the same interface. Retain both values in case data because the address opens a second investigation plane on Polygon.

Once the network hunt returns a host, look for the local sequence rather than closing on the hostname alone:

1. Review the initiating process path, SHA-1, signer and creation time. A binary under AppData\Local with no approved software record merits containment.
2. Search the user's Startup folder for new .lnk files and resolve each target. Aeternum names vary, so path and creation time matter more than a single filename.
3. Hunt child processes and payload writes in random directories beneath %TEMP%. Check for PowerShell with execution-policy bypass, command files and executables whose apparent parent is explorer.exe despite surrounding evidence that suggests another origin.
4. Review network events after each RPC lookup for downloads from GitHub, file hosts or unfamiliar domains. Then look for Telegram API traffic or other outbound transfer channels identified in the later Unit 42 cases.
5. Scope the device's cloud access. Record interactive users, managed identities, local credential files and recent administrative sessions. Rotate credentials only where the evidence shows they were present or used; a Polygon lookup does not prove credential theft.

False positives concentrate in Web3 engineering, wallet software and security research. Build a baseline by device role. A production finance workstation and an approved blockchain build runner should not share the same threshold or response. Browser traffic may also reach RPC services because a legitimate decentralised application makes calls directly from JavaScript. That is why process identity, provider fan-out, cadence and follow-on execution need to be read together.

What to do now

Block public blockchain RPC at egress for device groups that do not need it. Where a business requirement exists, restrict access to approved software and providers, then log the initiating process. This reduces the problem from an internet-wide set of legitimate services to a small, owned exception list.

Run the Defender hunt across Windows servers, virtual desktops and developer endpoints. Investigate non-browser matches from user-writable directories first. Preserve endpoint network events, process creation, Startup-folder artefacts and DNS or proxy records before reimaging. The public contract history can help reconstruct commands later, but it cannot replace local evidence about which payload ran.

Add a second analytic for browser-origin RPC fan-out followed by command execution. Do not merge it with the native-loader rule. The destinations overlap; the process chain and response playbook do not.

Finally, treat recovered contract addresses and selectors as durable pivots. Search historical inspected traffic, query public chain history and monitor future contract updates. Blockchain-backed C2 is hard to take down, but it is not invisible. Its retrieval still crosses an endpoint, a process boundary and an egress control. Those are ordinary places to catch a supposedly extraordinary channel.