Dubbed NullReceiver, this newly uncovered technique bypasses conventional security monitoring by encoding malicious IP addresses directly into the destination bytes of zero-value, zero-data Ethereum transfers.
Discovered inside trojanized npm packages linked to the DPRK’s notorious “Contagious Interview” campaign, NullReceiver appears to be a direct evolutionary response to the burn-address monitoring that exposed its predecessor, EtherHiding.
Here is an in-depth breakdown of how NullReceiver works, why it signals a shift in open-source supply chain attacks, and what security teams must do to defend against it.
Evolution of Blockchain Dead Drops: EtherHiding vs. NullReceiver
Threat actors have long leveraged decentralized blockchains as “dead drops”. Because public ledgers run across thousands of distributed nodes, the transaction records hosted on them are virtually impossible for law enforcement or defenders to take down.
In late 2025, security researchers documented EtherHiding, a technique where DPRK operators embedded encoded scripts or C2 URLs into the transaction payload (calldata) of transfers sent to Ethereum’s well-known burn address (0x000...dEaD).
While effective, EtherHiding suffered from a critical architectural flaw: it relied on a fixed, public destination. Security operations centers (SOCs) quickly built detection signatures around traffic interacting with the burn address carrying anomalous calldata.
EtherHiding Flow (Legacy):
Malware ---> Fixed Burn Address (0x000...dEaD) + Payload in Calldata ---> Decodes C2 URL
NullReceiver Flow (New):
Malware ---> Queries Attacker Wallet ---> Reads Recipient Address Bytes ("To" Field) ---> Decodes C2 IP
NullReceiver eliminates this signature entirely.
How NullReceiver Operates
Discovered during static analysis of the malicious npm packages bianira-ui@1.27.0 and fluid-type-ui@2.0.8 (clones of popular Tailwind CSS plugins), NullReceiver operates without executing smart contracts or carrying transaction data.
Instead, the malware performs a read-only RPC lookup against public Ethereum nodes (such as 1rpc.io or drpc.org) to fetch the latest outbound transaction from a designated attacker wallet.
The Technical Mechanism:
- No Calldata (
input: "0x"): The transaction contains zero extra data and transfers zero ETH, rendering it indistinguishable from a standard, minimal gas fee transfer. - The Destination IS the Payload: The “recipient” address is not a real wallet or smart contract. It is a single-use, throwaway string generated by the attacker to encode data within its raw address bytes.
- Runtime Decoding: Once fetched, the client-side malware parses specific byte positions from the destination address to reconstruct the C2 IP address.
In the analyzed sample, the destination address 0xa658863ea658863e68656c6c6f6970626f742121 yielded the IP address 166.88.134.62, while the trailing bytes encoded the ASCII marker string "helloipbot!!".
Feature Comparison
| Feature | EtherHiding (Legacy) | NullReceiver (Next-Gen) |
| Secret Location | Transaction calldata field | Recipient (To) Address Bytes |
| Destination Used | Fixed Public Burn Address (0x...dEaD) | Unique, throwaway address per update |
| Transaction Data | Non-empty (contains payload) | Completely empty ("0x") |
| Gas Cost | Higher (pays for payload storage) | Lowest possible base transfer cost |
| Primary Weakness | Static destination easy to monitor | Sending wallet reuse across campaigns |
Why NullReceiver Matters to Global & Regional Security Teams
The rise of NullReceiver highlights a broader trend: threat actors are turning open-source software registries (like npm, PyPI, and RubyGems) into delivery vectors for stealthy RATs (Remote Access Trojans).
Global & MEA Impact
For organizations across North America, Europe, Asia, and the Middle East & Africa (MEA) – where rapid digital transformation and cloud-native software development are accelerating – supply chain compromises represent an immediate risk.
Developers pulling unverified or typosquatted packages can unknowingly introduce blockchain-backed beacons into corporate networks, giving adversaries persistent access behind corporate firewalls.
10 Recommended Actions & Mitigations for Security Teams
To defend against stealthy blockchain-resolved malware and open-source supply chain threats, security teams should implement the following control measures:
- Implement Automated Dependency Auditing: Enforce strict Software Bill of Materials (SBOM) verification and block unvetted npm/PyPI packages prior to integration into build pipelines.
- Deploy Continuous Cybersecurity Monitoring: Enhance SOC capabilities to detect unusual outbound HTTP/HTTPS requests originating from developer machines or CI/CD build environments.
- Restrict Public RPC Node Access: Block or flag outbound requests to public Web3/Ethereum RPC endpoints (e.g.,
1rpc.io,drpc.org,infura.io) from corporate networks unless explicitly required for business logic. - Conduct Regular Testing and Penetration Testing: Perform routine offensive assessments and simulated supply-chain compromise tests to evaluate your organization’s detection and response speed.
- Enforce Developer Security Training and Awareness: Educate engineering teams on the risks of typosquatting, rogue package maintainers, and third-party dependency risks.
- Monitor Known Indicators of Compromise (IOCs): Block the C2 IP addresses
166.88.134.62and flag references to the Ethereum wallet0xa322e5f3d311d3080e6f0121063e9adc2490ef1aacross network logs. - Inspect Node.js Network Activity: Monitor Node.js processes (
node.exe/node) making direct socket or HTTP calls outside normal environment boundaries. - Adopt Zero-Trust Network Architecture: Ensure endpoint isolation policies prevent lateral movement if a developer’s workstation becomes compromised through a rogue package.
- Track Emerging Threats on CyberCory Magazine: Stay informed on evolving DPRK tactics, software supply chain risks, and emerging malware tradecraft.
- Establish Endpoint Detection and Response (EDR) Rules: Configure EDR solutions to trigger alerts on obfuscated or base-encoded strings inside Node.js modules (e.g., detection signatures like
A10-npm3!).
Key Indicators of Compromise (IOCs)
- Malicious npm Packages:
bianira-ui@1.27.0,fluid-type-ui@2.0.8 - Attacker Ethereum Wallet:
0xa322e5f3d311d3080e6f0121063e9adc2490ef1a - NullReceiver Address Example:
0xa658863ea658863e68656c6c6f6970626f742121 - C2 Server Infrastructure:
166.88.134.62:443,166.88.134.62:80 - Detection Signature:
A10-npm3!
Conclusion
NullReceiver demonstrates how state-sponsored cyber adversaries continuously refine their tradecraft to stay ahead of defenders. By shifting from fixed burn addresses to disposable recipient bytes in blank Ethereum transactions, DPRK actors have removed the primary signature that made EtherHiding detectable.
As adversaries increasingly weaponize public blockchains and open-source package repositories, organizations must shift from static signature matching toward behavioral detection, developer environment controls, and strict supply chain governance.




