NullReceiver's Blank Crypto Transfers Solves the Challenges of EtherHiding | OpenSourceMalware
We just identified a new blockchain-based command-and-control technique hiding inside two trojanized npm packages, bianira-ui and fluid-type-ui. Both are DPRK-linked clones of legitimate Tailwind CSS plugins, and both use the same trick to find their command server: they read it out of the destination address of a completely blank cryptocurrency transfer.<br>We’re calling it NullReceiver , and we think it’s a deliberate improvement on EtherHiding.<br>What is NullReceiver?<br>NullReceiver is a blockchain-based command-and-control (C2) resolution technique used by DPRK-linked npm malware. Instead of hardcoding a C2 address or hiding it in transaction calldata (as in EtherHiding), NullReceiver encodes the C2 IP directly in the bytes of the recipient address of a zero-value, zero-data Ethereum transfer. The malware looks up the attacker's wallet, reads the destination address of its most recent outbound transaction, and decodes a C2 IP straight from those address bytes, with no smart contract and no payload field involved.
Threat Type: Blockchain-based C2 resolution technique in a Node.js RAT
Affected Ecosystem: npm (bianira-ui@1.27.0, fluid-type-ui@2.0.8)
Attribution: DPRK “Contagious Interview” campaign
What it does: Decodes its C2 IP address directly from the bytes of a made-up recipient address on a zero-value, zero-data Ethereum transfer.
Why it matters: It fixes EtherHiding’s biggest weakness — a fixed, publicly known destination address. There's no smart contract, no transaction data, nothing EtherHiding-style detections are built to catch. We think it’s a strong candidate to become the DPRK ecosystem’s default blockchain dead-drop going forward.
Malware needs a way to phone home without getting its command-and-control (C2) server blocked. Hardcode a domain or IP, and defenders can flag and kill it in minutes. So DPRK-linked operators have increasingly turned to public blockchains as dead drops — ledgers that are effectively impossible to take down, since they run on thousands of machines at once. Instead of hardcoding a C2 address, the malware looks one up on-chain at runtime.<br>Blockchain dead drops for malware keep getting harder to spot, and NullReceiver is the leanest version we’ve seen yet — no contract call, no payload field, just an ordinary-looking transfer with a meaningful destination address. If your detections are built around “malware talking to a smart contract” or “malware reading data out of a transaction,” this is a reminder to also watch what address the money is (supposedly) going.<br>We did not execute any part of these packages. All findings came from static analysis of the published npm tarballs and read-only lookups against the attacker’s own public blockchain activity.<br>What is EtherHiding?<br>EtherHiding is a blockchain-based command-and-control (C2) technique that Google Threat Intelligence tied to a DPRK-linked actor in October 2025. It works by sending a transaction to Ethereum's well-known "burn address" (0x000...dEaD, the address people typically send tokens to when they want to destroy them) and embedding the actual secret, such as a C2 URL or even a whole malicious script, inside the transaction's data field (the calldata that carries extra bytes alongside a payment). The destination address itself is meaningless; only the data field matters.<br>EtherHiding's main weakness is it reuses the same fixed, public burn address across every campaign. That gives defenders a permanent "landmark" to watch, which is exactly how Google's team caught it: monitor the burn address and flag anything unusual sent there. It also costs more in gas since calldata is billed per byte, though it can carry far more data (a full URL or script) than the technique described here as its successor, NullReceiver, which can only smuggle a few bytes.<br>What NullReceiver does differently<br>bianira-ui and fluid-type-ui don’t call a smart contract, and they don’t put anything in the transaction’s data field. They hide the C2 address in a place no prior public reporting describes: the recipient of an ordinary, empty transfer.<br>Every crypto transaction has a “from” and a “to” address — think of it like writing a check. Normally the “to” address is just wherever the money is going. With this technique, the “to” address isn’t a real destination at all. Instead, it's a made-up address that was never meant to receive anything. Its only job is to encode data in its own bytes — read the right chunk as numbers, and it spells out the current C2 IP. The malware’s logic, once running on a victim machine:<br>Look up a hardcoded attacker wallet
Find its most recent outbound transaction
Read that transaction’s “to” address
Decode a C2 IP address directly out of the address bytes
Connect to that IP
The transaction we recovered carries zero value and zero data ("input": "0x") — a completely mundane wallet-to-wallet transfer. There’s no contract...