A malicious npm package avoids npm's install-script block by waiting to run

A missing warning sign became a reason to relax

Security controls change how people behave. Once a risk is removed from view, reviewers stop looking for it. ReversingLabs says this campaign targets that blind spot.

In July, npm version 12 stopped running dependency install scripts by default. These scripts are called preinstall and postinstall. They were a route for supply chain attacks. The change was meant to close that route.

ReversingLabs reported that a new campaign works around the change. Bruno Dias described it in Checkmarx's blog. The campaign uses a malicious package called indexed-btree. It copies the name of a real library, sorted-btree.

What happened

The package has no install script. Its trigger sits in the library's own code, in a method called btree.prototype.set. The malware starts when an application uses that method.

How the trigger works

Think of a parcel that passes the front-desk check. It then unpacks itself once someone carries it upstairs. Install-time controls only watch the front desk.

A prototype method is a function shared by every object of one type. If an ordinary function in a library holds the hidden code, that code runs each time the app calls it.

Jacob Krell of Suzu Labs said the loader was hidden in that method. So it ran as part of the application's normal work. Whatever the application was allowed to do, the malware could do too, including reaching the network.

Sonu Kapoor of Solid Software Solutions made a related point. By the time the library runs, it may sit inside a live production service. Such a service can reach credentials, internal systems and customer data. He said the malicious activity can blend into normal application behavior.

An empty install-script list no longer signals trust

The authors also built cover for it. Aviram Jenik of KhaiCode described a plausible fake GitHub repository. It had a commit history and a developer profile with a photo. The public repository holds none of the malicious code. Scanning it finds nothing.

Jenik said static analysis, which reads code without running it, will not see this path. In his view, the way to find it is to run the application under dynamic analysis.

Boris Cipot of Black Duck Software argued for several layers of defense. One is software composition analysis, paired with malicious-package intelligence and policy enforcement. Others are checking packages before use, locked-down development environments, and watching how applications behave while running.

What this shows

The lesson here is that a control narrows the attacker's options. It does not make a dependency trustworthy. Krell called blocking lifecycle scripts a speed bump, not a package trust model.

This is one campaign, not proof of a wider pattern. It does show a gap between what a control prevents and what teams assume it prevents.

What leaders should ask their teams

Removing the package does not close the matter. Cipot advised teams to find where indexed-btree or related packages were present. They should then work out whether the code ran.

Next, teams should check affected systems for suspicious activity. They should look for possible exposure of credentials or secrets. Where needed, they should rebuild environments from trusted sources.

Meyer said the command infrastructure still exists. He added that researchers expect the threat actors to keep publishing npm malware.

Questions to put to your engineering and security leads:

Did indexed-btree or any lookalike of sorted-btree enter our builds? If so, did it run?

Which of our dependency checks only look at install time?

Do we watch what third-party libraries do when our applications call them?

Do production services have any reason to contact Telegram or Slack? Would we notice if they did?

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: ReversingLabs.