Spectra Assure Free Trial
Get your 14-day free trial of Spectra Assure for Software Supply Chain Security
Get Free TrialMore about Spectra Assure Free TrialKey takeaways
New research shows that attackers have already routed around a measure that npm adopted in July to close a longstanding security gap. Version 12 of the package manager stopped running dependency install scripts by default in an attempt to shut down a vector for software supply chain attacks.
Researchers have detected an ongoing npm supply chain campaign built on the malicious indexed-btree package, which mimics the legitimate sorted-btree library. Instead of a preinstall or postinstall script, the malware trigger is buried inside the package’s own prototype method and fires the moment the library is used, Bruno Dias explained in Checkmarx’s application security testing blog.
The dependency install script change at npm was meant to cut off exactly this class of malware, said Darren Meyer, a research advocate at Checkmarx. However, once running, the malware fingerprints hosts, exfiltrates data via Slack and Telegram, and uses an Ethereum smart contract as a resilient command-and-control channel.
“Attackers just moved to a new vector.”
—Darren Meyer
Here’s what you need to know about why npm’s security measure could be so easily sidestepped.
[ See webinar: Why Binary Analysis Is Becoming the New Standard ]
Waseem Ahmed, head of engineering at Secure.com, noted that some researchers had warned when npm shipped the lifecycle script change that the code still has to run at some point. “If you close the door at install time, a patient attacker moves one step downstream and runs it at import time instead,” he said.
Ahmed also said that the absence of an install script had quietly become a trust signal: reviewers would glance at the package.json, see no hooks, and relax. This btree package has a completely clean package.json, with the malware sitting in the library’s own prototype method.
“So the single heuristic that npm’s change encouraged people to rely on is exactly the heuristic this defeats.”
—Waseem Ahmed
Sonu Kapoor, a senior Angular consultant at Solid Software Solutions, agreed that npm’s July measure may have signaled to security teams that install time is the moment an npm package becomes dangerous. But a dependency doesn’t need to misbehave during installation, he said; it can wait until the application uses it. By then it may be running in a production service with access to credentials, internal systems, and customer information.
“That delay matters because the malicious activity can blend into normal application execution.”
—Sonu Kapoor
A clean install tells a user only that the package manager saw nothing suspicious, said Jacob Krell, senior director for secure AI solutions and cybersecurity at Suzu Labs. It says little about what will happen when the application uses the package. In this case, the loader was hidden inside btree.prototype.set, Krell said, so it ran in the application’s normal execution context, with the same permissions and network access as the application itself.
Jason Soroko, a senior fellow at Sectigo, said that, in simple terms, the attacker has moved from package installation to package use.
“That makes relying solely on installation-time security checks insufficient.”.
—Jason Soroko
Aviram Jenik, CEO of KhaiCode, said this shift to activation upon use turns the malware into a “sleeper cell” waiting for activation.
“This makes it borderline impossible to detect by any static analysis tools, which will not see this path activated. The only way to detect this is by actively running the application with dynamic analysis.”
—Aviram Jenik
The attackers also built cover for the package, Jenik noted, adding a fake but plausible-looking GitHub repository and commit history and a developer profile complete with photo. The public repository contains none of the malicious code, so scanning it turns up nothing.
This incident shows that attackers always adapt to security controls rather than simply giving up, said Boris Cipot, a security engineer at Black Duck Software. Blocking lifecycle scripts such as preinstall and postinstall removes an important attack route, he said, but it does not make the package itself trustworthy.
Software composition analysis can help when combined with malicious-package intelligence and policy enforcement, by identifying and blocking known malicious dependencies before they progress further through the development process. But, Cipot said, it should be just one layer of a broader defense that also includes package validation, secure development environments, and monitoring of application behavior.
Complex binary analysis can dissect and scrutinize the binary code without the execution of — or even the need for — source code. The Enduring Security Framework group, a public-private working group led by the National Security Agency and the Cybersecurity and Infrastructure Security Agency, has published new guidelines focused heavily on practices for ensuring the security of open-source components in enterprise software. But within its guidance document, the ESF goes a step further, calling for application security testing tools that go beyond legacy testing by using complex binary analysis, as well as employing reproducible builds.
Matt Rose, former field CISO at ReversingLabs, said that binary code analysis can help organizations evaluate and verify the security of not just internally developed software, but also third-party commercial software in their environment.
“It is the final examination of a package for software supply chain risk, which allows for trust in that piece of software that you are either developing for your customers or that you are buying to help operate your business.”
—Matt Rose
Organizations that pulled in indexed-btree or related packages from this campaign can’t fix things by simply removing the dependency, Cipot warned. They should determine where the package was present and whether it executed, investigate affected systems for suspicious activity and possible exposure of credentials or secrets, and rebuild affected environments from trusted sources where necessary.
Blocking lifecycle scripts is still useful, Krell said, but it is a speed bump rather than a package trust model. He would look at what a dependency does when its normal APIs are called, not just whether it carries a suspicious postinstall script. “This campaign shows why runtime behavior matters,” he said, “especially for packages that appear to be ordinary utility libraries.”
The campaign is not limited to the btree packages, Checkmarx’s Meyer said. The command-and-control infrastructure still exists, and researchers expect the threat actors to continue publishing and profiting from npm malware.
“It’s good that npm disabled lifecycle scripts by default, as it does have security value, but it is important that organizations do not have a false sense of security. It doesn’t stop infections. It just moves the vector.”
—Darren Meyer


This post-mortem on recent supply chain attacks and threat actors including S1ngularity, Shai-Hulud and TeamPCP can help you prepare for what comes next.
The package poses as a security tool targeting developers looking to implement Internet-based apps with telecom networks.
Aurastealer, ACRStealer, and RemusStealer, a new potential LumaStealer variant, show MaaS in action. Here's what you need to know.


