Netskope Explains Blockchain Dead Drop Resolvers for C2 Fetches

Blockchain-based dead drop resolvers fetch malware command-and-control (C2) endpoints at runtime from public ledgers, and the technique is shown across eight families on Ethereum Virtual Machine, Solana, and TON. The update matters because it changes how C2 infrastructure can be detected and disrupted for enterprise defenders.

Research overview

The post defines a dead drop resolver as a mechanism where malware retrieves a C2 address during execution from an external attacker-controlled location rather than embedding it in the binary. It frames the article as a practitioner primer with examples spanning multiple malware families and chains.

Across the walkthrough, the loader calls public blockchain services to obtain an encoded value, then decodes it into a C2 target such as an IP, URL, domain, JavaScript, or a bash stager. The article also describes a workflow for detection by reconstructing the decoded output.

Key findings

The post describes a pattern in which the blockchain provides a censorship-resistant source of truth for the C2 pointer while the loader and its decode logic retrieve that pointer at runtime. It highlights that the approach supports traffic blending by relying on high-reputation blockchain RPC providers.

It also states that the technique’s prevalence reduces defenders’ visibility, and it illustrates this through specific malware families that read either plaintext or obfuscated payloads from smart contracts or transaction fields. In addition, it provides an example tied to the August 2026 ChainDrop npm compromise, using an Ethereum contract read to obtain the C2 target.

Technical breakdown

For EVM networks, the post describes the most common variant as using a JSON-RPC eth_call against a public EVM node, which is read-only and creates no transaction. It explains that the ABI-decoded response holds the C2 pointer and that operators may encode the payload using formats such as UTF-8, Base64, Base64 plus XOR, or gzip plus Base64.

It provides example decoding behavior for specific families and shows how a live RPC call can reproduce a plaintext C2 URL. It also describes ChainDrop behavior as sending a 136-byte eth_call body to Ethereum mainnet RPC providers, reading the contract, then exfiltrating to the resolved domain, with resolution spanning eth.llamarpc.com, go.getblock.io, and eth-mainnet.nodereal.io.

EVM eth_call example

The post includes a one-liner that calls a Polygon publicnode endpoint using curl with an eth_call JSON payload, then runs a Python snippet to decode the returned hex into a URL. It reports an output that includes a defanged IP address.

It also notes that ChainDrop uses fallback RPC endpoints and that the contract’s stored value is cleared by operators after use, so a subsequent read may return 0x.

Solana memo dead drop approach

For Solana, the post says there is no eth_call equivalent, so the variant abuses the memo field attached to ordinary transactions. It describes a two-call sequence: getSignaturesForAddress to list recent transactions on a wallet, then getTransaction to fetch a payload such as a Base64-encoded C2 URL from the memo instruction.

The article includes a GlassWorm one-liner that first retrieves a signature and then extracts and Base64-decodes memo content when a programId includes “Memo.” It includes an example output containing a defanged HTTP URL path.

TON blockchain DNS query

For TON, the post describes a simpler mechanism where the loader issues a REST GET to tonapi.io or toncenter and calls get_domain on a TON smart contract. It states that the response returns a plain C2 domain value.

It identifies two families, SalatStealer and TONResolver, as using get_domain and provides a TONResolver example that currently returns a refreshed value consistent with a rotated dead-drop entry, along with the one-liner used to decode the returned JSON field.

Operational impact

The post explains that decoding separates malicious C2 targets from benign crypto traffic because the same blockchain RPC infrastructure is used by wallets and decentralized applications. It frames detection as focusing on alerts that include the RPC call details and the calling process context.

It proposes pulling four artifacts from an alert: the RPC URL, the contract address (the to field), the function selector (first four bytes of data), and the decoded result derived from decoding the hex response into a C2 string. It also states that non-browser processes such as node, bun, or curl indicate likely malicious activity, while browser or wallet activity is considered benign in this framing.

Leadership perspective

The article concludes that blockchain dead drop resolvers allow attacker-controlled C2 endpoints to be updated via on-chain values while loaders reconstruct the endpoint at runtime. It connects this to the August 2026 ChainDrop npm compromise as an example of the technique appearing in commodity supply chain attacks.

It states that Netskope One Threat Protection Intrusion Prevention System detects blockchain DDR RPC patterns and points readers to a published set of indicators of compromise under Netskope Threat Labs’ repository.

The overall takeaway is that defenders can treat dead drop resolver traffic as a reconstructable sequence: identify the RPC call, contract address, and function selector, then decode the response to recover the active C2. This Blog Signals brief is a fact-based summary of the vendor blog.

The original article was written by Decision Insights Editorial.