When North Korean hackers started encoding command-and-control (C2) IPs in Ethereum transaction recipient addresses, they exposed a gap most security teams didn't know they had. The NullReceiver technique, documented by OpenSourceMalware researchers, embeds C2 infrastructure details directly in zero-value Ethereum transfers. It's clever, stealthy, and shows how unprepared most detection strategies are for threats using public blockchains as infrastructure.
The packages 'bianira-ui' and 'fluid-type-ui' were downloaded 109 and 587 times respectively before removal. While not a massive campaign, it's enough to compromise production environments. More importantly, it demonstrates a pattern: attackers are evolving faster than your detection rules.
Why These Mistakes Keep Happening
Your detection stack was built for a different threat model. Traditional C2 detection relies on network signatures, domain reputation, and traffic pattern analysis. Blockchain-based techniques sidestep all three. When the C2 IP is in a legitimate Ethereum transaction, your firewall sees normal HTTPS to a blockchain node. Your SIEM sees a package making API calls. Neither sees the threat.
The second problem is organizational. Your security team monitors network traffic. Your DevSecOps team reviews dependencies. Neither owns "what happens when a package queries Ethereum." That gap is where NullReceiver thrives.
Mistake 1: Treating Blockchain API Calls as Low-Risk
Why it happens: Blockchain interactions look like normal web traffic. Your team sees HTTPS requests to Etherscan or Infura and assumes it's legitimate Web3 functionality.
The consequence: Malicious packages query Ethereum nodes without triggering alerts. NullReceiver encodes the C2 IP directly in the bytes of the recipient address of a zero-value, zero-data Ethereum transfer. Your network monitoring sees an API call to a public blockchain node, categorizes it as "cryptocurrency research" or "developer tools," and moves on.
The fix: Add blockchain API endpoints to your egress monitoring with context-aware rules. If a package in your dependency tree has no documented Web3 functionality, any Ethereum node query should trigger investigation. Create an allowlist of packages that legitimately need blockchain access, and alert on everything else. For npm packages, check package.json for blockchain-related keywords before allowing Ethereum API calls.
Mistake 2: Ignoring Zero-Value Transactions in Threat Models
Why it happens: Security teams focus on financial transactions. A zero-value Ethereum transfer doesn't move money, so it doesn't appear in fraud detection or AML monitoring.
The consequence: You're blind to the primary vector. Zero-value transactions are free to create and cost-effective for attackers. They're also invisible to any monitoring that filters for "transactions of interest" based on value thresholds.
The fix: If your environment has any blockchain interaction, monitor transaction metadata, not just values. Look for patterns like repeated zero-value transfers to addresses that don't correspond to known smart contracts. Build detection rules that flag packages making blockchain queries without corresponding user-initiated actions. Your SIEM should correlate: "Package X made an Ethereum API call" with "Did any user request Web3 functionality?"
Mistake 3: Relying on Static Indicators for C2 Infrastructure
Why it happens: Your threat intelligence feeds provide IP addresses, domains, and file hashes. You block those indicators and consider the threat mitigated.
The consequence: NullReceiver-style techniques make your blocklists obsolete before you create them. The C2 IP isn't hardcoded in the malware. It's dynamically retrieved from blockchain data that the attacker controls. By the time you identify a malicious IP and block it, the attacker has already published a new transaction with a different C2 address. Your static defenses can't keep pace with dynamic infrastructure.
The fix: Shift to behavioral detection. Instead of blocking known-bad IPs, monitor for suspicious patterns: packages that query blockchain data and then immediately initiate outbound connections to IPs that weren't in your firewall logs previously. Implement network flow analysis that correlates blockchain queries with subsequent connection attempts. If a package reads an Ethereum transaction and then connects to an IP address within 60 seconds, that's worth investigating.
Mistake 4: Separating Dependency Analysis from Runtime Monitoring
Why it happens: You scan dependencies at build time and monitor network behavior at runtime. These are different teams using different tools.
The consequence: You catch known malicious packages during CI/CD but miss novel techniques that only activate post-deployment. NullReceiver doesn't look suspicious in static analysis. The code that queries Ethereum and decodes the recipient address might pass automated security scans. The malicious behavior only emerges at runtime when the package actually retrieves and uses the C2 IP.
The fix: Connect your dependency metadata to runtime monitoring. When your SIEM sees a package making unexpected network calls, it should automatically cross-reference that package's declared functionality. Build a runtime policy that says: "This package is documented as a UI component library. It should never make HTTP requests to blockchain nodes or connect to IPs outside our infrastructure." Tools like eBPF-based runtime security can enforce these policies at the kernel level.
Mistake 5: Assuming Open-Source Means Reviewed
Why it happens: You trust npm's ecosystem. Millions of packages, billions of downloads, community oversight.
The consequence: Malicious packages slip through. OpenSourceMalware's research shows that attackers publish packages with innocuous names and minimal functionality, wait for downloads, then introduce malicious updates. Your dependency scanner checks for known vulnerabilities, not for "this package just added Ethereum API calls in version 1.0.3."
The fix: Monitor dependency changes, not just initial installations. Set up alerts when any package in your dependency tree releases an update that adds new network permissions or external API calls. Use tools that diff package.json and the actual code between versions. If a UI library suddenly imports crypto libraries or adds network functionality, pause the update and investigate. Require manual approval for any dependency update that expands a package's capabilities beyond its stated scope.
Mistake 6: Not Participating in Threat Intelligence Sharing
Why it happens: You're busy. Sharing indicators feels like extra work with unclear ROI.
The consequence: You're always reacting, never anticipating. The NullReceiver technique was identified and named by OpenSourceMalware researchers who shared their findings publicly. Organizations that monitor open-source threat intelligence learned about this technique before it hit their environments. Organizations that don't participate in these communities are still discovering it the hard way.
The fix: Assign someone to monitor security research communities. Follow researchers who focus on supply chain attacks and novel C2 techniques. When OpenSourceMalware or similar groups publish findings, translate those into detection rules within 24 hours. Better yet, contribute your own findings. If you discover a suspicious package or technique, document it and share with the community. The intelligence you provide today might prevent your next incident.
Prevention Checklist
- Inventory all packages that make external API calls; document expected behavior
- Add blockchain node endpoints (Etherscan, Infura, Alchemy) to egress monitoring with context-aware alerting
- Create behavioral detection rules that correlate blockchain queries with subsequent outbound connections
- Implement runtime policies that restrict packages to their documented functionality
- Set up alerts for dependency updates that add network capabilities or external API calls
- Establish a weekly review of open-source security research (allocate 2 hours)
- Build a cross-team process for investigating packages that query blockchain data without user initiation
- Test your detection by simulating a zero-value Ethereum transaction query from a non-Web3 package
The NullReceiver technique won't be the last time attackers use public infrastructure to hide C2 channels. Your detection strategy needs to assume that any public API, any decentralized system, any legitimate service can become a covert communications channel. The question isn't whether your current defenses would catch this specific technique. It's whether your detection philosophy can adapt to techniques you haven't seen yet.
