How Malware Uses Blockchain Dead Drops for C2—and How to Detect Them

Aug 18, 2026 · Original article ↗

Summary

Netskope explains how eight malware families across EVM, Solana and TON blockchains retrieve mutable C2 pointers, with read-only examples and hunting guidance to help distinguish malicious activity from legitimate crypto traffic.

Key points

Blockchain dead drop resolvers let malware retrieve C2 addresses or payloads at runtime from attacker-controlled smart contracts or transaction data.
Examples span EVM contract reads, Solana transaction memos and TON smart-contract lookups.
The article covers eight malware families, including DeadLock ransomware, GlassWorm and the ChainDrop npm supply-chain compromise.
ChainDrop reportedly compromised more than 440 npm packages in August 2026 and used Ethereum RPC providers to resolve its C2; the contract’s stored value has since been cleared.
For investigation, examine the RPC URL, contract address, function selector, decoded response and calling process; non-browser processes such as node or bun can help distinguish malware from benign crypto activity.
Netskope says its Threat Protection IPS provides threat-hunting rules for blockchain DDR RPC patterns and links to a collection of indicators of compromise.

Article Details

Defense Focus: Detect blockchain dead drop resolvers and recover their current C2 destinations while distinguishing malicious loader activity from benign blockchain traffic.
Detection Methods: Inspect JSON-RPC eth_call requests and correlate the RPC URL, contract address, function selector, decoded response, and originating process.
Decode contract responses containing plaintext, Base64, Base64 plus XOR, or gzip plus Base64 to recover C2 pointers or executable stagers.
Hunt for paired getSignaturesForAddress and getTransaction calls that retrieve and decode a C2 URL from a transaction memo.
Inspect get_domain REST requests that retrieve a C2 domain from a smart contract.
Use decoded content and process context to discriminate suspicious requests; the article treats non-browser callers such as node, bun, or curl as malicious indicators and browser or wallet callers as benign.
Use IPS threat-hunting rules to identify blockchain DDR RPC patterns rather than relying on public RPC hostnames alone.
Data Sources: Blockchain RPC HTTP requests and responses
IPS alerts
Originating process context
Smart-contract read results
Transaction signatures and parsed memo instructions
Smart-contract domain lookup responses
Rule Types: IPS threat-hunting rules
JSON-RPC request-pattern matching
Defensive Actions: Collect the RPC URL, contract address, function selector, decoded result, and calling-process context from suspicious traffic or alerts.
Reproduce suspicious contract reads using read-only requests and decode the returned value.
Block recovered live C2 destinations and use them as investigation pivots.
Treat an eth_call response of 0x as an empty or stale dead-drop value rather than a recovered C2 destination.
For transaction-memo investigations, increase the signature-query limit or pin a specific signature if subsequent wallet transactions change the latest result.
Avoid blanket blocking or host-only signatures against shared public RPC providers because legitimate wallets and decentralized applications use the same infrastructure.

Indicators of compromise

Type	Indicator	Context
DOMAIN	`njzlopghznkamkl[.]cfd`	Current C2 domain returned by the TONResolver smart-contract lookup.
URL	`hxxp[:]//137[.]184[.]198[.]91/R2dIXAJpSXwxP`	C2 URL decoded from the transaction memo retrieved by the GlassWorm reproduction commands.
URL	`hxxp[:]//83[.]97[.]20[.]150`	Live C2 URL returned by the article's read-only query of TroyDen's Polygon dead-drop contract.
URL	`hxxps[:]//tonapi[.]io/v2/blockchain/accounts/0:c66119f0e5635c4380441d7a79baf0c02a0ab7ea6cd78de06507fc5dc2c1a5d9/methods/get_domain`	Specific public API resource for TONResolver's malicious dead-drop contract; the article's query retrieves its current C2 domain.