
NullReceiver's Blank Crypto Transfers Solves the Challenges of EtherHiding
Researchers analyzing the DPRK-linked npm packages bianira-ui@1.27.0 and fluid-type-ui@2.0.8 (Contagious Interview campaign, trojanized clones of Tailwind CSS plugins) identified NullReceiver, a new blockchain C2-resolution technique that encodes the C2 IP address directly in the bytes of the recipient address of a zero-value, zero-data Ethereum transfer, rather than in calldata as with EtherHiding. Because it uses a disposable, never-reused destination address and carries no data field, it avoids the fixed "burn address" landmark that let Google's GTIG detect EtherHiding, making it harder to fingerprint. The writeup includes the malware's wallet-lookup logic, a code snippet, and full IOCs (packages, attacker wallet, encoded address, C2 IPs).
What it is
NullReceiver, a blockchain-based C2 resolution technique found in two DPRK-linked trojanized npm packages: bianira-ui@1.27.0 and fluid-type-ui@2.0.8, both clones of legitimate Tailwind CSS plugins, attributed to the "Contagious Interview" campaign. The summary tells you this exists; below are the concrete indicators the page publishes so you can hunt for them.
How it works
The malware hardcodes an attacker wallet, queries Ethereum for that wallet's most recent outbound transaction, and reads the C2 IP directly out of the bytes of that transaction's recipient ("to") address. The transfer carries zero value and zero data ("input": "0x") — an ordinary wallet-to-wallet transfer with no smart contract and no calldata payload. The "to" address is never meant to receive funds; it exists only to encode data. The recovered transaction's recipient bytes decode to the C2 IP, and the trailing bytes spell the ASCII string helloipbot!! as an attacker fingerprint.
Indicators
The page provides these specific values, which the existing summary references but does not state:
- C2 IP:
166.88.134.62 - Attacker wallet:
0xa322e5f3d311d3080e6f0121063e9adc2490ef1a - Detection signature string in code:
A10-npm3!(assigned asglobal.i) - RPC endpoints used for lookup:
https://1rpc.io/ethandhttps://eth.drpc.org - Fingerprint in recipient address bytes: ASCII
helloipbot!!
The malware code opens with:
global.i = "A10-npm3!", global.r = require, "object" == typeof module && (global.m = module);
let http = require("http"),
https = require("https"),
S = "0xa322e5f3d311d3080e6f0121063e9adc2490ef1a",
R = ["https://1rpc.io/eth", "https://eth.drpc.org"],What to do
The authors' explicit guidance: detections built around "malware talking to a smart contract" or "malware reading data out of a transaction" will miss this — there is no contract and no payload field. Instead, watch the destination address of transfers. Hunt for the string A10-npm3! and the wallet/RPC constants above in npm package code, and block/monitor 166.88.134.62.
Caveats
- NullReceiver can smuggle only a few bytes (enough for an IP), unlike EtherHiding's calldata approach, which can carry a full URL or script. This constrains what a single dead-drop transaction can deliver.
- The researchers did not execute the packages; all findings come from static analysis of the published npm tarballs and read-only blockchain lookups. IOCs are point-in-time — the C2 IP can rotate simply by the attacker sending a new outbound transaction with a different recipient address.
Techniques named here
- NullReceiver
- EtherHiding
- Obfuscator.io string obfuscation
- Shuffled-array encoding
- Base91 encoding with rotating alphabets
- Hardcoded C2 domains
- Dead-drop resolvers
Threat actors named here
- DPRK "Contagious Interview" campaign
- DPRK-linked actor
- DPRK
- Contagious Interview
Also named here
- bianira-ui
- fluid-type-ui
Related in Supply Chain


