Researchers at Checkmarx have identified a shift in npm supply‑chain attacks: the malicious package indexed-btree no longer relies on pre‑install or post‑install scripts. Instead, it embeds malicious logic in the runtime implementation of Btree.prototype.set, a method that executes only when the library is used by application code.
What changed?
Traditional npm malware triggered during the installation phase, leveraging lifecycle scripts that npm now restricts. The new approach hides the payload inside legitimate‑looking runtime code, meaning a clean install does not automatically execute malicious behavior. The package mimics the legitimate sorted-btree module, has amassed close to two million weekly downloads, and includes an obfuscated file that gathers host details (OS architecture, hostname, CPU, memory) and forwards them to a hard‑coded Slack channel and Telegram chat. Communication with the attacker is routed through a Sepolia testnet Ethereum smart contract, which serves as a resilient command‑and‑control (C2) channel.
Why it matters to engineers and security teams
For AI, cloud, and DevOps practitioners, the change expands the attack surface beyond install‑time scanning. Dependency provenance checks that focus on package reputation or script hooks will miss runtime‑only payloads. The use of a blockchain testnet for C2 demonstrates that takedown of traditional domains or IPs may not disrupt the malware, complicating network‑based detection. The attacker also created a realistic GitHub repository with multiple commits and an AI‑generated avatar, adding social credibility that can mislead manual reviews.
Architectural and operational implications
- Runtime monitoring becomes essential. Tools that only analyze package metadata or install scripts must be complemented with behavior‑based monitoring that can detect unexpected outbound connections or suspicious function calls such as
Btree.prototype.set. - Dependency provenance needs deeper inspection. Comparing a package against its upstream source and checking for code divergence can highlight unexpected runtime logic.
- Network egress controls should consider blockchain endpoints. Outbound traffic to Ethereum testnet nodes may be a sign of C2 activity, even when no traditional domain is contacted.
- Incident response must account for self‑deleting payloads. The malware can erase its files and remove the trigger code, reducing forensic artifacts after execution.
Related CloudNinjas coverage: DevOps.
What This Means For Practitioners
Teams should extend supply‑chain security policies to include runtime code analysis, such as static analysis of downloaded modules and dynamic tracing of library usage in CI pipelines. Enforcing least‑privilege network egress, especially to blockchain networks, can limit C2 channels. Regularly audit the provenance of high‑download packages and treat unusually high download counts without recent security reviews as a risk indicator. Finally, incorporate threat‑intel feeds that flag packages mimicking popular modules, and consider sandboxing untrusted dependencies during development and testing phases.