Malicious npm Package 'indexed-btree' with 2 Million Downloads Hides Malware in Runtime Code
A malicious npm package, indexed-btree, with nearly 2 million weekly downloads mimicked a legitimate library, activating its malware during runtime to profile hosts, steal data, and deliver payloads via an Ethereum smart contract.
A malicious npm package that appeared to be an ordinary data-indexing tool has exposed a significant weakness in software supply-chain defenses. The package, named indexed-btree, meticulously copied the identity of the legitimate sorted-btree library and managed to accrue nearly two million weekly downloads before its discovery. This campaign is particularly notable because the malware does not execute during the installation phase, a common vector for detection. Instead, it lies dormant within the application's normal code and activates only when the library is actively used, transforming a trusted dependency into a potent tool for host profiling, data theft, and subsequent payload delivery.
Researchers at Checkmarx identified this sophisticated operation, highlighting in a report shared with Cyber Security News (CSN) that security checks focused solely on install scripts are insufficient to catch threats that execute later in the development lifecycle. The sheer scale of downloads poses a considerable risk to organizations whose projects might have incorporated this package into their build systems, testing environments, or even production services. The attackers further bolstered their credibility by creating a convincing repository and account history, making the malicious package blend seamlessly into routine development workflows.
The indexed-btree package notably lacks preinstall or postinstall commands in its configuration, meaning a simple installation process would not trigger its malicious routines. This absence can lead to a false sense of security during cursory reviews. The malware loader is strategically placed within the BTree.prototype.set method, a core function that is highly likely to be invoked whenever an application stores data. Once a specific condition is met, this code initiates an obfuscated first-stage component, enabling the threat to execute during normal program activity rather than during the more scrutinized installation stage.
This novel execution strategy fundamentally shifts the defensive challenge from verifying the safety of a package's installer to scrutinizing its behavior *after* it has been imported and utilized. This aligns with a broader trend of attackers adapting trusted developer channels for malicious delivery, as evidenced by earlier reports on malicious package mirror abuse. The initial stage of the malware is designed to gather critical system information, including the operating-system architecture, host name, processor details, memory, and system uptime. This data is then transmitted to attacker-controlled destinations.
Intriguingly, instead of relying on conventional command-and-control servers, the malware consults a smart contract on the Ethereum Sepolia test network. This blockchain-based command infrastructure can make disruption efforts more challenging, as the contract can dynamically redirect the malware to alternative addresses if a primary destination is blocked or taken offline. Following this, the code employs a cryptographic key exchange to derive a decryption key, which is then used to combine encrypted data retrieved from the smart contract into a second-stage payload, according to the Checkmarx research.
The package also includes specific functions designed to clean up the malicious files and remove the trigger from the prototype method. This self-removal capability could significantly limit the forensic evidence left behind after the application first utilizes the compromised library, complicating incident response efforts.
The campaign underscores a critical gap in current security practices where the absence of lifecycle scripts is often mistakenly treated as an indicator of a benign npm package. This approach fails to detect malicious behavior embedded directly within a package's primary JavaScript functions. Organizations are advised to meticulously scan their codebases, including source trees, lockfiles, build images, developer workstations, and CI/CD systems, for the presence of affected package names or versions. Prompt removal, rotation of potentially exposed secrets, and thorough inspection of logs for specific indicators of compromise are crucial steps.
Dependency review processes should be enhanced to include scrutiny of package ownership, release history, repository consistency, and the code distributed through the registry. For more robust protection, security teams should consider running suspicious packages in isolated environments and actively monitoring child processes, filesystem changes, network calls, and overall behavior after common methods are invoked. This proactive runtime analysis can uncover malicious pathways that static scanning tools might overlook. Developers should prioritize pinning reviewed dependency versions, maintaining up-to-date software bills of materials, and enforcing strict approval workflows for new or significantly altered packages.