Guides · 7 min read
Blockchain Dead Drops: Why Hackers Write Malware Commands Into TRON and What It Means for the Network
Chainalysis has recorded a 420–440% surge in on-chain malware writes. We break down why TRON became the primary route in the UNC5342 scheme and what it means for the network.Short answer
Hackers are using public blockchains as "dead drops": they write pointers and encrypted configurations into transactions, from which infected devices retrieve the addresses of command-and-control servers. According to Chainalysis, the number of such writes has grown 420% over 12 months (and 440% since July 2025), and UNC5342, a group linked to North Korea, used TRON as its primary pointer route, Aptos as a backup, and BNB Smart Chain for payload storage.
The technique analysts call blockchain dead drops has gone from an exotic curiosity to a working tool for state-sponsored hackers. A Chainalysis report states that over the past 12 months the number of cases in which malware instructions and infrastructure data were placed on public blockchains grew by 420%, and that previously unattributed activity on TRON, Aptos and BNB Smart Chain has been linked to UNC5342, a group associated with North Korea. In this scheme, malware needs the blockchain not as a wallet for moving funds, but as an unkillable command-and-control channel: the network stores a pointer that an infected machine uses to find the address of its control server. Let's look at how it works, why TRON was chosen, and what follows from this for TRX holders and USDT TRC-20 users.
What blockchain dead drops are
Every piece of malware needs a communication channel with its operator — C2 (command-and-control). Classically, an infected host sends a "beacon" to a domain or IP address and receives its next set of instructions. That point is precisely the attacker's weakest link: the domain gets delegated away, the IP lands on a blacklist, the hosting provider shuts the server down, and the campaign falls apart. Hence decades of an "arms race": multiple parallel C2 nodes, infrastructure rotation, fast-flux DNS.
A blockchain dead drop solves the same problem differently: the data is written into a transaction or into the storage of a smart contract on a public network. Such a "drop" has properties no hosting provider can offer:
- the record cannot be deleted or revoked — a confirmed transaction is final;
- it cannot be seized on request: a contract account on TRON has no private key at all, it is governed solely by its own code and access rules;
- reading the data is free and requires no authentication — any public RPC node will do;
- traffic to RPC endpoints looks like ordinary wallet or dApp activity.
The idea itself is not new: the technique has been known since 2013, when one variant of the Necurs botnet stored domains in Namecoin, and in 2023 EtherHiding appeared — placing payloads in EVM contracts. What is new is the scale.
What the Chainalysis report showed
| Metric | Value |
|---|---|
| Growth in on-chain malware writes over 12 months | 420% |
| Growth in malicious writes since July 2025 | 440% |
| Average number of malicious writes per day | from 2.06 to 11.1 in under a year |
| Share of state-linked groups (Q2 2026) | ~2/3 of new activity |
The two growth figures — 420% and 440% — refer to different baselines (the full year versus the period since July 2025), so there is no contradiction between them. The spike coincided in time with the mid-2025 emergence of powerful open Chinese AI models without restrictions on generating malicious code, but precision of wording matters here: Eric Jardine, cybercrimes research lead at Chainalysis, spoke only of a temporal correlation, not a proven causal link.
The geography of participants is broader than North Korea: actors presumably linked to Iran wrote C2 data to the Bitcoin blockchain, including small payments to a well-known address associated with Satoshi Nakamoto, while Russian-speaking criminal groups, according to Chainalysis, sell this capability as a service — via resolver contracts on Polygon.
The UNC5342 scheme: TRON as the primary route
The most interesting part for readers of a TRON blog is how roles were split between networks. As analysts describe it, UNC5342 built a three-chain structure:
- TRON — the primary route: encoded pointers are published in transactions.
- Aptos — a backup route with the same pointers.
- BNB Smart Chain — storage: a transaction holding encrypted server addresses and configuration.
The pointers on TRON and Aptos lead to the same transaction on BSC. The logic is clear: even if one of the "mailboxes" becomes unavailable to the client, the second remains, while the payload sits on a third network. Chainalysis notes directly that the blockchain increases campaign resilience, because the data stays accessible after domains and servers are blocked. Separating the "pointer" from the "payload" also makes it possible to change the server address without rewriting the malicious code itself.
At the same time, the blockchain here is not an infection vector but a control layer that comes into play after the code is already on the machine: delivery happens through ordinary channels, such as compromised npm packages (the ChainDrop attack in August 2026 affected more than 440 packages, according to Netskope), and in 2025 North Korean hackers used EtherHiding.
Why hackers specifically choose TRON
The choice of network is not ideology but a sum of technical properties. The irony is that exactly the qualities that make TRON convenient for USDT TRC-20 payments also make it convenient for "drops."
EVM compatibility. TRON contracts execute in the TVM — a deterministic sandbox compatible with the EVM at the bytecode level; most Ethereum Solidity contracts compile and run on TRON with minimal changes, as described in the network documentation. For an attacker this means a ready-made tool from the EVM world can be ported with almost no rework. TRON's documentation notes this effect in another context as well: phishing schemes from Ethereum often show up on TRON a few months later following the same template.
Cost and speed of writing. Low fees and blocks roughly every 3 seconds are attractive for legitimate payments, but equally useful for frequent pointer rotation. That said, writing data is not free: in the TVM, the SSTORE instruction costs 20,000 Energy when writing a non-zero value into a "zero" slot. Hence a practical conclusion: on TRON it is economically sensible to keep pointers short and move bulky encrypted payloads to another network — which is exactly what we see in the UNC5342 scheme. An additional constraint is that the serialized transaction size is capped by the TRANSACTION_MAX_BYTE_SIZE parameter; if it is exceeded, the network rejects the transaction.
Free and anonymous reading. Contract data is publicly readable:
eth_getCode returns the runtime code at an address, and eth_getLogs returns all logs matching a filter. An infected client needs neither keys nor registration — only network access.A low barrier to entry. Deploying a contract requires no infrastructure of your own: TronIDE runs in the browser, and all you need is a wallet, TRX for the fee_limit, and Energy. No hosting, no domain, no payment trail with a provider.
What this means for the network and its users
First, the key point: blockchain dead drops are not a TRON vulnerability. Consensus does not break, nodes are not compromised, and user funds do not disappear because of this. This is abuse of a standard feature — storing arbitrary data in a public ledger. But there are consequences, and they come in three kinds.
Reputational risk. TRON appears in reports as an element of the C2 infrastructure of state hacking groups. For a network positioned as the main rail for stablecoin payments, that is unwelcome context: every such publication hands more arguments to advocates of tough regulation.
The impossibility of "just blocking it." Corporate security tools cut off connections to known C2 infrastructure using blacklists. With a blockchain that does not work: you cannot ban access to the network's public RPC endpoints wholesale without breaking legitimate wallets and applications. Nor does hope in automated scanners help: researchers note that malware detectors for smart contracts run up against resistance to obfuscation and portability across execution environments, and reliable analysis of obfuscated EVM bytecode is still at the roadmap stage.
Compliance and "tainted" addresses. The practical consequence for an ordinary user is not a hack but filtering. The more actively blockchain analytics flag addresses and contracts from such schemes, the higher the chance that interacting with them (including accidentally — via an obscure airdrop or a call to an unfamiliar contract) will raise questions about an address when dealing with exchanges and services.
What can be done about it
There is no complete solution: by definition, data cannot be deleted from a blockchain. But the TRON ecosystem does have a layer that works at the level of visibility.
- Flagging malicious contracts. A contract can be reported on TRONSCAN; the explorer team marks such contracts, and other users see warnings — this is covered in the network's security guide.
- Tools for researchers. TRONSCAN is not only a web interface but also a set of programmatic interfaces (API, MCP server, analytical SKILLS, CLI) used daily by wallets, exchanges, dApps, compliance teams and research firms. It is exactly this kind of data that attribution like Chainalysis's is built on.
- User-side hygiene. Infection arrives through ordinary channels, so basic measures (controlling dependencies in projects, distrusting unexpected files and "test assignments," using a separate device or a hardware wallet for large amounts) remain effective regardless of which blockchain holds the pointer.
Conclusion
The growth in malware writes and the shift to multi-network schemes such as "TRON and Aptos as pointers, BNB Smart Chain as storage" show that attackers have begun treating public blockchains as high-reliability infrastructure — for the same reasons legitimate users choose them: cheap writes, fast blocks, free reads, and no single point of shutdown. For TRON this is not a story about a technical breach but about reputation and compliance: the network itself works as before, but analysts' attention to addresses and contracts will only grow, which means caution when interacting with unfamiliar contracts is becoming the norm.
Cointelegraph covers the details of the report and Chainalysis's assessments.
This material is for informational purposes only and does not constitute investment or legal advice.
LT
About the author