ReversingLabs researchers have made it a priority to monitor public, open source repositories for malicious packages that may lurk on them in recent years. The number and frequency of malicious packages has increased steadily as malicious actors turn to software supply chains for an easy route into hundreds, thousands or even tens of thousands of protected IT environments. 

Many of the packages the RL threat research team has found are what we term “infostealers” — malicious software that is designed to grab sensitive information. For example, our team recently wrote about a package discovered on the NuGet repository, SqzrFramework480.dll, that contained features for capturing a screenshot, sending ping packets, as well as opening a socket and sending data over it. The package contained information — including a graphic — that suggested it was targeting BOZHON Precision Industry Technology Co., a China-based firm that does industrial and digital equipment manufacturing. 

RL researchers frequently discover downloaders and malicious applications designed to fetch other software — so called second (or third) “stages” that are often open source “infostealers” or simple “beacon-backs” that red team operators use to plant a flag within target environments to prove they were successful in breaching defenses. 

Whatever their purpose, all of the packages we detect as malicious are reported to the relevant maintainers of the affected repositories. In our team’s experience, they are removed shortly after. That’s good for developers and development teams, as it removes potentially damaging code from public repositories where it might find its way onto developers’ systems, or even integrated into legitimate applications and services. 

But there’s a problem with this approach: The sheer scale of the open source ecosystem is so large that it is impossible for any single group of researchers to keep abreast of and police massive repositories like Python Package Index (PyPI), npm, NuGet, VS Code Marketplace and others. On any given day, RL researchers, using RL Spectra Assure platform, identify dozens of malicious packages spread across these repositories, but far more packages may lurk undetected — suspicious but not overtly malicious. 

Wanted: A health warning for open source packages

What developers and development organizations need is something like a health warning for open source packages — an easy way to check dangerous ingredients such as malicious or suspicious content or behaviors before the packages are deployed. 

That’s why RL is introducing Spectra Assure Community, which provides a free open source risk assessment for the most popular package repositories, including npm, PyPI, and RubyGems. The portal provides a comprehensive risk assessment for software packages, offering visibility into threats, security, and compliance issues. 

Spectra Assure Community helps prevent software supply chain breaches and attacks by providing unprecedented visibility into your software packages. A recent suspicious package the research team discovered on npm’s Registry, provides a great example of how it will work.

Discovered: A downloading uploader

A few days ago, our research team identified a  malicious package lurking on npm. The package was named legacyreact-aws-s3-typescript and “lurking” is really the right word to use. Why? Well, the legacyreact-aws-s3-typescript had been publicly accessible on npm but dormant for about four months. It mimics another popular legitimate npm package with over a quarter of a million downloads: react-aws-s3-typescript, which is designed to facilitate the uploading of files to Amazon S3 Buckets (AWS) directly using a React typescript template. (React is an open source user interface software framework.)  

Post install scripts demand a closer look

The package [email protected] was found as part of daily threat hunting activities using RL Spectra Assure platform. The package was initially flagged as suspicious because of unusual activity found inside the package’s postinstall script (Figure 1). Specifically, after the package is installed on the user’s computer, a postinstall script runs and downloads an ELF format file and executes it.

Figure 1: A postinstall script from version 1.2.4. fetching second stage ELF file

Post- and pre-install scripts are not uncommon and do not always connect with malicious activities. There are many legitimate packages present on npm that use install scripts for common software development purposes. However, packages that have install scripts demand heavier scrutiny as there is a possibility the scripts might be malicious. 

That was the case with this package as well. The ELF file downloaded by the script was still fetchable at the time the package was detected. When we analyzed that second stage software, it turned out to be a simple backdoor. It opened a socket, connected to the IP address 91[.]238[.]181[.]250, and then executed and received commands through /bin/sh. RL researchers immediately classified the package as malicious, and reported it to npm. 

A legacy of deception

The behaviors observed in the legacyreact-aws-s3-typescript package aren’t uncommon among the malicious open source packages RL has uncovered and documented. But the history of the package is a lesson in why tracking open source threats is such a challenge. 

That’s because the latest version of the package, version 1.2.4,  is not the only one published to npm. In February 2024, three versions of this package were published: 1.1.5, 1.1.6 and 1.1.7. Based on our analysis, all of them were completely clean, without any malicious activity that was present in the version 1.2.4. Those earlier editions of the package contained postinstall scripts as well. Even though some of them were unusual like invoking Windows 10’s calculator or being completely empty, nothing out of the ordinary happened when those packages were installed and those scripts were executed. 

Things changed three months later, however. In May, three versions of legacyreact-aws-s3-typescript, 1.1.9, 1.2.1, and 1.2.2 were published to npm briefly, after which they were removed almost immediately. 

It is unclear why they were removed. We suspect they were removed by the author of the packages, though we are unaware of the reason they were published and quickly removed.

