Malicious npm Packages Hide Attacker Servers Inside Empty Ethereum Transactions

Key points

• Two malicious npm packages, bianira-ui and fluid-type-ui, hid the address of their control server inside the recipient field of empty Ethereum transactions.
• Researchers named the technique NullReceiver, an evolution of the earlier EtherHiding method that stashes attacker instructions on public blockchains.
• npm is the world's largest registry of open-source JavaScript code, used by millions of developers who install packages without inspecting them.
• The trick makes the attacker's infrastructure very hard to take down, because the blockchain record cannot be deleted or blocked by a hosting provider.
• Developers who installed either package should remove it, rotate any secrets on affected machines, and audit outbound network traffic.

Security researchers have spotted a fresh trick that hides criminal infrastructure inside the Ethereum blockchain, the public ledger best known for cryptocurrency payments.

The method turned up in two poisoned software packages on npm, the giant online library where JavaScript developers grab ready-made code to drop into their apps. The packages are called bianira-ui and fluid-type-ui. Both looked like harmless user-interface helpers. Both were not.

Researchers have named the technique NullReceiver. It is a twist on an older method called EtherHiding, where criminals stash instructions or malicious code inside blockchain data so that ordinary web filters cannot easily reach in and delete them.

What is actually happening here?

The malicious packages secretly look up the address of their command server, the machine that tells the infected computer what to do next, by reading a specific Ethereum transaction. That server address is the criminals' real hideout on the internet.

Here is the clever bit. A normal Ethereum transaction moves some cryptocurrency from a sender to a recipient. In these transactions, no money moves at all. The recipient field, which normally holds a wallet address, has been stuffed with encoded numbers that the malware knows how to decode into an IP address. Once decoded, the malware phones home and asks for orders.

The technique was first reported by The Hacker News, and it fits a wider pattern of criminals treating public blockchains as an untouchable message board.

Why does hiding a server address on a blockchain matter?

Because the blockchain cannot be taken down. When investigators find a criminal server hosted on a normal web provider, they can ask the provider to pull the plug. A record written to Ethereum is copied across thousands of computers worldwide and stays there forever.

That means defenders have to spot and block the malicious behaviour on the victim machine, rather than knocking out the source. It also means the criminals can update where their server lives simply by publishing a new empty transaction. Cheap, quiet, and durable.

Who is at risk?

Any developer who installed one of the two packages, and any application they built or shipped after doing so. npm downloads happen automatically when a project is built, so a single careless install can spread the poisoned code across a whole team's laptops and into production servers.

End users of ordinary consumer apps are not the direct target here, but they can end up affected if a company they trust shipped software that pulled in a bad dependency.

What should developers and security teams do now?

Remove both packages from any project, lockfile, or build cache. Rotate credentials, API keys and tokens that lived on machines where the packages ran, because you have to assume they were read.

Check outbound network logs for connections to unfamiliar IP addresses that started around the time of installation. And treat calls to public Ethereum RPC endpoints from build servers as suspicious unless you have a reason for them being there. A build pipeline that talks to a blockchain when your product has nothing to do with crypto is a red flag.

On the identity side, this is not a login attack, so multi-factor authentication would not have blocked the initial install. It would, however, limit the damage if stolen developer tokens were later used to push code or reach cloud accounts.