- Unit 42 reports that supply chain malware now looks up its command server on public blockchains, which removes the fixed address defenders used to block.
- Developer workstations and build runners hold cloud keys, and the campaigns Unit 42 describes target them first.
- Ask whether your developer machines and build runners ever need blockchain access. If not, alert on it, and audit repository config files and install hooks.
For years, defenders had a simple move against malware that phones home. Find the address it calls, then block it. Palo Alto Networks' Unit 42 describes a technique that takes the address out of view. In its 7 October report, the address is no longer a string in the code. It sits on a public blockchain. In the newest variant, the address is hidden in the wallet address itself.
What Unit 42 found
Unit 42 says attackers have moved their command-and-control (C2) servers onto Web3 networks. C2 servers are the machines that send orders to infected systems. Instead of hard-coding a server in the malware, attackers publish it in blockchain transactions. One transaction can then redirect a whole botnet or worm.
The report names two campaigns. The first is ChainDrop, a self-spreading npm worm from the Shai-Hulud family. Unit 42 counts more than 400 npm packages carrying it. Two of them are keyv and cacheable-request. A preinstall script downloads a custom Bun runtime, and that runtime starts an obfuscated tool for collecting credentials.
The second is PolinRider, which spans npm, Go modules and Packagist. Unit 42 describes it as DPRK-affiliated. It hides loaders in repository configuration files, web resources and IDE workspace automation. It does not rely only on install scripts.
How the hiding works, in three steps
The report describes three stages. Each one leaves defenders less to inspect.
The first is EtherHiding. The malware asks a fixed smart contract for its server address. A smart contract is a program stored on a blockchain. Unit 42 notes this left a weak point. The request names the contract, so a security control could block every query to it.
The second is TxDataHiding, used in PolinRider. Operators put an encrypted server address in the data field of an ordinary transaction. The loader reads it and decrypts it in memory. If one network is flagged, the operator posts a new transaction on another. The report lists TRON, Aptos and Binance Smart Chain.
The third is NullReceiver. Unit 42 saw it in the front-end packages bianira-ui and fluid-type-ui. The loader looks at one wallet the attacker controls and finds its newest transaction, which moves no money. It then works out the server's IPv4 address from the receiving wallet's address. Unit 42 says no code structure or domain string is left for a filter to inspect.
The lesson: a blocklist cannot match a message that is only an address
This shows a limit in how many security programs work. Blocklists assume the attacker must write something a defender can match. Think of a spy's dead drop. A chalk mark on a public wall means nothing to anyone who is not looking for it. A zero-value transaction works the same way. To a filter, it is a normal event on a public network.
Unit 42 reaches a similar view. It says static blocklists and perimeter defenses are no longer enough. It calls for behavioral visibility instead. The question changes from "is this destination known to be bad?" to "why is this machine talking to a blockchain at all?"
Who carries the risk
The targets are developer workstations and automated build runners. Unit 42 describes them as highly privileged. They hold sensitive or administrative cloud identity keys and tokens. ChainDrop searches the memory of running build processes. It collects short-lived cloud keys, pipeline worker tokens and OIDC federation keys before the runner shuts down.
This matters for any firm that counts on short-lived credentials. They protect only if nothing takes them during their lifetime. Unit 42 adds that such credentials may give direct access to cloud consoles and APIs. That access can bypass multi-factor authentication if other controls are missing.
ChainDrop also leaves behind task hooks that restart its code. Two ordinary moments set them off: opening a project and beginning a session with an AI coding tool. A normal workday becomes the trigger.
The report links three more operations to one DPRK-affiliated actor. These are the Axios, Mastra AI and Rust arrayref compromises. Unit 42 cites matching C2 beacon behavior, SSL configurations and clustered hosting ranges. The report does not say how many organizations were affected.
Questions for your security team
First, does any developer machine or build runner have a business reason to reach a blockchain network? For firms with no Web3 operations, Unit 42 rates any such traffic a high-confidence anomaly. Ask whether anyone would see it today.
Second, can your endpoint tools show which process made an outbound blockchain query? Unit 42 advises alerts when non-crypto development tools contact public blockchain gateways. Examples are scripting engines and compilers.
Third, who reviews changes to repository configuration files, package manifests and package lifecycle hooks? That review should happen before code runs in a pipeline. Unit 42 recommends automated policy controls across runners and version control to flag unauthorized changes.
These campaigns leave fewer strings to match. Defense now depends on knowing what normal looks like on the machines that build your software.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Palo Alto Networks Unit 42.