However, RL researchers managed to get a hold of versions 1.2.1 and 1.2.2 and found that both were malicious, and had the same malicious functionality as was later published version 1.2.4. The team can’t say with any certainty whether version 1.1.9 was also malicious, but we suspect that it was, as it was published and removed alongside two other, malicious updates. 

A few weeks later and four months after the original, non-malicious legacyreact-aws-s3-typescript package was first published, version 1.2.4 was published and contained the malicious code described above.This update wasn’t removed and we detected it shortly after it was published to npm.

Typosquatting: A red flag for open source

Code analysis aside, there were some other features of the legacyreact-aws-s3-typescript package that became apparent while looking at the package’s npm page and suggested that something was amiss.

At the top of that list was the appearance of typosquatting, in which a malicious or suspicious package adopts a name that is close — or identical to — a popular, widely used package or file. Looking at the legacyreact-aws-s3-typescript’s npm landing page and digging into the README.md and linked GitHub page both pointed to a legitimate npm package, named react-aws-s3-typescript. With around 255.29K downloads, that package is also advertised as a tool to upload files into AWS S3 Buckets directly using the react typescript template. Upon closer examination, it was clear that the code from the legitimate package was copied and pasted into the malicious one. That resulted in two npm landing pages, one belonging to a legitimate package and another to the malicious package, with both looking exactly the same.

Figure 2: legacyreact-aws-s3-typescript’s npm page

The malicious actor behind the legacyreact-aws-s3-typescript package took further steps to try to convince developers their malicious package is legitimate and safe to use. For example, the last published version of react-aws-s3-typescript is 1.1.5 and it was published two years ago. The first version of malicious package legacyreact-aws-s3-typescript is also 1.1.5 and it was published about four months ago. What’s at work is an effort by the malicious actors to pass their package off as a continuation of — and update to the react-aws-s3-typescript package. Having the word “legacy” in the name only further validates that theory.

Figure 3: legacyreact-aws-s3-typescript’s versions previously available on npm

Spectra Assure Community: A portal for OSS truth

Of course, picking out these subtle, suspicious indicators isn’t easy — especially for developers and development teams under pressure to meet aggressive development and release deadlines. That’s why RL is introducing Spectra Assure Community, a free portal where developers can access all the information on packages we find on platforms like npm, PyPI and RubyGems through the RL research team’s regular scanning and threat hunting efforts. 

For the packages like legacyreact-aws-s3-typescript, Spectra Assure Community provides a vital assessment of the trustworthiness of the underlying code in the package. 

A portion of information Spectra Assure Community provides can be seen in Figure 4. As you can see, the scan of the package immediately detected the presence of malware in the latest update as well as a critical, unpatched vulnerability.

Figure 4: legacyreact-aws-s3-typescript page on Spectra Assure Community page

Malicious packages found on public repositories are unfortunately nothing new — and they’re becoming more common each day. 

RL’s latest research uncovered a package on the npm repository mimicking a very popular legitimate npm package that was dormant for 4 months before the maintainer published a string of new, malicious versions containing downloader functionality, culminating in version 1.2.4, which RL downloaded and analyzed. 

The RL research team’s latest discovery shows that threats lurking on public repositories are still prevalent, and developers and software publishers alike need to pay close attention to the risk brought in by third-party, open source components. While that includes the risks posed by vulnerable code, that’s not the full extent of open source risk. As our latest research shows, hasty decisions by developers risk introducing malicious code into otherwise clean products. That’s why it’s necessary for developers to conduct security assessments that can verify the integrity and quality of public, open source libraries for safety before they are used. 

With the launch of the Spectra Assure Community developers and software publishers now have a powerful new tool to help them do just that quickly, and easily. Leveraging RL’s award-winning Spectra Assure software supply chain security solution, Spectra Assure Community enables developers, maintainers, repo managers, and engineering teams among to assess more than five million code packages from open source repositories for malicious code, code tampering, suspicious behaviors, known vulnerabilities, license compliance issues, exposed secrets, and overall package health. 

To learn more about Spectra Assure Community or check your open source software package for any threat, visit secure.software.

Indicators of Compromise (IOCs)

Indicators of Compromise (IoCs) refer to forensic artifacts or evidence related to a security breach or unauthorized activity on a computer network or system. IOCs play a crucial role in cybersecurity investigations and cyber incident response efforts, helping analysts and cybersecurity professionals identify and detect potential security incidents.

The following IOCs were collected as part of ReversingLabs investigation of this malicious software supply chain campaign.

Second stage payload

Additional IOCs

*** This is a Security Bloggers Network syndicated blog from ReversingLabs Blog authored by Lucija Valentić. Read the original post at: https://www.reversinglabs.com/blog/a-lurking-npm-package-makes-the-case-for-open-source-health-checks