· 5 min read

Analysis of 5000+ Malicious Open Source Packages

Analysis of malicious open source packages from Datadog's malicious packages dataset. Each of these packages were found in the wild and confirmed to be malicious. The goal of this analysis is to understand the nature of malicious OSS packages and how they are distributed in the wild.

Analysis of malicious open source packages from Datadog's malicious packages dataset. Each of these packages were found in the wild and confirmed to be malicious. The goal of this analysis is to understand the nature of malicious OSS packages and how they are distributed in the wild.

TL;DR

  • We analyzed a total of 5,576 open source packages from DataDog Malicious Packages Dataset.
  • 96.2% of the packages were detected as malicious by our code scanning engine.
  • 64% (3,611) were from npm and 35% (1,965) were from PyPI among the malicious packages.
  • 71.9% of the detections were with high confidence with multiple signals and evidence.
  • T1041 – Exfiltration Over C2 Channel was the most common TTP.
  • The top two behaviors were exfiltration via Burp Collaborator and pre-install command execution in NPM scripts.
  • 90% of the malicious packages were very small in size (< 10KB).
  • 44 clear typosquatting attempts on popular libraries (e.g. beautifulsoup‑numpy, djangoo).
  • 10 YARA rules matched > 75% of the malicious packages indicating common TTPs.

Key Findings at a Glance

TTPs

The Top 10 YARA rules that matched > 75% of the malicious packages are shown below. The rules were curated from the YARA Forge project. This is an indicator of most common TTPs used by malicious actors.

The burp_collab rule match is an indicator of attackers leveraging Burp Collaborator for exfiltration of data. In our past research, we identified multiple malicious packages that use Burp Collaborator for exfiltration of data.

The following table shows the MITRE ATT&CK mapping for the top behaviors.

BehaviorMITRE ATT&CK IDTactic
Burp Collaborator usageT1041 – Exfiltration Over C2 ChannelExfiltration
npm preinstall arbitrary execT1059 – Command and Script InterpreterExecution
System info harvestingT1082 – System Information DiscoveryDiscovery
External IP discovery (ipify.org)T1016.001 – Internet Connection DiscoveryDiscovery
Runtime phone home / beaconT1071.001 – Web Protocols (C2)Command and Control
Hardcoded host for exfiltrationT1567.002 – Exfiltration over Web ServiceExfiltration
setuptools custom command execT1059.006 – Command and Script Interpreter: PythonExecution
Hard‑coded IP callbacksT1071.001 – Web Protocols (C2)Command and Control
System info + uploadT1567.002 – Exfiltration over Web ServiceExfiltration
Sensitive file accessT1552.001 – Credentials in FilesCredential Access

Signals by File Extension

The distribution of file extensions that contributed to evidence (signals) based on which a package was classified as malicious are shown below.

Note: The JSON files are classified due to extensive use of npm install hooks in package.json files.

Size of Malicious Packages

Interestingly, the size of the malicious packages is very small with 90% of them being less than 10KB.

Typosquatting

Typosquatting is a technique used by attackers to trick users into installing malicious packages. In this technique, attackers create packages that are similar to popular packages but with a few characters changed. Below are the most common typosquatting attempts on popular libraries:

Typosquat NameTarget Package NameRegistryCount
expresssexpressnpm7
reqestsrequestsPyPI5
djangoodjangoPyPI4
lodashslodashnpm4
reactjsreactnpm3
beautifulsoup‑numpybeautifulsoup4 + numpy (combo bait)PyPI3
pandas3pandasPyPI3
flaskkflaskPyPI2
asynciooasyncioPyPI2
webpackjswebpacknpm2

Common patterns observed:

  • Double letters or missing letters (expresss, reqests, djangoo, flaskk) remain the easiest way attackers catch fat‑finger installs.
  • Version oriented bait (pandas3) and combo bait (beautifulsoup‑numpy) try to appear “new” or “feature‑rich.”

Dependency Confusion

Dependency Confusion Attacks were another most common technique observed in the dataset. Following are some of the examples based on unusually high version numbers:

Package NameVersion
32red-admin999.9.9
32red-analytics999.9.9
32red-api999.9.9
32red-api-client999.9.9
32red-auth999.9.9

While the examples are insufficient, the common observation is red teamers often use high version numbers in dependency confusion attempts to gain access to the target organization.

Background

We at SafeDep build and maintain a code analysis engine optimized for scanning open source packages for malicious code. This engine uses a hybrid approach consisting of:

  1. YARA Forge rules for detecting known malicious patterns
  2. Static code analysis for identifying code blocks that perform specific operations (e.g. network:connect, fs:write, process:exec etc.)
  3. LLM based code analysis for basic block of code that are potentially malicious based on [1] and [2]

We use this code analysis engine to continuously scan all open source packages published to supported registries such as npm, PyPI, RubyGems etc. Data from this analysis engine is used by vet, our free and open source supply chain security tool to protect users against malicious OSS packages in near realtime.

Evaluation Dataset

The LLM usage in the analysis workflow makes the overall system probabilistic due to the inherent nature of LLMs. To be able to maintain and improve quality of analysis, we needed an evaluation dataset. DataDog’s Malicious Packages Dataset was a right fit for our needs.

Methodology

The analysis was performed using the SafeDep Package Analysis engine with necessary customizations to support the analysis of malicious packages from zip files instead of analysing artifacts directly from package registries. The reason being, many of the malicious packages in the dataset are already removed from the package registries due to being malicious.

The following customizations were made:

  • Originally supports OSS package scanning directly from package registries
  • A custom script to extract zip files with infected password from input DataDog’s malicious packages dataset into local file system
  • A custom adapter to read package files from local file system
  • Scan the local packages using the SafeDep Package Analysis engine

While the scanning engine that we used is not open source at this time, anyone can use it with vet, our free and open source supply chain security tool. Developers can build custom tools using the Package Analysis API.

Conclusion

While the goal of this analysis was to evaluate and create a benchmark for our code analysis engine, the results are useful for the community to understand the nature of malicious open source packages and how they are distributed in the wild. In fact, this analysis helps us fine tune our analysis engine to be more accurate and reduce false positives. Interested readers can use the data for their own analysis and research.

  • vet integrates with the analysis API to protect against malicious OSS packages in CI/CD pipelines.
  • Documentation on how to use malicious package analysis service
  • vetpkg.dev/mal is an example app built to show most recently analyzed OSS packages
Back to Blog

Related Posts

View All Posts »