Malicious packages are hard to avoid and hard to detect — unless you know what to look for.

Jeff Martin, Vice President of Product, Mend

May 3, 2023

5 Min Read
Skull on a screen with a backdrop of various letters and numbers
Source: James Thew via Alamy Stock Photo

Last January, thousands of users of two popular open source libraries, "faker" and "colors," were shocked to see their applications breaking and showing gibberish data after being infected with a malicious package. And in October, a threat actor published 155 malicious packages to the npm repository in a typosquatting campaign targeting users of 18 legitimate packages, which, combined, typically see more than 1.5 billion weekly downloads. The attacker's goal? To download and install a backdoor password stealer/Trojan.

As the name implies, a malicious package is software that is created with malicious intent. What makes them particularly concerning is that they are remarkably easy to create. Useful for any number of malicious intentions, these packages are hard to avoid and to detect, unless you know what to look for.

A Fast-Growing Threat

Malicious packages aren't new, but they're proliferating at an alarming pace. In our "Malicious Packages Special Report," Mend identified a 315% increase in malicious packages published to npm and RubyGems alone from 2021 to 2022, and expects that trend to continue.

A type of malware, malicious packages use similar techniques to trick people into downloading them, where they wreak havoc inside users' systems. Because malicious packages are something that generally come in from places you think you trust, they are abnormally effective.

Malicious packages are an automated way of creating an attack vector or getting data to enable another attack vector that doesn't require any additional activity from the attacker. You simply upload the package and let it go. From a threat actor's perspective, the effort expended nets a high return. It's not surprising then that we are seeing a meteoric increase in malicious packages.

Anatomy of a Malicious Package Attack

Malicious packages are used to steal credentials, exfiltrate data, turn applications into botnets, or erase data. But first, attackers need to trick someone or something into downloading the package.

Attackers utilize four basic attack vectors for malicious packages:

  1. Brandjacking: When an attacker acquires or otherwise assumes the online identity of another company or an owner of a package and then inserts a malicious code. The latter method was used in the attack on cryptocurrency exchange dYdX. In this case, the malicious package versions contained a preinstall hook that made it appear as though a CircleCI script was about to be downloaded.

  2. Typosquatting: Like its name suggests, this attack relies on a simple typo. An attacker publishes a malicious package with a name similar to a popular package and waits for a developer to misspell the package name and unintentionally call the malicious version.

  3. Dependency hijacking: An attacker obtains control of a public repository in order to upload a new malicious version.

  4. Dependency confusion: A more recent addition to the attack vector list, dependency confusion happens when a malicious package in public repositories has the same name as an internal package name. The attacker uses this to trick dependency management tools into downloading the public malicious package.

As malicious packages are still relatively young, the techniques attackers rely on are likewise unsophisticated. Attackers using malicious packages tend to rely on four common techniques, including re- and post-install scripts, basic evasion techniques, shell commands, and basic network communication techniques. In the case of network communication, malicious packages use basic methods to deploy, execute, and communicate on the machine. That's good news for defenders, since even if the package is successfully downloaded, it remains relatively easy to detect while deployed.

As with attack vectors, attackers are increasingly adopting more sophisticated techniques, such as telemetry, which enables data collection. There are many opportunities for bad actors to refine their use of malicious packages. We expect to see more diverse and advanced approaches, and harder-to-spot attacks, as threat actors evolve their techniques.

While at first glance the timing of malicious packages being released seems random, our research found almost 25% published on Thursday afternoons. We attribute this to attackers knowing the prevalence of cybersecurity vendors based in Israel, where many observe Friday and Saturday as the weekend. Additionally, targeting Israel's time zone, we see the attacks launching in the late afternoon when the workweek ends.

Open Source Doesn't Have to Mean Open Season

The chief reason malicious packages work so well is because open source is publicly accessible. Not only can a novice with basic programming skills easily create a malicious package, they can just as easily publish the code to open source repositories that are used by millions of developers. The chances of success are very much in their favor.

This is why it's so important to understand what gets brought into applications through open source code. If companies haven't already, they need to start prioritizing their software supply chain. They must use an automated scanning tool that can monitor open source code repositories and libraries for vulnerabilities and attacks, and take advantage of tools that can help generate a software bill of materials (SBOM). Unlike vulnerabilities that can linger in codebase for months, malicious packages are an urgent threat to software and systems.

Attacks such as Log4j and the SolarWinds breach grab headlines, but they represent a tiny fraction of the relentless attacks launched daily against applications. The increasing threat of malicious package attacks adds further urgency to the growing need for a new approach to application security programs. Only through persistent and automated AppSec can organizations gain the upper hand in the battle for secure software.

About the Author(s)

Jeff Martin

Vice President of Product, Mend

Jeff Martin has spent the last 20 years in product roles helping both the organizations he worked for and their customers transform and measure their software risk management processes and practices. He especially enjoys cultural and mindset transformations for their ability to create lasting progress.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights