An ongoing supply chain campaign shows how malicious npm packages can bypass installation protections by activating during normal application use. The indexed-btree package hides its malware loader inside a commonly called function instead of using detectable installation scripts.
Package Impersonates Popular Library
Security researchers at Checkmarx discovered the malicious indexed-btree package during an investigation into npm supply chain threats.
The package attempts to imitate sorted-btree, a legitimate library with around two million weekly downloads. Attackers often choose this tactic to catch developers who mistype a package name or mistake a clone for the real project.
Indexed-btree also presents itself as a legitimate software library. Its creators built a convincing repository, created a detailed commit history and carefully maintained the associated developer account.
As a result, developers examining the project might not immediately notice anything suspicious.
Checkmarx also connected nine additional npm packages to the same campaign. npm has since removed those packages from its registry.
npm Blocks Unapproved Installation Scripts
GitHub announced additional npm protections in June 2026 after repeated attacks disrupted the open-source ecosystem.
One important measure restricts dependency lifecycle scripts. Packages can use preinstall, install and postinstall scripts to execute code while npm installs them.
Threat actors have frequently abused these scripts to infect developer systems. Therefore, npm v12 blocks them unless the user grants explicit approval.
Additional protections prevent npm from automatically downloading dependencies from Git repositories or remote URLs without permission.
These controls can stop malware that activates during package installation. However, they cannot protect against every execution path.
Malware Waits Until Runtime
Indexed-btree avoids lifecycle scripts entirely. Therefore, its installation appears clean and does not trigger npm’s approval process.
Instead, the package conceals its loader inside the BTree.prototype.set() method. Applications use this core function to add or update values in a B-tree data structure.
The malicious code activates only when an application calls the method with a specific key value. Consequently, the package can remain dormant during installation and initial security checks.
Once the trigger appears, the function launches an obfuscated file called sharedLoad.min.js. This file contains the first stage of the malware.
Embedding the loader inside a legitimate and frequently used method also complicates analysis. Static scanners may interpret the function as ordinary library behaviour.
Runtime Trigger Evades Security Scanners
Many software supply chain tools focus on installation activity, known malicious code patterns and suspicious data flows.
However, malicious npm packages can evade these checks by placing harmful logic inside valid application functions. The code may only activate under specific runtime conditions.
This approach limits the visible indicators during installation. It also makes automated analysis less reliable because the scanner may never reproduce the required trigger.
Additionally, the loader uses obfuscation to conceal its behaviour. Security tools must therefore identify both the hidden activation condition and the encoded malicious logic.
The campaign demonstrates why a clean installation does not guarantee that a package is safe.
Malware Collects System Information
After activation, the malware gathers details about the infected computer.
The collected information includes the system architecture, hostname, processor, available memory and uptime. These details can help attackers evaluate the compromised environment.
For example, the operators could use the information to identify valuable development systems or avoid unsuitable targets.
The malware then sends the collected data through hardcoded Slack and Telegram channels. These legitimate services can provide convenient communication infrastructure for threat actors.
Because many organisations allow traffic to these platforms, the data transfers may blend into normal network activity.
Ethereum Contract Provides Commands
The malware also checks an Ethereum smart contract for command-and-control information.
Specifically, it polls a contract on the Sepolia test network. Attackers can update the contract to provide instructions or locations for additional payloads.
This decentralised approach reduces reliance on a traditional command-and-control server. Security teams cannot easily disable the channel by taking down a single domain.
The malware uses an X25519 key exchange to generate an encryption key. It then applies that key through AES encryption to unlock a second-stage payload stored in the contract.
This design helps conceal both the payload and its instructions from researchers monitoring the blockchain.
Malware Can Remove Its Own Traces
The campaign includes a cleanup feature that helps the operators conceal their activity.
When the attackers decide to end an infection, the malware can delete its files from the affected system. It can also remove the malicious trigger from the package code.
This capability may make later forensic investigations more difficult. A developer could retain the compromised package without seeing the original harmful code.
Furthermore, the cleanup process could reduce the evidence available to incident responders. Organisations may struggle to determine which systems ran the malware or what information it collected.
Researchers Find Nine Related Packages
Checkmarx connected nine other packages to the same operation. Together, they accumulated millions of downloads:
- ordered-kv-index – 448,184 downloads
- btree-leaderboard – 493,685 downloads
- priority-slot-queue – 402,860 downloads
- btree-range-store – 468,092 downloads
- btree-core – 1,951,274 downloads
- btree-time-index – 425,312 downloads
- btree-lru-cache – 372,185 downloads
- neighbor-key-map – 366,019 downloads
- sliding-score-window – 448,024 downloads
npm has removed all nine packages. However, their download figures show that supply chain campaigns can reach many development environments before detection.
The number of downloads does not necessarily equal the number of infected systems. Automated builds, mirrors and repeated installations can significantly increase package statistics.
Cryptocurrency Wallet Holds 109 ETH
Checkmarx also identified a cryptocurrency wallet associated with the campaign’s operators.
The wallet reportedly contained 109 ETH. However, the researchers did not establish that the funds came from cryptocurrency theft or activity connected to this malware.
Therefore, the balance alone does not confirm how much money the attackers generated through the campaign.
Still, the discovery suggests that the operation may involve financially motivated threat actors with significant resources.
Developers Need Runtime Monitoring
The campaign proves that developers cannot rely solely on install-time scanning.
Security teams should also monitor how third-party packages behave while applications run. Suspicious network connections, system discovery and unexpected access to messaging platforms require investigation.
Organisations should review their dependency inventories and search for indexed-btree or any of the nine related packages.
Anyone who installed these malicious npm packages should rotate credentials, tokens and other secrets stored in the affected environment.
Developers should also restore compromised systems from a trusted backup where possible. Simply deleting the package may not remove additional payloads or undo changes made after infection.
Ultimately, malicious npm packages can exploit normal runtime behaviour to bypass controls designed around installation. Supply chain security must therefore examine what dependencies do after developers begin using them.
0 responses to “Malicious npm Packages Evade Install Defences at Runtime”