Summary
- Cyber threat actors are using public blockchains to hide malware instructions on blockchains, making it nearly impossible to seize or take down. We call these attack techniques Blockchain Dead Drops (BDD).
- Our research finds that North Korean and Iranian-state operators are among those developing distinct blockchain dead drop techniques. Nation-state threat actors now represent the majority of BDD activity.
- BDDs have surged 440% since the launch of Chinese high-capacity open-source AI models that place no restrictions on generating malicious code.
Cyber attackers are always searching for tactics that give them an advantage over digital defenders. A surging number of threat actors — from money-minded cybercriminals to agents of Iran — are finding their latest advantage on the blockchain. Instead of storing their malicious code on centralized servers that are prone to disruption, they store them on public blockchains, censorship resistant databases that cannot be taken offline.
At Chainalysis, we call this technique “blockchain dead drops” (BDD). BDDs store payloads in on-chain transactions and smart contracts where infected devices can retrieve them on demand. The permanence of blockchains gives threat actors’ cyber campaigns longevity; they can communicate with compromised machines without fear of losing their command-and-control (C2) relayer.
The danger of blockchain dead drops is not greater destructive power. The danger is greater campaign durability. Threat actors can use blockchains as durable coordination layers that survive domain seizures, hosting takedowns, repository removals, and other web2 disruptions.
Cheap to use, hard to disrupt, and accessible around the world, blockchain communication can add an additional challenge to maintaining effective cybersecurity. Traditional threat-intelligence platforms can miss the on-chain activity associated with cyber threats, creating a visibility gap that blockchain intelligence can help close.
Especially following the explosion of open-source AI coding tools (which lower the technical barrier to entry for cybercriminals) BDD attacks have been on the rise: up 420% in the past 12 months, and 440% since the rise of the coding tools. Our research finds nation state actors from Iran to North Korea are leading the charge.
A history of blockchain dead drops (BDDs): EtherHiding and beyond
Attackers have been using BDDs for more than a decade, initially in limited form on the Bitcoin blockchain. The earliest example dates to 2013, when a variant of the Necurs botnet stored C2 domains on Namecoin (a Bitcoin fork). In 2019, cybercriminals encoded command and control (C2) IP addresses for banking malware into the amount of Satoshis being transferred. Also that year, operators of the crypto mining botnet Glupteba wrote malicious info into Bitcoin’s OP_RETURN field.
BDDs arrived on EVM chains in mid-2023 with “EtherHiding.” ClearFake operators faced a problem; CloudFlare had cracked down on the servers they were using to deliver their infostealing malware. So they embedded their malicious code in smart contracts on Binance Smart Chain (BSC) instead. Because BSC cannot be taken offline, the cybercriminals could keep their campaign going. Within days, other, seemingly unrelated threat actors were testing how to host their own malware on blockchains. Supported by smart contract C2, the Smargaft DDoS attack botnet was live on BSC by late December 2023.
The resilience and relative obscurity of blockchain-based C2 is likely what attracted nation-state actors to BDDs. In late 2024 Iranian threat actors linked to the regime’s Ministry of Intelligence first embedded C2 data in Bitcoin transactions. And in early 2025 North Korean agents began strengthening their fake job interview ruse with EtherHiding.
Malicious writes to the blockchain have increased from 2.06 writes per day before high capacity open-source Chinese AI models to 11.1 per day – a 440% increase in less than a year.
Historically, building effective BDDs requires substantial cybersecurity and crypto experience. But in mid-2025 the launch of sufficiently powerful open-weight Chinese LLMs (which launched without restrictions on generating malicious code) removed the barrier to entry. Suddenly, many different, less-experienced threat actors could deploy BDDs with ease.
We are now tracking BDD activity across five major blockchains and over a dozen named malware strains – more threat actors building more complex C2 infrastructure.
Who is driving the activity?
When we categorize the on-chain activity by threat actor type, cybercriminals accounted for essentially all of the malware instructions being posted to blockchains through early 2024. State-linked actors began appearing meaningfully in mid-2024; their share has since grown. By Q2 2026, state-actor-linked groups were responsible for roughly two-thirds of new BDD activity each quarter, and half of total BDD activity.
Nation-state operators are refining and expanding techniques that cybercriminals introduced. Later, we will highlight how the DPRK, Iranian state actors, and Russian-language cybercriminals are utilizing BDDs.
How blockchain dead drops work
BDDs vary from campaign to campaign. But they typically store either malware payloads or dynamic Command-and-Control (C2) configuration pointers in locations on the blockchain. This stored data directs infected machines to the attacker’s current infrastructure.
Once the malware has retrieved what it needs from the blockchain, the operation transitions off-chain for the actual compromise. Some campaigns target crypto wallets and credentials with infostealing malware; others install remote access trojans that give attackers persistent control over compromised machines.
We have identified the following techniques used by Russian, Iranian, and North Korean threat actors:
Transaction-based storage: Threat actors use blockchain transactions to publish C2 configurations, payload references, or infrastructure pointers that malware can later retrieve. This can occur on a single blockchain or across multiple blockchains.
Contract-based storage: Threat actors use smart contracts as resilient storage locations for C2 configurations, payload references, or infrastructure pointers. This is the model behind EtherHiding-like activity: malware can retrieve updated information from contract-readable data, while the visible on-chain evidence is typically limited to the actor’s contract setup and update activity.
These are not the only ways to hide malware on-chain. Threat actors continue to come up with new, less detectable methods. For example, some attackers have created a lightweight strategy that hinges on phantom wallets; addresses that have no private key-pair. The attackers hide their C2 server’s IP address inside the phantom wallet address bytes, as opposed to a transaction or a smart contract. They send zero-value transactions to this phantom address. The malware is programmed to decode the C2 IP from the phantom address and connect to the C2 server.
Case study 1: DPRK deploying on redundant chains
In February 2025, one DPRK-linked group tracked by Google Threat Intelligence Group (GTIG, which incorporates Mandiant) as UNC5342 began using smart contracts on public blockchains to deliver malware to job-seeking cryptocurrency developers. Bogus recruiters duped their victims into downloading malicious payloads from information contained in on-chain transactions. This attacker tactic, which relies on contract-based storage, is what’s commonly known as EtherHiding.
Our investigation connected UNC5342 to a second, previously unattributed transaction-based BDD technique.
This technique adds redundancy to the DPRK campaign by utilizing two blockchains — TRON and Aptos — to direct infected devices to a third, BSC. Within transactions on TRON and Aptos the attacker embeds encoded pointers that resolve to the same transaction on BSC. The malware runs the TRON query first; if that fails it runs the Aptos route. Either way it fetches directions to BSC, where the payload is stored.
The BSC transaction contains encrypted malware instructions in its input data — including C2 server addresses, configuration data, and in some cases references to additional on-chain stages. Once the victim’s infected device decrypts that payload, they connect to the attacker’s off-chain C2 infrastructure, where the operation transitions to remote access and data exfiltration.
The attacker rotates infrastructure by publishing new transactions, and every previously infected device picks up the change automatically. Disrupting the operation would require action across all three chains simultaneously.
As with the previously attributed DPRK campaign, this new variant deploys credential-stealing malware meant to drain the victim of their crypto. The activity fits within the DPRK’s long-running cyber effort to steal digital assets and fund the regime.
Through our on-chain analysis, we connected this new activity to the same BSC deployer that GTIG attributed to UNC5342.
Case study 2: Iran operators using Bitcoin OP_RETURN
Threat actors that we suspect are linked to Iran’s Ministry of Intelligence are writing C2 infrastructure onto the Bitcoin blockchain. In this case, the blockchain transaction stores encoded C2 routing data that malware can later retrieve. We base the Iran nexus on evidence from the malware and the broader operation, not from the blockchain activity alone. The malware family, decoding logic, operational timing, and C2 infrastructure align with previously reported activity tied to Iranian threat actors.
In this case, attacker-controlled wallets send small payments to a well-known Bitcoin address with historical ties to Satoshi Nakamoto, the pseudonymous creator of Bitcoin. The payments themselves are meaningless. What matters is the data embedded in each transaction, which the malware knows to look for and decode to retrieve the current attacker infrastructure.
This design has two advantages. First, the reference address has no connection to the attacker; it simply exists as a publicly accessible, permanent lookup point — reducing the attacker footprint. Second, it is easy to rotate infrastructure. The attacker simply broadcasts a new Bitcoin transaction with updated encoded data. As with other attack types, every infected device automatically picks up the change.
Once the malware retrieves what it needs, the operation moves off-chain into the normal malware lifecycle: command retrieval, follow-on payload delivery, remote access, credential theft, or other post-compromise activity depending on the variant.
Case study 3: Russian-language cybercriminals
Russian-language criminal groups are embedding BDD into smart contracts on the Polygon blockchain. Public threat intelligence reporting from firms including Securonix, Trinity Cyber, and LevelBlue has documented a BDD Malware-as-a-Service toolkit being marketed and sold on Russian-language criminal forums, complete with a Russian-language operator panel and a subscription model.
These actors are not necessarily state-sponsored; we classify them as “Russian-language” to point to their likeliest sphere of influence given linguistic analysis of their work as well as external reporting.
The evidence points to a Malware-as-a-Service (MaaS) operation, where a single operator maintains infrastructure that is resold or rented to downstream affiliates running their own malware campaigns. On the Polygon blockchain, where this campaign lives, this looks like one operator wallet controlling a large fleet of storage contracts, each tied to a different downstream customer or campaign variant.
This operator uses smart contracts as programmable storage. The contracts hold the current location of attacker infrastructure, and the operator updates that value periodically as domains and servers are discovered or blocked. When a compromised machine needs to contact the attacker’s server, it reads the contract and follows the pointer.
We observe this activity across two variants. In the simpler version, a single operator wallet maintains one storage contract that serves all downstream traffic.
A single operator wallet (left) deploys and updates a resolver contract (right), which serves a single campaign.
In the larger version, a primary operator wallet controls a fleet of contracts, consistent with the MaaS model or rental structure where each contract likely corresponds to a different customer or campaign.
Our on-chain analysis ties the deployer wallet from this campaign to a much wider footprint of activity. It appears linked to fraudulent tokens impersonating stablecoins, clipboard-hijacking campaigns targeting crypto users, and over 50 near-identical Binance Smart Chain resolver contracts.
In other variants of this central deployer model, the same deployer address also funds additional deployer wallets that deploy resolver sets using the same contract code, vastly expanding the on-chain reach for these campaigns. A traditional campaign-centric investigation would treat these as separate cases. On-chain, they converge on the same operator, showing how wallet-level attribution surfaces the full scope of a threat actor’s activity.
What to do about blockchain dead drops
Public blockchains are cheap to use and highly resistant to takedown. As long as those properties hold, a myriad of threat actors will incorporate BDDs into their cyberattacks.
Defenders cannot feasibly address BDDs by blocking blockchain traffic from their network.
For example, blocking “Ethereum traffic” would require blocking every public RPC endpoint operated by companies like Cloudflare, Infura, and Alchemy, which would also break every legitimate blockchain application, wallet, and DeFi service in the process — and the attacker could still fall back to running their own node.
Blockchain intelligence can, however, strengthen the defense. The same immutability that makes blockchain dead drops attractive to threat actors makes them uniquely observable. By following the trail of evidence that attackers create with each transaction, defenders using infrastructure identification tools can profile the adversary and tailor their response.
The Chainalysis automated threat monitoring platform already assists law enforcement agencies, financial institutions, regulators, and tax agencies in preempting threats like these. If you are interested in learning more, request a demo of Chainalysis Data Solutions.
FAQs
What is EtherHiding?
EtherHiding is a technique in which threat actors store malware command and control (C2) data inside smart contracts on a public blockchain, so that infected machines can retrieve their instructions from infrastructure that cannot be seized or taken down. Chainalysis tracks EtherHiding as one form of a broader category we call blockchain dead drops.
Is EtherHiding the same as a blockchain dead drop?
EtherHiding is the original and best-known form of a blockchain dead drop. Chainalysis uses “blockchain dead drop” as the umbrella term because the same tradecraft now appears in forms EtherHiding does not cover, including transaction-based storage embedded in transaction fields (memos, calldata) and cross-chain relays spanning several networks. The category maps to MITRE ATT&CK T1102.002, Web Service: Dead Drop Resolver.
What is a blockchain dead drop (BDD)?
A blockchain dead drop is a pre-arranged, takedown-resistant location on a public blockchain where threat actors deposit malicious payloads, command and control (C2) configurations, or pointers for later retrieval by malware on a victim’s device. The technique borrows its name from traditional espionage tradecraft, where operatives leave materials at a physical location for later pickup.
Why are threat actors moving their infrastructure onto blockchains?
Public blockchains are decentralized, immutable, and cannot be seized or taken down through traditional means. Once a malicious pointer is written on-chain, it stays there. Attackers can rotate C2 infrastructure with a single new transaction without ever needing to reinfect their victims, making blockchain-based infrastructure far more persistent than traditional web hosting.
How does a blockchain dead drop actually deliver malware?
In the cases discussed here, BDD techniques appear in two main forms: transaction-based storage, where C2 information is embedded in transaction fields like Bitcoin OP_RETURN or BSC input data, and contract-based storage, where smart contract state holds the current C2 pointer. Compromised devices query these locations through standard blockchain RPC calls, decode the data, and connect to the retrieved off-chain infrastructure.
Which threat actors are using this technique?
Chainalysis has identified more than 15 distinct campaigns and threat actor clusters using BDD techniques. Our research highlights three case studies: DPRK-attributed actors using a cross-chain relay across TRON, BSC, and Aptos; Russian-language cybercriminal groups using Polygon smart contracts as C2 resolvers; and an Iran-nexus operator using Bitcoin OP_RETURN fields tied to Satoshi-era addresses.
Can blockchain developers stop this activity at the protocol level?
Almost certainly not. Any effort to restrict what data can be written to a public blockchain would require fundamental changes that carry significant ramifications, likely outweighing the value of the intervention. Detection, attribution, and downstream disruption remain the primary paths forward.
How can this activity be detected and disrupted?
Every on-chain rotation is permanent, timestamped, and detectable. Blockchain analytics can map operator wallets, resolver contracts, funding chains, and update histories, connecting disparate campaigns to shared actors. For organizations with endpoint visibility, monitoring outbound JSON-RPC calls to public blockchain endpoints represents a scalable early-warning signal.
This website contains links to third-party sites that are not under the control of Chainalysis, Inc. or its affiliates (collectively “Chainalysis”). Access to such information does not imply association with, endorsement of, approval of, or recommendation by Chainalysis of the site or its operators, and Chainalysis is not responsible for the products, services, or other content hosted therein.
This material is for informational purposes only, and is not intended to provide legal, tax, financial, or investment advice. Recipients should consult their own advisors before making these types of decisions. Chainalysis has no responsibility or liability for any decision made or any other acts or omissions in connection with Recipient’s use of this material.
Chainalysis does not guarantee or warrant the accuracy, completeness, timeliness, suitability or validity of the information in this report and will not be responsible for any claim attributable to errors, omissions, or other inaccuracies of any part of such material.
