Blockchain C2 in Malicious npm Packages: How ChainDrop Targets Windows Devs and CI Secrets

What Unit 42 is describing​

Unit 42 says it has seen threat actors upgrade their C2 from static endpoints baked into malware to Web3 smart contracts. In the ChainDrop npm worm, the malware queries smart contract transactions that carry encrypted information about the exfiltration IP or domain. The operator can change the infrastructure with one blockchain transaction. No new package release is needed.

The report's framing is that developer workstations and build runners are the prize. They hold IAM keys, service-account keys, deployment secrets and short-lived OIDC tokens. A malicious dependency runs during install or build, before anything reaches production, so it bypasses the usual authentication perimeter.

Unit 42 backs the concern with its 2026 Incident Response Report. That report covers more than 750 major incidents handled in 2025. It says identity weaknesses played a material role in almost 90% of investigations. It also says 87% of intrusions spanned two or more attack surfaces. These figures come from Unit 42's own caseload. They are not a census of all organizations.

Two campaigns, one problem​

ChainDrop​

Unit 42's separate ChainDrop analysis says the worm infected more than 400 npm packages. They include keyv and cacheable-request, and Unit 42 says they are downloaded hundreds of millions of times a week in total. The mechanics are as follows:

• An npm preinstall hook runs a dropper that fetches the Bun runtime if it is missing. Bun is legitimate. The attacker simply uses it as a portable way to run code.
• Bun then runs a large obfuscated JavaScript credential harvester.
• The harvester searches files and also the memory of running build processes. It targets cloud IAM keys, CI worker tokens, OIDC tokens, npm and GitHub tokens, and SSH keys.
• It plants persistent task hooks. These fire when a developer opens a project or starts an AI coding session.
• With stolen npm publishing tokens, it republishes infected versions of other packages.

On Aug. 4, 2026, Unit 42 watched the operator rotate the C2 domain through a single Ethereum transaction. The domain moved from npm-cache[.]com to a freshly registered .icu domain. Unit 42 saw victim traffic to the new domain within about 19 hours. It found 453 public GitHub repositories across five accounts matching the worm's exfiltration pattern. It also detected execution in 10 environments. Unit 42 calls the five accounts candidate victims, not confirmed ones. Treat the numbers as observed signals, not a victim count.

One Windows-relevant detail: in a Unit 42 detection, activity began inside a developer's VS Code environment. Bun ran a payload from the cacheable node modules directory. That payload spawned cmd.exe to run gh auth token and grab the user's GitHub credentials.

Unit 42 says ChainDrop resembles the Shai-Hulud toolkit. Resemblance is not attribution, and published tooling can be reused.

PolinRider​

Unit 42 describes PolinRider as spanning npm, Go modules and Packagist. It hides loaders in repository configuration, web resources and IDE workspace automation, not just install scripts. Variants resolve C2 through multi-chain lookups on TRON, Aptos and BNB Smart Chain. Some use the zero-data NullReceiver technique. Operators combine these in a hybrid design. If RPC gateways or lookups are blocked, a backup channel takes over.

Socket's July 2026 research adds practical detail. This is Socket's finding, not Unit 42's:

• Observed loaders reach TRON, Aptos and BNB Smart Chain RPC services. They fetch encrypted second-stage material and decrypt it with embedded XOR keys. Then they run it with eval().
• Observed follow-on payloads include DEV#POPPER and OmniStealer.
• Loaders hide in config files such as vite.config.js, or in fake .woff2 font files. A .vscode/tasks.json task set to run on folder open then executes them.
• Attackers rewrite Git history with force pushes and backdated commits. The repository's front page can look clean while the GitHub Activity view shows the tampering.

Three stages of blockchain C2​

Unit 42 describes three architectural phases. Treat this as its framing of observed techniques. Not every campaign necessarily followed the same chronological path.

On NullReceiver, Unit 42 says the loader reads the recipient address, checks an ASCII validation marker, and converts the leading four bytes into an address. Open-source researchers described the same technique independently. OpenSourceMalware.com identified it in the trojanized npm packages bianira-ui and fluid-type-ui. It said NullReceiver fixes EtherHiding's biggest weakness, a fixed and publicly known destination address. Sonatype reported six npm packages using it. Per The Hacker News, Sonatype said the loader decodes the bytes into two IPv4 addresses that serve as primary and secondary C2 endpoints.

The North Korea angle, and where to be careful​

Unit 42 ties its Axios, Mastra AI and Rust arrayref examples to Alluring Pisces, also known as Sapphire Sleet or Midnight Neptune. It cites matching beacon behavior, SSL configurations and clustered VPS hosting. These operations are corroborated by other sources, but each should be read on its own terms.

