Palo Alto Networks traces blockchain C2 through poisoned dependencies

A poisoned dependency can run on a build runner that holds cloud credentials, then look up its next command server through a blockchain transaction. Palo Alto Networks Unit 42 describes three ways recent supply-chain loaders make that lookup. In the most stripped-down version, a zero-value transfer’s recipient address carries an IPv4 destination. Developer workstations and CI/CD runners that execute untrusted packages or workspace automation are the entry points.

Unit 42 says its ChainDrop npm worm infected more than 400 npm packages, including keyv and cacheable-request. Its October 7 report connects the package-execution problem to changing command-and-control (C2) infrastructure: a loader can recover a destination from public chain data while the attacker changes that destination without republishing the package. Palo Alto Networks sells security products alongside Unit 42’s research; the checks below concern the runner, process and network traffic, whatever tools collect them.

Dependency hooks reach cloud credentials

ChainDrop used a preinstall hook to start a credential harvester through a downloaded Bun runtime, according to Unit 42. It searched files and memory in running build processes for cloud IAM credentials, pipeline worker tokens and short-lived federation material. An installation on a privileged runner gives that code access to the same execution environment as the build. npm’s lifecycle documentation confirms that preinstall runs during npm ci and npm install; prepare is also among the events npm runs during those operations. Treat a new lifecycle hook in a dependency update as a code-execution change, especially on a runner carrying deployment authority.

Unit 42 describes PolinRider variants across npm, Go modules and Packagist. Some loaders sit in repository configuration or IDE workspace automation, so a developer opening the workspace can trigger execution before a package-install step. Across the variants, Unit 42 reports theft of developer credentials, cloud session tokens and environment secrets. Review workspace automation settings along with package manifests when a repository or dependency changes ownership or behavior.

Blockchain lookups change the observable

Unit 42 separates the C2 lookup into three forms. In EtherHiding, a loader reads a hard-coded smart contract with the JSON-RPC operation eth_call to obtain a current endpoint. The contract address remains an observable in that design. ChainDrop used a smart-contract lookup to recover changing exfiltration destinations, the researchers say.

TxDataHiding moves encrypted destination data into transaction input. A loader retrieves transaction history, including through eth_getTransactionByHash, and resolves the destination from that data. Unit 42 reports PolinRider variants with fallbacks across TRON, Aptos and Binance Smart Chain. An attacker can change the chain transaction while the package on disk stays the same.

NullReceiver moves the signal again. Unit 42 identifies the method in compromises of bianira-ui and fluid-type-ui: the loader reads the most recent zero-value transfer for an actor-controlled wallet and derives an IPv4 destination from the recipient address. The transaction has zero value and zero input data. A network alert keyed only to a known malicious hostname or a visible transaction payload would miss that lookup; link a developer-tool process to its blockchain gateway request and subsequent outbound connection instead. These blockchain gateways are shared infrastructure, so a gateway hostname by itself is a poor compromise indicator.

Runner traffic tells the story

First, establish whether any build jobs or developer projects have an approved reason to contact public blockchain gateways. Unit 42 calls outbound blockchain traffic a “high-confidence anomaly” for an organization with no Web3 operations. In a Web3 shop, use process identity, job ownership and the expected chains to narrow the question. A legitimate gateway can serve both ordinary application traffic and an attacker-controlled wallet.

Correlate endpoint process trees with proxy or firewall connection records for a runner or developer workstation. Investigate a package-install process, scripting runtime, compiler or IDE that suddenly reaches a blockchain JSON-RPC gateway and then connects to a new destination. Preserve the job ID, dependency lockfile change, package manifest and workspace configuration, along with the request timing. A preinstall or workspace hook may fire and end quickly; a later clean-looking build can hide the short-lived process that made the request.

Restrict unnecessary build egress

Put network egress controls on CI/CD runners and developer environments that have no approved blockchain use, and alert on blocked gateway attempts with the initiating process and job context. Add repository and pipeline policy that reviews new lifecycle hooks, unexpected package-manifest changes and workspace automation before they run with cloud deployment credentials. Unit 42 says an attacker can change a C2 destination with a fresh blockchain transaction while leaving the installed package untouched, so enforce the egress and hook-review rules at the runner and repository.

For GitHub Actions jobs that use cloud roles, GitHub’s OIDC documentation explains that cloud providers validate workflow claims and issue short-lived job credentials. Scope the cloud role’s trust conditions to the intended workflow and keep deployment authority away from dependency-install jobs where possible. Short token lifetime limits exposure after a job; a malicious hook executing during that job can still reach credentials available to it. If runner or network evidence matches the reported pattern, isolate the job environment and investigate use of the cloud identity it held.

Verify the runner policy

Inventory which build jobs may contact blockchain gateways, then block that egress for the rest and require review for new dependency hooks and workspace automation. For approved Web3 jobs, record the expected runner, process and chain so an unexpected lookup has a useful comparison. A new preinstall hook or IDE automation file in a dependency change deserves review before the job receives deployment authority. Correlate a gateway request and the next outbound connection with the job ID, endpoint process tree and lockfile change; a shared gateway address alone is a noisy alert. In a controlled, nonproduction job with no Web3 purpose, test the egress rule using an approved benign connection attempt to a designated test endpoint. The expected result is a firewall deny and an endpoint event that ties the attempt to the same process and job ID. If a suspicious hook already ran, isolate the runner and review cloud-identity activity from that job.