Sonatype Research Labs has uncovered a threat your dependency scanning tools might miss: malware using Ethereum blockchain transactions to locate command-and-control servers. Six npm packages employed this method, split between three hijacked legitimate packages and three newly published malicious ones.
This is a real threat. If your team downloaded dependencies during the exposure window, you need to verify what's running in your environments now.
What This Checklist Covers
This checklist helps you detect blockchain-based command-and-control techniques in your JavaScript dependencies and establish controls to prevent similar compromises. It covers immediate incident response and long-term supply chain security for teams running Node.js applications.
Prerequisites
Before you start, ensure you have:
- Access to your package-lock.json or yarn.lock files across all environments
- Ability to review network egress logs from build and runtime systems
- Admin access to your npm registry or artifact repository
- Authority to update your CI/CD pipeline configuration
Blockchain-Based Malware Detection Checklist
1. Audit current dependencies against known malicious packages
Review your lockfiles for the six packages identified by Sonatype Research Labs. Cross-reference against your Software Bill of Materials (SBOM) if you maintain one per NIST 800-53 SR-4.
Good looks like: A documented scan showing zero matches, or if matches exist, a containment plan with specific affected systems listed.
2. Scan for Ethereum API calls in your dependency tree
Search your node_modules directory for references to etherscan.io, web3.eth, or similar Ethereum RPC endpoints. These shouldn't appear in typical business application dependencies.
Good looks like: A grep or static analysis report showing only expected blockchain libraries (if you're building crypto features) or zero matches otherwise.
3. Review network egress for blockchain node connections
Check firewall and proxy logs for outbound connections to Ethereum nodes (typically ports 8545, 8546, 30303). Your applications shouldn't query blockchain networks unless that's their explicit function.
Good looks like: Network monitoring rules that alert on unexpected cryptocurrency protocol traffic, with zero alerts from non-blockchain applications.
4. Verify package maintainer continuity for critical dependencies
For your top 20 dependencies by usage, check npm for maintainer changes in the past 90 days. Package hijacking often involves compromising maintainer accounts.
Good looks like: A spreadsheet tracking maintainer history with investigation notes for any ownership transfers.
5. Enable package signature verification
Configure your package manager to verify signatures where available. While npm doesn't enforce signing universally, you can require it for packages you publish internally.
Good looks like: Registry configuration that rejects unsigned packages for your organization's scope, documented in your artifact repository settings.
6. Implement SBOM generation in your build pipeline
Generate a Software Bill of Materials for every build. This creates the audit trail you need when threats emerge months after deployment. NIST 800-53 SR-4(2) and PCI DSS v4.0.1 Requirement 6.3.2 both reference software inventory.
Good looks like: Automated SBOM generation using CycloneDX or SPDX format, stored alongside each release artifact with cryptographic hash verification.
7. Configure runtime monitoring for unexpected network behavior
Deploy application-level monitoring that flags when your Node.js processes make HTTP requests to domains outside your allowlist. The malware used Ethereum transactions to discover JavaScript payload URLs.
Good looks like: Runtime application self-protection (RASP) or eBPF-based monitoring with alerts configured for any HTTP request to non-approved domains.
8. Establish a dependency update cadence with security review
Don't auto-merge dependency updates. The three hijacked packages were legitimate until they weren't. Create a review process that includes checking recent issues, download trends, and maintainer activity.
Good looks like: A weekly dependency review meeting where security reviews npm advisories and unusual package behavior before approving updates.
9. Isolate build environments from production networks
Your CI/CD runners shouldn't have the same network access as production systems. If malicious code executes during build, network segmentation limits what it can reach.
Good looks like: Build agents in a separate VLAN with explicit egress rules, unable to reach production databases or internal services directly.
10. Document your incident response plan for supply chain compromises
When you discover a malicious dependency, you need a playbook: which systems to isolate, who to notify, how to verify the integrity of deployed code. ISO 27001 Annex A.5.24 requires information security incident response planning.
Good looks like: A runbook with specific commands to check for indicators of compromise, contact information for your package registry provider, and rollback procedures tested quarterly.
Common Mistakes
Assuming dependency scanners catch everything. Tools like Snyk and Dependabot check against known vulnerability databases. They didn't flag these packages because the malicious behavior was novel. You need behavioral monitoring, not just signature matching.
Trusting package download counts. The hijacked packages had legitimate download histories before compromise. High download numbers don't guarantee safety.
Ignoring post-install scripts. npm packages can execute arbitrary code during installation via lifecycle hooks. Review what your dependencies do in their postinstall scripts.
Treating blockchain traffic as automatically suspicious. If you're building DeFi applications, Ethereum connections are expected. Context matters. Document which services should make blockchain calls.
Next Steps
After completing this checklist:
- Schedule a quarterly review of your dependency management process
- Subscribe to security advisories from Sonatype, Snyk, and GitHub for your language ecosystems
- Test your incident response plan with a tabletop exercise simulating a supply chain compromise
- Evaluate whether your current tooling would have detected this attack vector
The DPRK-linked campaign that deployed these packages represents state-level sophistication in supply chain attacks. Your response needs to match that threat model. Start with this checklist, but recognize it's a baseline. The next attack will use a different technique entirely.
