Researchers from ReversingLabs, who discovered the malware-ridden packages, say the attackers behind them attempted to have the packages impersonate another legitimate package — agent-base version 6.0.2 — which has been downloaded over 20 million times.
Their findings underscore an emerging trend of threat actors taking advantage of how npm has for years failed to account for certain types of typosquatting, potentially leading enterprises to inadvertently download malware, which Checkmarx recently flagged in a report.
ReversingLabs’ researchers said the discovery of the latest malicious packages, including irregularities in the package version numbers, were a red flag: in this case, a “strangely high version number” (6.0.2) that was used to try and bait developers into downloading what appeared to be the latest release of the package.
“The malicious actors were clearly hoping one of those millions of developers would be fooled into downloading the malicious package instead of the benign one,” ReversingLabs said in its report.
The TurkoRat package — which has been removed from the npm library — utilized the npm package “pkg” to bundle files into a single executable, with the files stored in a virtual file system accessible during runtime.
The nodejs-encrypt-agent was discovered to closely resemble the agent-base module it was based on, except for the inclusion of a malicious portable executable (PE) file, which executed right after the package was run, using hidden malicious commands in the index.js file.
The malicious behaviors included writing to and deleting from Windows system directories, executing commands, and tampering with DNS settings.
How You Can Spot Malicious npm Packages
Lucija Valentić, software threat researcher with ReversingLabs, explains there are many ways to identify malicious packages.
“Since package repositories contain source code, one of the simplest ways is to inspect it manually,” she says. “Packages can also be installed and executed in an isolated environment and inspected for unusual behavior.”
Any kind of out-of-place content or behavior which isn’t advertised or expected for a particular package (e.g., network requests in non-network-related packages), should be double-checked and verified.
“Always check if you need an external dependency to implement a particular functionality — if it’s something simple, it might be better to handle it yourself than to introduce unverified code in your project,” Valentić adds. “If you really need to use a library, check its name and reputation, and review the code to make sure you’re including the correct library.”
Software Supply Chain Threat
Meantime, the malicious nodejs-encrypt-agent was downloaded approximately 500 times in two months, and nodejs-cookie-proxy-agent had fewer than 700 downloads.
“Still, the malicious packages were almost certainly responsible for the malicious TurkoRat being run on an unknown number of developer machines,” the report cautioned. “The longer-term impact of that compromise is difficult to measure.”
The escalation of automated cyberattacks against npm, NuGet, and PyPI underscores the growing sophistication of threat actors and the threats to open source software supply chains. The use of automated processes to create the packages and user accounts is making it hard for security teams to identify and take down the packages.
In March, more than a dozen components in the .NET code repository were discovered impersonating other legitimate software, such as Coinbase and Microsoft ASP.NET, and running a malicious script upon installation, with no warning or alert.
Tech giants including Google are taking steps to shore up security in the open source software supply chain through deps.dev API, which helps developers with information about the packages they are thinking of using, and Assured OSS, which lets organizations incorporate the same open source packages Google secures and uses into their own developer workflows.