A recent Checkmarx report uncovered a new npm malware campaign using blockchain for command-and-control (C2) operations. This campaign affected nine packages, with one reaching over 1.9 million downloads before removal. Your team might be wondering how this impacts your supply chain security. Here's what you need to know.
Blockchain for Malware C2: A New Challenge
Attackers are now using blockchain to manage C2 operations, changing how you handle takedowns. They stored the C2 server address in a smart contract on the Sepolia Ethereum testnet. Instead of using a domain, the malware interacts with this contract. When a C2 server is taken down, attackers simply update the smart contract with a new address.
Traditional domain-blocking and IP-blacklisting methods won't work here. You can't remove a blockchain contract as easily as a domain. Your detection efforts should focus on outbound connections to Ethereum testnet nodes. Update your network monitoring to flag smart contract interactions from development environments. If you use EDR on build servers, configure alerts for Web3 library usage from package manager processes.
Include this threat vector in your software supply chain risk register and update your incident response playbook to cover blockchain-based C2 infrastructure.
Bypassing npm's Install Script Controls
The malware didn't trigger npm's install script controls. Instead, it embedded malicious code in a runtime method, BTree.prototype.set. When a specific key value is received, it launches an obfuscated loader as a detached Node.js process.
Your pre-installation scans won't catch this. Static analysis of package.json lifecycle hooks is ineffective. You need runtime behavior monitoring to track what imported modules do during execution.
Consider these measures:
- Use sandboxed environments for dependency testing.
- Implement Runtime Application Self-Protection (RASP) tools to monitor module behavior.
- Apply network egress controls to block unexpected outbound connections from development environments.
Update your vendor intake questionnaire to cover runtime method overrides and prototype manipulation.
Spotting Malicious Repositories
The GitHub repository associated with the malware appeared legitimate, with numerous commits and active maintenance. However, the malicious code wasn't in the repository.
This highlights a gap in your due diligence. Ensure the npm package matches the repository source by using npm pack and manual diff checks. Look for differences between repo code and published tarballs. Be wary of AI-generated profile images, which may show unnatural symmetry or inconsistent lighting.
For critical dependencies, require developers to build from source rather than using pre-built packages. This ensures the repository code matches what's running in your environment.
Data Theft and Reconnaissance
The malware's first-stage loader collected system fingerprint data, including OS architecture, hostname, CPU, memory, and uptime. It exfiltrated this data via hardcoded Slack channels and Telegram chats.
While Checkmarx didn't detail the second-stage payload, the malware can delete its own files and remove trigger code after execution. This means:
- Monitor for unexpected Slack and Telegram API calls from development environments.
- Assume affected systems are fully fingerprinted for later targeting.
- Treat this as reconnaissance; the second stage likely delivers additional payloads based on target value.
- Check for prototype function modifications that may have been reverted.
If you find this malware, assume attackers have detailed intelligence about your infrastructure and may plan a second-stage attack.
Preventing Future Incidents
Assume package registries will contain malicious code and implement defense in depth.
Start with network segmentation. Development and build environments shouldn't have direct internet access. Route all package installations through an internal registry proxy that caches vetted versions.
Implement:
- Dependency pinning with hash verification.
- Automated scanning of new package versions before they enter your internal registry.
- Network egress rules blocking blockchain node connections from development environments.
- Regular audits of installed packages against known-good hashes.
For high-risk environments, consider air-gapped build environments and manual security reviews of new dependencies. Update your TPRM program to include software supply chain risk as a distinct assessment category.
Technical Indicators of Compromise
Checkmarx published indicators of compromise in their research. The affected packages include ordered-kv-index, btree-leaderboard, priority-slot-queue, btree-range-store, btree-core, btree-time-index, btree-lru-cache, neighbor-key-map, and sliding-score-window.
Although these packages have been removed from npm, the campaign is ongoing. Monitor for connections to Sepolia Ethereum testnet nodes, Slack and Telegram API calls from unexpected processes, and discrepancies between published package contents and associated GitHub repositories.
Add these patterns to your SIEM correlation rules and update your vendor security questionnaire to ask how suppliers detect and respond to supply chain compromises in their dependencies.