• Axios. Microsoft's report says malicious Axios versions 1.14.1 and 0.30.4 appeared on March 31, 2026. They added the [email][email protected][/email] dependency, whose post-install script fetched a second-stage RAT. Windows, macOS and Linux were all targeted. On Windows, the payload was a PowerShell-based RAT. Microsoft's safe versions are 1.14.0 and 0.30.3. Microsoft's report describes a conventional C2 domain, not the blockchain techniques in Unit 42's article. The two should not be merged.
• Mastra. Microsoft documented a separate staged npm compromise. A clean bait package, [email][email protected][/email], came first. Version 1.11.22 followed with a post-install hook. Then [email][email protected][/email] and more than 140 other @mastra packages were published with the dependency. Microsoft attributed it to Sapphire Sleet with high confidence in a June 19 update. On Windows, it observed a PowerShell backdoor, Defender exclusions being added, and a SYSTEM-level service implant.
• Cross-campaign attribution. Amazon Threat Intelligence assesses with medium confidence that the Axios, debug, chalk and typo-crypto compromises trace to the same DPRK-linked actor. That is a separate line of corroboration. It does not independently verify the blockchain methods in PolinRider.

The Rust arrayref incident was documented separately in a Rust project advisory. Unit 42's discussion alone does not establish that it used blockchain C2.

PolinRider itself is linked by Socket to North Korea's broader Contagious Interview activity. Unit 42 describes it as DPRK-affiliated. Attribution confidence varies across vendors, so be wary of any claim that flattens it into one definitive story.

What defenders can do​

Unit 42's headline advice is simple. First, decide whether blockchain traffic is ever legitimate in your organization. If it never is, any outbound RPC call to a blockchain gateway is a high-confidence anomaly. Blocking becomes an easy win. If you have approved Web3 work, don't block blindly. Baseline it and watch process context instead.

A practical checklist, combining Unit 42's guidance with Microsoft's, Socket's and ChainDrop-specific advice:

1. Watch process context, not just domains. Alert when a package manager, scripting runtime, compiler, IDE or build runner connects to a public blockchain RPC endpoint. A domain blocklist is brittle when the C2 address changes on-chain.
2. Audit workspace automation. Look for VS Code tasks with "runOn": "folderOpen", especially ones that run files with odd extensions such as .woff2 through Node. Check commits that touch .vscode/tasks.json, config.js, vite.config.js and eslint.config.js.
3. Police lifecycle hooks. Flag unexpected preinstall and postinstall scripts and unauthorized edits to package manifests before code executes in CI.
4. Pin versions. Microsoft advises removing caret and tilde ranges in package.json where review of updates matters. Use exact versions and upgrade manually.
5. Clean up fully. Unit 42 warns that moving a package tag back to a clean release does not fix poisoned lockfiles, caches, mirrors or tarballs already sitting in CI images. Clear them and fetch the updated release.
6. Rotate secrets from a clean machine. Unit 42's ChainDrop guidance lists npm tokens, GitHub PATs, deploy keys, cloud credentials, Kubernetes service-account tokens, Vault tokens, SSH keys and AI-provider credentials. Treat any runner that executed the worm as compromised.
7. Map the blast radius. If a developer installed an affected release, enumerate every package their npm credentials could modify. ChainDrop tries to republish through them.
8. Review Git Activity logs. Force pushes and backdated commits can hide tampering, so the commit history alone is unreliable.
9. Watch the contract. For ChainDrop, Unit 42 notes that monitoring the smart contract for setStrings() calls would give early warning of the next domain rotation.

For Microsoft-centric environments, Microsoft's Axios guidance points to Defender XDR advanced hunting, Sentinel TI mapping analytics and Defender for Cloud's cloud security explorer. These can find affected package versions in container images. Microsoft's Exposure Management graph can also help gauge the blast radius from an affected endpoint.

Analysis: why this matters beyond the vendor pitch​

This is a vendor report, and the vendor sells endpoint, cloud and secrets products. Some of its recommendations, such as AI-driven behavioral analytics, read like a product shopping list. The underlying technique, though, is independently corroborated. Sonatype, OpenSourceMalware.com, Socket and Google (for EtherHiding in other settings) have all documented blockchain-hosted C2. The core idea is sound. Blockchain lookups remove the single takedown point that registries and DNS sinkholes depend on.

There is also a limit worth stating. Blockchain traffic is not inherently malicious, and legitimate developer tools use the ethers library. Unit 42's own claim that any outbound blockchain interaction is a "high-confidence anomaly" holds only for organizations with no Web3 activity. Everyone else needs to baseline before they alert.

The wider lesson is about where credentials live. A CI runner's memory, a developer's gh auth token and a cached OIDC token are all valuable. A package that appears clean today can be armed later, because the endpoint it consults changes on a blockchain you cannot take down. Short-lived credentials, pinned dependencies and process-aware monitoring work better here than any single blocklist.