Dozens of Machines Infected: Year-Long NPM Supply Chain Attack Combines Crypto Mining and Data Theft

Through our continuous monitoring of software supply chain threats, the Checkmarx Research team identified a supply chain attack that has remained active for over a year. The package, @0xengine/xmlrpc, began its life as a “legitimate” XML-RPC implementation in October 2023, but strategically transformed into a malicious tool in later versions and has remained active through November of 2024. This discovery serves as a stark reminder that a package’s longevity and consistent maintenance history do not guarantee its safety. Whether initially malicious packages or legitimate ones becoming compromised through updates, the software supply chain requires constant vigilance — both during initial vetting and throughout a package’s lifecycle.

Key Findings

• A malicious NPM package masquerading as an XML-RPC implementation has maintained an unusually long presence on the NPM registry from October 2023 to November 2024, receiving 16 updates during this period.
• The package started as a “legitimate” XML-RPC implementation and strategically introduced malicious code in later versions.
• The malware steals sensitive data (SSH keys, bash history, etc..) every 12 hours while mining cryptocurrency on infected systems. Data is exfiltrated through Dropbox and file.io.
• The attack achieved distribution through multiple vectors: direct NPM installation and as a hidden dependency in a legitimate-looking repository.
• Evasion techniques include system monitoring detection and activity-based mining
• At the time of investigation, it appeared that up to 68 compromised systems were actively mining cryptocurrency through the attacker’s Monero wallet.

Package History and Evolution

The malicious package “@0xengine/xmlrpc” first appeared on the NPM registry on October 2nd, 2023, presenting itself as a pure JavaScript XML-RPC server and client implementation for Node.js.

What makes this package particularly interesting is its strategic evolution from legitimate to malicious code. The initial release (version 1.3.2) and its immediate follow-up appeared to be legitimate implementations of XML-RPC functionality. However, starting from version 1.3.4, the package underwent a significant transformation with the introduction of malicious code in the form of heavily obfuscated code within the “validator.js” file.

Over its year-long presence on NPM, the package has received 16 updates, with the latest version (1.3.18) published on October 4th, 2024. This consistent update pattern helped maintain an appearance of legitimate maintenance while concealing the malicious functionality.

Distribution Strategy

Our research uncovered a calculated supply chain attack involving two distribution vectors. The first involves direct installation of @0xengine/xmlrpc from NPM. The second, more sophisticated approach, involves a GitHub repository named “yawpp” (hxxps[:]//github[.]com/hpc20235/yawpp), which presents itself as a WordPress posting tool.

The yawpp repository appears legitimate, offering functionality for WordPress credential checking and content posting. It requires @0xengine/xmlrpc as a dependency, claiming to use it for XML-RPC communication with WordPress sites. This dependency is automatically installed when users set up the yawpp tool through standard npm installation.

This strategy is particularly effective as it exploits the trust developers place in package dependencies, potentially leading to inadvertent installation of the malicious package through what appears to be a legitimate project dependency.

The combination of regular updates, seemingly legitimate functionality, and strategic dependency placement has contributed to the package’s unusual longevity in the NPM ecosystem, far exceeding the typical lifespan of malicious packages that are often detected and removed within days.

Attack Flow

The attack orchestrated through @0xengine/xmlrpc operates through a sophisticated multi-stage approach that combines cryptocurrency mining with data exfiltration capabilities. The malicious functionality, concealed within validator.js, remains dormant until executed through one of two vectors:

• Direct package users execute any command with the ‘ — targets’ or ‘-t’ flag. This activation occurs when running the package’s validator functionality, which masquerades as an XML-RPC parameter validation feature.
• Users installing the “yawpp” WordPress tool from GitHub automatically receive the malicious package as a dependency. The malware activates when running either of yawpp’s main scripts (checker.js or poster.js), as both require the ‘ — targets’ parameter for normal operation.

This implementation ensures the malware activates through legitimate-looking tool usage, making detection more difficult.

Initial Compromise

Once triggered, the malware begins gathering system information:

Following the initial data collection phase, the malware deploys its cryptocurrency mining component with a particular focus on Linux systems. The deployment process involves downloading additional payloads from a Codeberg repository disguised as system authentication services. The mining operation utilizes XMRig to mine Monero cryptocurrency, directing all mining rewards to a predetermined wallet address while connecting to the mining pool.

These downloaded components include:

• XMRig: The actual cryptocurrency mining software
• xprintidle: Used to detect user activity
• Xsession.sh: The main script that orchestrates the mining operation

The mining operation is configured with specific parameters targeting Monero:

At the time of our investigation, we observed 68 miners actively connected to this wallet address through the hashvault.pro mining pool, indicating a possible significant number of compromised systems actively mining cryptocurrency for the attacker.

Sophisticated Evasion Mechanisms

The malware implements an advanced process monitoring system to avoid detection. It maintains a list of monitoring tools and continuously checks for their presence.

The malware also carefully monitors user activity through the xprintidle utility. It only initiates mining operations after a specified period of inactivity (default: 1 minute) and immediately suspends operations when user activity is detected. This behavior is controlled by the INACTIVITY_IN_MINS parameter.

Maintaining Persistence

To ensure long-term survival on infected systems, the malware establishes persistence through systemd, disguising itself as a legitimate session authentication service named “Xsession.auth”. This service is configured to automatically start with the system, ensuring the mining operation resumes after system reboots. The malware also implements a daily check-in mechanism, regularly sending system status updates and potentially receiving new commands or configurations.

Data Exfiltration Pipeline

The malware implements a comprehensive data collection and exfiltration system that operates continuously. Every 12 hours, it performs a systematic collection of sensitive system information through a “daily_tasks” function found in Xsession.sh:

During each collection cycle, the malware systematically gathers a wide range of sensitive data including:

• SSH keys and configurations from ~/.ssh
• Command history from ~/.bash_history
• System information and configurations
• Environment variables and user data
• Network and IP information through ipinfo.io

The stolen data is exfiltrated through two channels. One, using the Dropbox API with hardcoded credentials.

Additionally, the malware employs file.io as a secondary exfiltration channel, using a bearer token for authentication and setting automatic file deletion after download to minimize detection risks.

Conclusion

This year-long campaign serves as a stark reminder of the critical importance of thoroughly vetting open-source projects before incorporation into any software development process. Projects can be malicious from the start, maintaining a long-term presence while hiding their true nature, or legitimate projects can later become compromised and introduce malicious code through updates.

This dual threat emphasizes why developers and organizations must remain vigilant not only during initial vetting but also in monitoring package updates, implementing robust security measures, and conducting regular audits of their dependencies to mitigate the risks associated with supply chain attacks.

As part of the Checkmarx Supply Chain Security solution, our research team continuously monitors suspicious activities in the open-source software ecosystem. We track and flag “signals” that may indicate foul play, including suspicious entry points, and promptly alert our customers to help protect them from potential threats.

Checkmarx One customers are protected from this attack.

Packages

- @0xengine/xmlrpc

IOC

• hxxps[:]//codeberg[.]org/k0rn66/xmrdropper/raw/branch/master/xprintidle
• hxxps[:]//codeberg[.]org/k0rn66/xmrdropper/raw/branch/master/xmrig
• hxxps[:]//codeberg[.]org/k0rn66/xmrdropper/raw/branch/master/Xsession.sh
• Wallet Address: 45J3v3ooxT335ENFjJBB3s7WS7xGekEKiBW4Z6sRSTUa5Kbn8fbqwgC47SLUDdKsri7haj7PBi5Wvf3xLmrX9CEZ3MGEVJU

Dozens of Machines Infected: Year-Long NPM Supply Chain Attack Combines Crypto Mining and Data… was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.

October 2024 heralded a new chapter in supply chain security challenges, characterized by innovative attack techniques and cryptocurrency-focused threats. A groundbreaking entry point exploitation technique affecting multiple package ecosystems was unveiled, while the NPM ecosystem witnessed the first-ever use of Ethereum smart contracts for malware C2 infrastructure. The month also saw multiple sophisticated attacks on cryptocurrency wallets through PyPI packages and a notable compromise of the popular lottie-player package, despite 2FA protections, highlighting the increasing complexity of supply chain security threats.

Let’s delve into some of the most striking events of October:

This New Supply Chain Attack Technique Can Trojanize All Your CLI Commands

A new supply chain attack technique exploits entry points in various programming ecosystems, allowing attackers to trojanize CLI commands. This stealthy method poses risks to developers and enterprises, bypassing traditional security checks. (Link to report).

With 2FA Enabled: NPM Package lottie-player Taken Over by Attackers

NPM package lottie-player compromised via leaked automation token, bypassing 2FA. Malicious versions injected code to trick users into connecting crypto wallets. Swift response: safe version released, compromised versions unpublished. (Link to report).

Crypto-Stealing Code Lurking in Python Package Dependencies

A sophisticated cyber attack on PyPI targeted cryptocurrency wallets through malicious packages. The attack used deceptive strategies, distributed malicious code across dependencies, and only activated when specific functions were called, making detection challenging. (Link to report).

Cryptocurrency Enthusiasts Targeted in Multi-Vector Supply Chain Attack

A malicious PyPI package “cryptoaitools” targeted cryptocurrency enthusiasts through a multi-vector supply chain attack. It used deceptive GUI, multi-stage infection, and comprehensive data exfiltration to steal crypto-related information from Windows and macOS users. (Link to report).

Supply Chain Attack Using Ethereum Smart Contracts to Distribute Multi-Platform Malware

A sophisticated NPM supply chain attack uses Ethereum smart contracts for C2 distribution. The cross-platform malware, targeting popular testing packages, affects Windows, Linux, and macOS through Typosquatting and preinstall scripts. (Link to report)

Our team will continue to hunt, squash attacks, and remove malicious packages in our effort to keep the open-source ecosystem safe.

I encourage you to stay up to date with the latest trends and tactics in software supply chain security by tuning into our future posts and learning how to defend against potential threats.

Stay tuned…

Working to Keep the Open Source Ecosystem Safe

October 2024 in Software Supply Chain Security was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.

Cryptocurrency enthusiasts have been the target of another sophisticated and invasive malware campaign. This campaign was orchestrated through multiple attack vectors, including a malicious Python package named “cryptoaitools” on PyPI and deceptive GitHub repositories. This multi-stage malware, masquerading as a suite of cryptocurrency trading tools, aims to steal a wide range of sensitive data and drain victims’ crypto wallets.

Key Findings

• A malicious package “cryptoaitools” was uploaded to PyPI, impersonating legitimate cryptocurrency trading tools, complete with a seemingly functional trading bot implementation.
• The malware activated automatically upon installation, targeting both Windows and macOS operating systems.
• The attacker also distributed the malware through GitHub repositories, expanding the attack surface.
• A deceptive graphical user interface (GUI) was used to distract victims while the malware performed its malicious activities in the background.
• The malware employed a multi-stage infection process, utilizing a fake website that appeared legitimate to host and deliver second-stage payloads.
• The malware displayed extensive data theft capabilities focused on cryptocurrency-related information, including wallet data, browser data, and sensitive system files.

Attack Flow

Initial Infection Vector

The CryptoAITools malware campaign began with the upload of a malicious package named “cryptoaitools” to PyPI. This package contained code for a seemingly legitimate cryptocurrency trading bot, including functions for automated trading on DEXs, price monitoring, and liquidity management. This legitimate-looking code served to disguise the malware’s true nature.

The malware activates automatically upon installation through the package’s __init__.py file. This file imports and executes the run_base() function from base.py:

The run_base() function determines the victim’s operating system and executes the appropriate malware variant:

The malware employs platform-specific helper functions to execute different versions for Windows and macOS systems. While the Windows version (basec_helper.py) is less obfuscated, the macOS variant (base_helper.py) is more heavily disguised. Despite these differences, both versions perform similar malicious activities, including data theft and cryptocurrency-related operations. These helper functions are responsible for downloading and executing additional malicious payloads, thus initiating subsequent stages of the attack.

Multi-Stage Infection Process

The CryptoAITools malware employs a sophisticated multi-stage infection process, leveraging a fake website to deliver its secondary payloads.

After the initial infection via the PyPI package, the malware’s second stage begins with the execution of base_helper.py (for macOS) or basec_helper.py (for Windows). These scripts are responsible for downloading additional malicious components from a deceptive website.

The malware uses a domain that appears legitimate: https://coinsw.app. This domain hosts a convincing appearance of a cryptocurrency trading bot service, complete with fake user reviews, subscriber counts, and detailed descriptions of AI-driven trading features. This elaborate disguise attempts to add credibility if a curious user investigates the domain.

The helper script decodes a base64-encoded URL and a list of filenames:

It then downloads these files from the fake website.

These downloaded files constitute the secondary payloads, expanding the malware’s capabilities. Notable among these is MHTBot.py, which is executed immediately after download (For MAC a different set of files are downloaded and the main.py file is then executed immediately after download)

This multi-stage approach allows the malware to:

• Maintain a small initial footprint in the PyPI package
• Evade detection during the initial installation
• Flexibly update and expand its capabilities post-infection
• Use a legitimate-looking website as a hosting platform for malicious payloads

Deceptive GUI

A unique aspect of this attack, compared to many malicious packages we have seen in the past, is that the CryptoAITools malware incorporates a graphical user interface (GUI) as a key component of its social engineering strategy. This GUI appears the moment the second-stage malware is activated and presents itself as an “AI Bot Starter” application. It is designed to distract users and collect sensitive information while the malware operates covertly. The interface’s role is straightforward: it begins by prompting users to create a password “to start using the bot securely.” Once a new password is added, a fake setup process is displayed, featuring a progress bar and loading animations. While users are engaged and focused on this seemingly legitimate interface and its fake setup process, the malware continues its malicious operations in the background, including data theft and system manipulation.

Data Heist

The CryptoAITools malware conducts an extensive data theft operation, targeting a wide range of sensitive information on the infected system. The primary goal is to gather any data that could aid the attacker in stealing cryptocurrency assets. The malware’s data collection capabilities are implemented across several modules, each focusing on specific types of data or system areas.

Types of Data Targeted

• Cryptocurrency wallet data from various applications (Bitcoin, Ethereum, Exodus, Atomic, Electrum, etc.)
• Browser data: saved passwords, cookies, and browsing history
• Data from a wide range of browser extensions related to cryptocurrency
• Sensitive system files, including SSH keys and configuration files
• Files from user directories (Downloads, Documents, Desktop) containing keywords related to cryptocurrencies, passwords, and financial information
• Telegram application data, including configuration files and message databases
• System terminal history
• Data from Apple Notes and Stickies applications on macOS systems

Data Exfiltration Method

The malware’s exfiltration process begins with the collected data stored in a hidden .temp directory in the user’s home folder. For each file, the exfiltration script changes the file extension to ‘.minecraft’. It then uploads the file to gofile.io using their API. Upon successful upload, gofile.io returns a download link, which is then sent to a Telegram bot of the attacker. After transmission, the local copy of the exfiltrated file is deleted. The process also includes error handling to prevent disruptions to the malware’s operation.

The Attacker

Our continued investigation into this campaign revealed the attacker was employing multiple infection vectors and social engineering tactics. The attack is not limited to the malicious Python package on PyPI, but extends to other platforms and methods:

1. PyPI Package: The initial discovery of the malicious “cryptoaitools” package on PyPI.
2. GitHub Repository: The attacker also distributes the malware through a GitHub repository named “Meme-Token-Hunter-Bot”. This repository contains similar malicious code, potentially infecting users who clone and run the code directly from GitHub.
3. Fake Website: The attacker operates a fake website at https://coinsw.app/, which mimics a legitimate cryptocurrency trading bot service.
4. Telegram Channel: The website’s “Buy” page leads to a Telegram chat named “Pancakeswap prediction bot”, where the attacker directly engages with potential victims.

In the Telegram chat, the attacker employs various tactics to lure potential victims. They offer “bot support” to establish credibility and trust. To entice users, they promote their GitHub repository as hosting their “most powerful bot,” appealing to those seeking advanced trading tools. The attacker then proposes an attractive offer: a free trial period followed by a monthly subscription model, making the proposition seem both risk-free and professional. To further personalize the experience and maintain ongoing engagement, they offer customized configuration options and continuous support, which creates a facade of a legitimate, customer-focused service.

This multi-platform approach allows the attacker to cast a wide net, potentially reaching victims who might be cautious about one platform but trust another.

Analysis of the GitHub repository interactions suggests that the scope of the attack may be larger than initially thought. Users who have starred or forked the malicious repository could potentially be victims, though further investigation would be needed to confirm this.

Impact

The CryptoAITools malware campaign has severe consequences for victims and the broader cryptocurrency community. Individuals face immediate financial losses through cryptocurrency theft, along with long-term risks of identity theft and privacy breaches due to extensive data exfiltration.

The true scope of the attack may be larger than initially thought, particularly given the GitHub repository interactions. Users who starred or forked the malicious “Meme-Token-Hunter-Bot” repository are potential victims, significantly expanding the attack’s reach.

On a larger scale, this attack erodes trust in cryptocurrency tools and platforms, potentially slowing adoption and innovation in the cryptocurrency space.

Conclusion

This cryptobot malware serves as a potent reminder that the stakes — and the risks — are high in the world of cryptocurrency. As digital assets continue to gain value and popularity, we can expect to see more sophisticated threats targeting this space.

As part of the Checkmarx Supply Chain Security solution, our research team continuously monitors suspicious activities in the open-source software ecosystem. We track and flag “signals” that may indicate foul play, including suspicious entry points, and promptly alert our customers to help protect them from potential threats.

Packages

• cryptoaitools

IOC

• hxxps[:]//coinsw[.]app/basecw/main[.]py
• hxxps[:]//coinsw[.]app/basecw/upd[.]py
• hxxps[:]//coinsw[.]app/basec/loading[.]gif
• hxxps[:]//coinsw[.]app/basecw/tad[.]py
• hxxps[:]//coinsw[.]app/basecw/ciz[.]py
• hxxps[:]//coinsw[.]app/basecw/ps[.]py
• hxxps[:]//coinsw[.]app/basecw/cat_dance[.]gif
• hxxps[:]//api[.]telegram[.]org/bot7337910559:AAF3fBlgDrcT9R07QpnqUWQ7_eKmnD_1QMc/sendMessage
• hxxps[:]//coinsw[.]app/basecw/firstpage[.]py
• hxxps[:]//tryenom[.]com/active-addon/nkbihfbeogaeaoehlefnkodbefgpgknn/bulo[.]php?pass=
• hxxps[:]//coinsw[.]app/basec/tx[.]py
• hxxps[:]//coinsw[.]app/basec/AiBotPro[.]py
• hxxps[:]//coinsw[.]app/basec/tg[.]py
• hxxps[:]//coinsw[.]app/basecw/security[.]py
• hxxps[:]//coinsw[.]app/basec/password_creation[.]py
• hxxps[:]//coinsw[.]app/basec/MHTBot[.]py
• hxxps[:]//coinsw[.]app/basec/one[.]py
• hxxps[:]//coinsw[.]app/basec/ArbitrageBot[.]py
• hxxps[:]//coinsw[.]app/basec/ph[.]py
• hxxps[:]//coinsw[.]app/basecw/ss[.]py
• hxxps[:]//coinsw[.]app/basecw/ara[.]py
• hxxps[:]//coinsw[.]app/basecw/cat[.]py
• hxxps[:]//coinsw[.]app/basecw/cf[.]py
• hxxps[:]//coinsw[.]app/basecw/local[.]py
• hxxps[:]//coinsw[.]app/basec/updel[.]py
• hxxps[:]//coinsw[.]app/basec/password_creation_advanced[.]py
• hxxps[:]//coinsw[.]app/basec/addonal[.]py
• hxxps[:]//coinsw[.]app
• hxxps[:]//github[.]com/CryptoAiBots

Cryptocurrency Enthusiasts Targeted in Multi-Vector Supply Chain Attack was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.

The open source ecosystem, due to its widespread adoption, has become a prime target for supply chain attacks. Malicious actors often exploit built-in features of open source packages to automatically distribute and execute harmful code. They particularly favor two techniques: Automatic, preinstall scripts that execute upon package installation, and seemingly innocent packages that import malicious dependencies.

As these tactics have become more recognizable, current security tools and vigilant developers have improved at detecting them quickly. However, an often overlooked yet potentially dangerous feature remains: Entry points.

This blog post explores how attackers can leverage entry points across multiple programming ecosystems with an emphasis on Pypi to trick victims into running malicious code. While this method doesn’t allow for immediate system compromise like automatic scripts or malicious dependencies, it offers a subtler approach for patient attackers to infiltrate systems, potentially evading standard security measures.

By understanding this lesser-known vector, we can better defend against the evolving landscape of Open source supply chain attacks.

Key Points

• Entry points, a powerful feature for exposing package functionality, are vulnerable to exploitation across various ecosystems including PyPI (Python), npm (JavaScript), Ruby Gems, NuGet (.NET), Dart Pub, and Rust Crates.
• Attackers can leverage these entry points to execute malicious code when specific commands are run, posing a widespread risk in the open-source landscape.
• Attack methods include command-jacking — impersonating popular third-party tools and system commands — and targeting various stages of the development process through malicious plugins and extensions. Each approach carries varying levels of potential success and detection risk.
• Entry point attacks, while requiring user interaction, offer attackers a more stealthy and persistent method of compromising systems, potentially bypassing traditional security checks.
• This attack vector poses risks to both individual developers and enterprises, highlighting the need for more comprehensive Python package security measures.

Understanding Python Entry Points

Entry points are a powerful feature of the packaging system that allows developers to expose specific functionality as a cli command without requiring users to know the exact import path or structure of the package.

Entry points serve several purposes which include:

• Creating command-line scripts that users can run after installing a package.
• Defining plugin systems where third-party packages can extend the functionality of a core package.

The most popular kind of entry point is console_scripts, which points to a function that you want to be made available as a command-line tool to whoever installs your package.

While primarily designed to enhance modularity and plugin systems, entry points can, if misused, become a vector for malicious actors to embed and execute harmful code. To understand how attackers can leverage Python entry points in their favor, let’s first understand how entry points were originally meant to work.

How Entry Points are Defined in Package Metadata

The location and format of entry point definitions can vary depending on the package format (wheel or source distribution).

Source Distributions (.tar.gz)

For source distributions, entry points are typically defined in a package’s setup configuration. This can be in setup.py, setup.cfg for traditional setups, or pyproject.toml for more modern packaging approaches.

Here’s an example of how entry points might be defined in setup.py:

Wheel Files (.whl)

In a wheel file, which is a built package format, entry points are defined in the entry_points.txt file within the .dist-info directory.

Here’s how the entry_points.txt file might look for the above example:

The syntax for entry points follows this pattern:

• name: The name of the entry point (e.g., the command name for console scripts)
• package.module: The Python module path
• object: The object (function, class, etc.) within the module to be used

In the above examples, my_command is a console script that will be created during installation. Anytime after the package installation, when a user types my_command in their terminal, it will execute the my_function from mypackage.module.

The plugin_name is a custom entry point that could be used by my_package to discover plugins. It points to PluginClass in my_package.plugins.

When a package is installed, these entry points are recorded in the package’s metadata. Other packages or tools can then query this metadata to discover and use the defined entry points.

If an attacker can manipulate a legitimate package’s metadata or convince a user to install a malicious package, they can potentially execute arbitrary code on the user’s system whenever the defined command or plugin is invoked. In the following section, I will provide multiple methods an attacker could use to trick someone into executing their malicious code through entry points.

Understanding CLI Commands in Operating Systems

Command-line interface (CLI) commands are the primary means by which users interact with an operating system through a text-based interface. These commands are interpreted and executed by the shell, which acts as an intermediary between the user and the operating system.

When a user enters a command, the shell follows a specific resolution mechanism to locate and execute the corresponding program. The exact order can vary slightly between different shells. However, the process typically begins by checking in order the directories listed in the PATH environment variable and runs the first matching executable it finds. Users can view their current PATH by entering the command “echo $PATH” in their terminal (the exact command will differ between operating systems), which displays the list of directories the shell searches for executables.

This resolution process ensures that when a user types a command, the appropriate action is taken. Understanding this process is crucial when considering how Python entry points, which can create new CLI commands, might interact with or potentially interfere with existing system commands.

How Attackers Can Abuse Entry Points to Execute Malicious Code

Malicious actors can exploit Python entry points in several ways to trick users into executing harmful code. We’ll explore a number of tactics, including Command-Jacking, Malicious Plugins and Malicious Extensions.

Command-Jacking

Impersonating Popular Third-Party Commands:

Malicious packages can use entry points to masquerade as widely-used third-party tools. This tactic is particularly effective against developers who frequently use these tools in their workflows.

For instance, an attacker might create a package with a malicious ‘aws’ entry point. When unsuspecting developers who regularly use AWS services install this package and later execute the aws command, the fake ‘aws’ command could exfiltrate their AWS access keys and secrets. This attack could be devastating in CI/CD environments, where AWS credentials are often stored for automated deployments — potentially giving the attacker access to entire cloud infrastructures.

Another example could be a malicious package impersonating the ‘docker’ command, targeting developers working with containerized applications. The fake ‘docker’ command might secretly send images or container specifications to the attacker’s server during builds or deployments. In a microservices architecture, this could expose sensitive service configurations or even lead to the exfiltration of proprietary container images.

Other popular third-party commands that could be potential targets for impersonation include but not limited to:

1. npm (Node.js package manager)
2. pip (Python package installer)
3. git (Version control system)
4. kubectl (Kubernetes command-line tool)
5. terraform (Infrastructure as Code tool)
6. gcloud (Google Cloud command-line interface)
7. heroku (Heroku command-line interface)
8. dotnet (Command-line interface for .NET Core)

Each of these commands is widely used in various development environments, making them attractive targets for attackers looking to maximize the impact of their malicious packages.

Impersonating System Commands:

By using common system command names as entry points, attackers can impersonate fundamental system utilities. Commands like ‘touch,’ ‘curl,’ ‘cd’, ‘ls’, and ‘mkdir’ just to name a few, could be hijacked, leading to severe security breaches when users attempt to use these fundamental tools.

While this method potentially provides the highest chances of the victim accidentally executing the malicious code, it also carries the highest risk of failure for the attacker. The success of this approach primarily depends on the PATH order. If the directory containing the malicious entry points appears earlier in the PATH than the system directories, the malicious command will be executed instead of the system command. This is more likely to occur in development environments where local package directories are prioritized.

Another thing to keep in mind is that globally installed packages (requiring root/admin privileges) might override system commands for all users, while user-installed packages would only affect that specific user’s environment.

Enhancing Attacks with Command Wrapping

In each of these Command-Jacking tactics, while it’s simpler for an attacker to merely override CLI commands, the chances of remaining undetected are quite low. The moment victims can’t execute a command, they’ll likely become suspicious immediately. However, these attacks can be made much more effective and stealthy through a technique called “command wrapping.” Instead of simply replacing a command, wrapping involves creating an entry point that acts as a wrapper around the original command. Here’s how it works:

1. The malicious entry point is triggered when the user calls the command (whether it’s an impersonated third-party tool or an attempt to impersonate a system command).
2. In addition to silently executing the attacker’s malicious code, it calls the original, legitimate command with all the user’s arguments.
3. Finally, it returns the output and exit code of the legitimate command to the user.

This method of command wrapping is particularly dangerous as it executes malicious code without the user’s knowledge while maintaining the appearance of normal operation. Since the legitimate command still runs and its output and behavior are preserved, there’s no immediate sign of compromise, making the attack extremely difficult to detect through normal use. This stealthy approach allows attackers to maintain long-term access and potentially exfiltrate sensitive information without raising suspicion.

However, implementing command wrapping requires additional research by the attacker. They need to understand the correct paths for the targeted commands on different operating systems and account for potential errors in their code. This complexity increases with the diversity of systems the attack targets.

An alternative approach, depending on the command being hijacked, is for the malicious package to not only perform its covert operations but also replicate some or all of the functionality of the original command. Instead of calling the real command, the wrapper simulates its behavior. This method could further decrease suspicion, especially for simpler commands, but it requires more effort from the attacker to accurately mimic the original command’s behavior across various scenarios.

The success of these attacks ultimately depends on the malicious package being installed and its scripts directory being prioritized in the system’s PATH.

Malicious Plugins & Extensions

Another powerful technique for abusing entry points is through the creation of malicious plugins for popular Python tools and frameworks. This approach can be particularly dangerous as it targets the development and testing process itself.

Manipulating pytest:

As an example, let’s consider how an attacker might target pytest, a widely-used testing framework in the Python ecosystem. By creating a malicious pytest plugin, an attacker could potentially compromise the integrity of the entire testing process.

Here’s how such an attack could work:

1. The attacker creates a plugin that uses pytest’s entry point system to inject malicious code.
2. This plugin is distributed as a seemingly helpful testing utility.
3. Once installed, the plugin can manipulate various aspects of the testing process such as assertion handling.

The malicious plugin could then stealthily run malicious code in the background during testing. The malicious plugin could also override pytest’s assertion comparison, causing, for example, all equality checks to pass regardless of their actual values, leading to false positives in test results, allowing buggy or vulnerable code to pass quality checks unnoticed.

In the following video demonstration, we showcase how such a malicious plugin can target pytest’s assertion handling, allowing an attacker to manipulate test results without alerting the developers. In this example, a developer was attempting a simple test scan of a basic calculator package.

Manipulating Flake8:

Attackers can also target popular development tools, manipulating them to run malicious extensions. Flake8, a widely-used linting tool in the Python ecosystem, is one such example. Since Flake8 uses entry points to discover and load extensions, it becomes a potential target for malicious actors.

An attacker might exploit Flake8 by creating a malicious extension disguised as helpful linting rules. This extension would be defined as an entry point in the package’s setup configuration. For example, the setup file might specify an entry point named ‘MCH’, pointing to a malicious checker class within the package.

The malicious checker’s implementation could include functionality to perform harmful actions on the victim’s system, inject malicious “fixes” into the code, or manipulate linting results to hide or create issues. When a user runs Flake8 on their codebase, this malicious extension would activate, allowing the attacker to execute their harmful code.

This attack is particularly dangerous because linting tools often run on entire codebases, giving the attacker broad access to the source code. Moreover, the attack can be perpetrated through seemingly helpful linting rules, making it less likely to raise suspicion. It could serve as part of a larger supply chain attack to gather intelligence or introduce vulnerabilities into the target’s codebase.

Working around .whl File Limitations

Python wheels (.whl files) have become increasingly prevalent due to their performance benefits in package installation. However, they present a unique challenge for attackers

While both .tar.gz and .whl files may contain a setup.py file, .whl files don’t execute setup.py during installation. This characteristic has traditionally made it more difficult for attackers to achieve arbitrary code execution during the installation process when using .whl files.

However, the entry point attack method we’ve discussed provides a workaround for this limitation. By manipulating entry points, attackers can ensure their code is executed when specific commands are run, even if the package is distributed as a .whl file. This is particularly significant because when developers build a Python package using commands like “pip -m build”, newer pip versions automatically create both .tar.gz and .whl files. Additionally, pip prioritizes delivering the .whl file to users during installation

This shift in package format and installation behavior presents a new opportunity for attackers. Many security tools focus on analyzing execution of preinstall scripts during installation, which are typically associated with .tar.gz files. As a result, they may miss malicious code in packages distributed as .whl files, especially when the malicious behavior is triggered through entry points rather than immediate execution.

Entry Points in Other Ecosystems

While this blog primarily focuses on Python, the exploitation of entry points for malicious purposes extends beyond the Python ecosystem. Through our research, we have confirmed that this type of attack vector exists in several other major ecosystems, including:

npm (JavaScript), Ruby Gems, NuGet (.NET), Dart Pub, and Rust Crates, though the vulnerability may not be limited to these alone.

Understanding how entry points function across various programming languages and package managers is crucial for grasping the widespread nature of this potential security risk and for developing comprehensive defensive strategies.

Conclusion

Entry points, while a powerful and useful feature for legitimate package development, can also be manipulated to deliver malicious code across multiple programming ecosystems

Attackers could exploit this mechanism through various methods, including Command-Jacking and the creation of malicious plugins and extensions for popular development tools.

Moving forward, it’s crucial to develop comprehensive security measures that account for entry point exploitation. By understanding and addressing these risks, we can work towards a more secure Python packaging environment, safeguarding both individual developers and enterprise systems against sophisticated supply chain attacks.

As part of the Checkmarx Supply Chain Security solution, our research team continuously monitors suspicious activities in the open-source software ecosystem. We track and flag “signals” that may indicate foul play, including suspicious entry points, and promptly alert our customers to help protect them from potential threats.

This New Supply Chain Attack Technique Can Trojanize All Your CLI Commands was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.

On September 22nd, a new PyPI user orchestrated a wide-ranging attack by uploading multiple packages within a short timeframe. These packages, bearing names like “AtomicDecoderss,” “TrustDecoderss,” “WalletDecoderss,” and “ExodusDecodes,” masqueraded as legitimate tools for decoding and managing data from an array of popular cryptocurrency wallets.

The attack targeted users of Atomic, Trust Wallet, Metamask, Ronin, TronLink, Exodus, and other prominent wallets in the crypto ecosystem. Presenting themselves as utilities for extracting mnemonic phrases and decrypting wallet data, these packages appeared to offer valuable functionality for cryptocurrency users engaged in wallet recovery or management. However, behind the scenes, these packages would fetch malicious code from dependencies to covertly steal sensitive cryptocurrency wallet data, including private keys and mnemonic phrases, potentially granting the attackers full access to victims’ funds.

This strategic use of dependencies allowed the main packages to appear harmless while harboring malicious intent in their underlying components.

Key Findings

• On September 22nd, multiple packages were published to the PyPI platform, targeting a wide range of crypto wallets including Atomic, Trust Wallet, Metamask, Ronin, TronLink, and Exodus.
• The malicious packages distributed their code across dependencies, making detection more challenging. This approach separated the seemingly benign main package from its harmful components.
• Unlike most malicious packages we’ve seen, these packages activate only when specific functions are called, not automatically upon installation.
• The malware’s capabilities include theft of private keys, mnemonic phrases, and other sensitive wallet data.
• The attack exploits the trust in open-source communities and the apparent utility of wallet management tools, potentially affecting a broad spectrum of cryptocurrency users.

A Web of Deception

The attacker behind this campaign implemented a multi-faceted strategy to disguise their intent and maximize the download count of their packages. This approach combined several deceptive techniques, each designed to exploit different aspects of user trust and package evaluation practices.

Deceptive Package Names and READMEs

Package names were carefully crafted to appeal to developers and users working with various wallet types. Names like “AtomicDecoderss,” “TrustDecoderss,” and “ExodusDecodes” mimicked legitimate tools.

Each package was accompanied by a professionally crafted README file, further enhancing its apparent legitimacy. These READMEs included detailed installation instructions, usage examples, and in one case, even “best practices” for virtual environments.

The attacker went a step further in their deception by including fake package statistics in the README files. At first glance, the packages displayed impressive stats, making them appear to be part of very popular and well-maintained projects. However, these were merely images creating an illusion of popularity and active development, further encouraging users to trust and download the package.

This level of detail and apparent popularity not only made the packages seem genuine but also significantly increased the likelihood of users implementing and running the malicious code.

Distributed Functionality Across Dependencies

Functionality was distributed across multiple dependencies within the packages themselves. Six of the malicious packages relied on a dependency called “cipherbcryptors,” which contained the core malicious code. Some packages further obfuscated their functionality by utilizing an additional dependency, “ccl_leveldbases.” This approach served dual purposes.

Firstly, it made the main packages appear more innocuous upon initial inspection, as they themselves contained little to no overtly malicious code.

Secondly, it significantly complicated the analysis process for security researchers and vigilant users. The full scope of each package’s capabilities wasn’t immediately apparent, requiring a deeper dive into the dependency chain to uncover the true nature of the code.

Obfuscation of Malicious Code

Within the “cipherbcryptors” package, where the heart of the malicious functionality resided, the code was heavily obfuscated. This obfuscation makes it challenging for automated security tools and human reviewers alike to quickly identify the package’s true intent.

Furthermore, the attacker employed an additional layer of security by not hardcoding the address of their command and control server within any of the packages. Instead, they used external resources to retrieve this information dynamically.

This technique not only makes static analysis of the code more difficult but also provides the attackers with the flexibility to change their infrastructure without needing to update the packages themselves.

By combining these various deceptive techniques — from package naming and detailed documentation to false popularity metrics and code obfuscation — the attacker created a sophisticated web of deception. This multi-layered approach significantly increased the chances of the malicious packages being downloaded and used, all while making detection and analysis more challenging.

Attack Flow

The execution of this attack diverged from the typical pattern seen in malicious packages. Rather than triggering malicious actions immediately upon installation, these packages lay dormant until specific functions were called. This approach significantly reduced the chances of detection by security tools that scan packages at installation time.

When a user attempted to use one of the advertised functions, the malicious code would activate. The process typically began with the package attempting to access the user’s cryptocurrency wallet data. For different wallet types, this involved targeting specific file locations or data structures known to contain sensitive information.

Once the wallet data was accessed, the malware would attempt to extract critical information such as private keys, mnemonic phrases, and potentially other sensitive data like transaction histories or wallet balances. This stolen data would then be prepared for exfiltration.

The exfiltration process involved encoding the stolen data and sending it to a remote server controlled by the attacker.

Impact

The consequences for victims could be severe and far-reaching. The most immediate and obvious impact is the potential for financial losses. With access to private keys and mnemonic phrases, attackers can swiftly drain cryptocurrency wallets. The irreversible nature of blockchain transactions means that once funds are stolen, recovery is nearly impossible. Beyond immediate financial theft, compromised wallet data can lead to ongoing vulnerability, as attackers may monitor and exploit the wallet over time.

The packages’ ability to fetch external code adds another layer of risk. This feature allows attackers to dynamically update and expand their malicious capabilities without updating the package itself. As a result, the impact could extend far beyond the initial theft, potentially introducing new threats or targeting additional assets over time.

Conclusion

This sophisticated supply chain attack on the Python ecosystem serves as another stark reminder of the ever-evolving threats in the open-source world. The cryptocurrency space, in particular, continues to be a prime target, with attackers constantly devising new and innovative methods to compromise valuable digital assets. This incident underscores the critical need for ongoing vigilance of the entire open-source community to remain alert and proactive in identifying and mitigating such threats. The attack’s complexity — from its deceptive packaging to its dynamic malicious capabilities and use of malicious dependencies — highlights the importance of comprehensive security measures and continuous monitoring.

As part of the Checkmarx Supply Chain Security solution, our research team continuously monitors suspicious activities in the open-source software ecosystem. We track and flag “signals” that may indicate foul play and promptly alert our customers to help protect them.

Checkmarx One customers are protected from this attack.

Packages

• atomicdecoderss
• trondecoderss
• phantomdecoderss
• trustdecoderss
• exodusdecoderss
• walletdecoderss
• ccl-localstoragerss
• exodushcates
• cipherbcryptors
• ccl_leveldbases

IOCs

• hxxps[:]//pastebin[.]com/raw/FZUp6ESH
• hxxps://decry[.]in/check

Crypto-Stealing Code Lurking in Python Package Dependencies was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.

For over a year, a persistent malware campaign has been targeting Roblox developers through malicious NPM packages. By mimicking the popular “noblox.js” library, attackers have published dozens of packages designed to steal sensitive data and compromise systems. This campaign exploits trust in the open-source ecosystem, particularly targeting the Roblox platform, an attractive target due to its massive user base of over 70 million daily active users. Despite multiple package takedowns, new malicious packages continue to appear on the NPM registry at the time of publication, requiring developers to remain vigilant against this ongoing threat.

Key Points

• Dozens of malicious npm packages mimicking the popular “noblox.js” library have been identified in a campaign dating back to August 2023, with the most recent ones appearing in late August 2024.
• The attackers of this campaign have employed techniques including brandjacking, combosquatting, and starjacking to create a convincing illusion of legitimacy for their malicious packages.
• The malware’s capabilities include Discord token theft, system information harvesting, system persistence, and deployment of additional payloads such as Quasar RAT.
• The malware employs a sophisticated persistence technique by manipulating the Windows registry, causing it to execute every time a user opens the Windows Settings app.
• While the identified malicious packages have been removed from npm, the attacker’s GitHub repository containing malicious executables remains active, posing a potential threat for future attacks.

Malware in Disguise: The Social Engineering Aspect

The attackers have employed a multi-faceted approach to craft an illusion of authenticity around their malicious packages.

One deceptive tactic combines brandjacking and combosquatting — two methods that fall under the broader category of typosquatting. This strategy creates the illusion that their packages are either extensions of or closely related to the legitimate “noblox.js” library.

For example: noblox.js-async, noblox.js-thread, and noblox.js-api.

Since libraries commonly have multiple versions or extensions for specific use cases, mimicking this naming pattern increases the likelihood that developers will install the attackers’ packages, assuming they’re official extensions of “noblox.js.”

Another tactic used is starjacking, a popular method attackers employ to fake their package stats. In this instance, the malicious packages were linked to the GitHub repository URL of the genuine “noblox.js” package. This tactic falsely inflates the perceived popularity and trustworthiness of the malicious packages.

The attackers also used tactics to disguise the malware within the package itself. They meticulously mimicked the structure of the legitimate “noblox.js” but introduced their malicious code in the “postinstall.js” file. They heavily obfuscated this code, even including nonsensical Chinese characters to deter easy analysis.

These combined techniques create a convincing façade of legitimacy, significantly increasing the chances of the malicious packages being installed and executed on developers’ systems. As reported in previous analyses by Socket, Stacklok and Reversinglabs, these tactics have been consistently employed and refined throughout the year-long campaign.

Attack Flow

The malicious code exploits NPM’s postinstall hook, ensuring automatic execution when the package is installed. This hook, designed for legitimate setup processes, becomes a gateway for running the obfuscated malware without the user’s knowledge or consent.

At first glance, the obfuscated code appears daunting and impenetrable. However, by simply using an online automated JavaScript deobfuscation tool, we were able to gain significant insight into the malicious code’s operation. This initial deobfuscation revealed the general steps the malware takes to achieve its objectives. Yet, the resulting code still contained confusing elements and required additional cleaning to fully comprehend its functionality. This process of incremental deobfuscation and analysis allowed us to piece together the complete attack flow, with its most notable details listed below.

Discord Token Theft

The malware searches for Discord authentication tokens in multiple locations.

The stolen tokens are then validated to ensure only active ones are exfiltrated.

Antivirus Evasion

The malware aggressively undermines the system’s security measures. It first targets Malwarebytes, attempting to stop its service if running. This is followed by a more comprehensive attack on Windows Defender: the script identifies all disk drives and adds them to Windows Defender’s exclusion list. This action effectively blinds Windows Defender to any file on the system. By disabling third-party antivirus and manipulating built-in Windows security, the malware creates an environment where it can operate freely, significantly increasing its potential for damage and persistence.

Additional Payload Deployment

The malware expands its capabilities by downloading two additional executables from the attacker’s GitHub repository. These files, “cmd.exe” and “Client-built.exe”, are fetched using base64-encoded URLs and saved to the “C:\WindowsApi” directory with randomized names. The malware uses a combination of “nodeapi_” prefix and a unique hexadecimal string, likely to help the malicious files blend in with legitimate system files.

Persistence Mechanism

To ensure long-term access, the malware manipulates a Windows registry key to ensure it runs consistently on the infected system.

Specifically, it adds the path of the downloaded “Client-built.exe” to the strategic registry location:

“HKCU\Software\Classes\ms-settings\Shell\Open\command”

By modifying this key, the malware hijacks legitimate Windows functionality. As a result, whenever a user attempts to open the Windows Settings app, the system inadvertently executes the malware instead.

Data Exfiltration

Throughout its execution, the malware collects various types of sensitive information from the infected system. This data is packaged and sent to the attacker’s command and control server using a Discord webhook.

QuasarRAT Deployment

The final stage involves deploying QuasarRAT, a remote access tool that gives the attacker extensive control over the infected system.

The Attacker

The second-stage malware originates from an active GitHub repository: https://github.com/aspdasdksa2/callback. As of this writing, the repository remains accessible and potentially in use for distributing malware through other packages. The repository, owned by user “aspdasdksa2”, contains multiple malicious executables. The repository’s continued existence and its content suggest ongoing malware development and distribution.

Previous malicious npm packages were found to be linked to a different repository of that user for their second stage, but that repository is no longer accessible.

Notably, the attacker maintains a second repository named “noblox-spoof”, which appears to house the latest malicious npm package content, directly referencing the target of this campaign.

The most recent malicious packages impersonating the popular noblox.js library (four packages published by user “bicholassancheck14” — noblox.js-async, noblox.js-threads, noblox.js-thread, and noblox.js-api) have been taken down after we promptly reported them to npm’s security team. While this is a positive development, it’s important to note that the threat is not entirely neutralized.

We strongly advise the developer community to remain vigilant. The attacker’s continued infrastructure presence and persistence pose an ongoing threat. Developers should exercise caution, particularly when working with packages that resemble popular libraries like noblox.js.

Conclusion

This malware campaign, targeting Roblox developers through npm packages, has persisted for over a year. By mimicking the popular “noblox.js” library, attackers published dozens of malicious packages designed to steal sensitive data and compromise systems.

Central to the malware’s effectiveness is its approach to persistence, leveraging the Windows Settings app to ensure sustained access.

The discovery of these malicious NPM packages serves as a stark reminder of the persistent threats facing the developer community. By masquerading as legitimate, helpful libraries, attackers continue to find new ways to exploit trust within the open-source ecosystem.

This campaign underscores the critical importance of thoroughly vetting packages before incorporation into projects. Developers must remain vigilant, verifying the authenticity of packages, especially those resembling popular libraries, to protect themselves and their users from such sophisticated supply chain attacks.

As part of the Checkmarx Supply Chain Security solution, our research team continuously monitors suspicious activities in the open-source software ecosystem. We track and flag “signals” that may indicate foul play and promptly alert our customers to help protect them.

Checkmarx One customers are protected from this attack.

Packages

• noblox.js-async
• noblox.js-thread
• noblox.js-api
• noblox.js-threads

IOC

• hxxps[:]//github[.]com/aspdasdksa2/callback/raw/main/Client-built.exe
• hxxps[:]//github[.]com/aspdasdksa2/callback/raw/main/cmd.exe
• hxxps[:]//discord[.]com/api/webhooks/1273489016658071624/HWeSPo3qKIbUbqkwiWNoTneHoqo70s5aAYf9NBkAxoICy1SBMezf9ka22Ry59WK1kwYk

Year-Long Campaign of Malicious npm Packages Targeting Roblox Users was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.

July 2024 saw a surge in reports from multiple security firms detailing North Korean threat actors targeting developers through malicious npm packages. These reports highlight the continuation and intensification of a campaign that has been ongoing for close to a year now. While the core structure of the malicious code has remained remarkably similar throughout the campaign, the threat actors have been consistently evolving their social engineering tactics to increase their chances of compromising target systems.

Key Points

• Multiple security firms reported North Korean threat actors publishing malicious npm packages throughout July 2024, indicating an intensification of an ongoing campaign.
• Despite the campaign’s year-long duration, the structure of the malicious code within the packages has remained notably consistent.
• The latest tactic involves mimicking trusted and popular npm packages with added malicious functionality, to make the package appear more legitimate and challenging to detect.
• Our research team is actively tracking additional undisclosed packages linked to this campaign.

The campaign by North Korean threat actors to target developers through malicious npm packages has been ongoing since at least September 2023.

However, July 2024 saw an uptick in activity and subsequent reports from security firms including Phylum, Stacklok, and Datadog. These reports, along with our own ongoing research, provide a comprehensive view of the threat landscape and the persistent nature of this campaign.

Throughout the year-long campaign, North Korean threat actors have consistently published malicious packages on the npm registry.

Typically, when packages are removed by npm, they retain a placeholder on the registry containing the package’s name.

These NK malicious packages are often live for only a short period, sometimes just a few hours, before being unpublished by the attackers themselves. This swift self-removal appears to be a deliberate tactic to evade detection and potential removal by npm’s security measures. Notably, because the attackers unpublish the packages rather than having them removed by npm, no placeholder containing the package’s name is retained in the registry. This means that security researchers and developers searching for these packages on the npm registry will find no mention of them, effectively erasing their malicious history

A key characteristic of this campaign has been the consistency in the structure of the malicious code within the packages.

Despite minor variations in file names, URLs, and decryption keys, the overall functionality and execution flow have remained largely unchanged. This consistency suggests that the attackers are relying on a proven technique, making only small modifications to evade detection.

While the malicious code structure has remained consistent, the social engineering tactics used to lure developers into downloading and installing these packages have continuously evolved. The threat actors have employed various methods, from creating fake job interviews to impersonating legitimate development workflows, each time adapting their approach to exploit the trust within the open-source community.

The typical execution flow of these packages includes checking the operating system (usually targeting Windows), downloading a file from a remote server, decrypting the file (often using XOR operation), executing the decrypted file (commonly using rundll32), and cleaning up traces of the attack.

In the most recent packages of this campaign the threat actors implemented an approach of mimicking legitimate packages by copying code from popular packages and then mixing malicious components into it. This tactic makes it more challenging to detect the malicious nature of the package at first glance.

CONCLUSION

The persistent and evolving campaign by North Korean threat actors targeting developers through malicious npm packages represents a significant and ongoing threat to the open-source ecosystem.

The surge of activity observed in July 2024 demonstrates that despite increased awareness and defensive measures, these actors remain undeterred and continue to adapt their tactics.

As part of the Checkmarx Supply Chain Security solution, our research team continuously monitors suspicious activities in the open-source software ecosystem. We track and flag “signals” that may indicate foul play and promptly alert our customers to help protect them.

Packages

• harthat-cookie
• next-react-notify
• harthat-chain
• harthat-hash
• harthat-api
• call-blockflow

IOC

• hxxps://cryptocopedia.com/explorer/search.asp?token=5032
• 142[.]111[.]77[.]196/user/user.asp?id=237596
• 142[.]111[.]77[.]196/user/user.asp?id=G6A822B
• 142[.]111[.]77[.]196/manage/manage.asp?id=745681
• 142[.]111[.]77[.]196/user/user.asp?id=518437

A Year-Long Campaign of North Korean Actors Targeting Developers via Malicious npm Packages was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tip of the Iceberg: Malicious Python Packages Reveal Extensive Cybercriminal Operation Based in Iraq

Recently, a series of malicious Python packages surfaced on PyPI, uploaded by a user named “dsfsdfds”. These packages contained a malicious script located within the __init__.py file.

Key Points

• Recently, malicious Python packages — uploaded to PyPI by user “dsfsdfds” — were found to be exfiltrating sensitive user data without consent, to a Telegram chat bot.
• The Telegram bot is linked to multiple cybercriminal operations based in Iraq. The bot has activity dating back to 2022 and contains over 90,000 messages, mostly in Arabic.
• The bot functions also as an underground marketplace offering social media manipulation services. It has been linked to financial theft and exploits victims by exfiltrating their data.
• Initially, the malicious packages incident, appeared isolated. However, it is part of a larger, sophisticated cybercriminal ecosystem, emphasizing the importance of thorough investigation and collaboration within the cybersecurity community.

Attack Flow

The malicious script follows a systematic approach to compromise the victim’s system and exfiltrate sensitive data. It begins by scanning the user’s file system and focusing on two specific locations: the root folder and the DCIM folder. The script searches for files during the scanning process, with extensions such as .py, .php, and .zip files, as well as photos with .png, .jpg, and .jpeg extensions.

Once identified, the script sends their file paths, along with the actual files and photos, to the attackers Telegram bot. This all occurs without the end-user’s knowledge or consent.

The following code snippet demonstrates the core functionality of the malicious script:

The inclusion of hardcoded sensitive information, such as the bot token and chat ID, allowed us to gain further valuable insights into the attacker’s infrastructure and operations.

Additional Insights

Further analysis of the Telegram bot to which the exfiltrated data was being sent uncovered additional findings.

The hardcoded “chat_id” and “bot_token” present in the malicious packages allowed us to gain direct access to the attacker’s Telegram bot and monitor its activities. This technique (outlined here) proved to be a valuable tool in understanding the scope and nature of the attack.

This Telegram bot exhibited a significant history of activity. It had records dating back to at least 2022 — long before the malicious packages were released on PyPI, and contained over 90,000 messages.

The messages were primarily in Arabic. Further investigation with GitHub’s “TeleTracker” revealed that the bot operator maintained numerous other bots and was likely based in Iraq.

Initially, the bot appeared to function as a typical underground marketplace, offering various illicit services such as: purchasing Telegram and Instagram views, followers, spam services, and discounted Netflix memberships.

However, upon further examination of the bot’s message history, we found evidence of more sinister activities that appeared to be involved in financial theft. Additional messages suggested they were sent from systems compromised by the harmful Python packages.

The discovery of this elaborate Telegram-based cybercriminal operation underscores the importance of thorough and persistent investigation when researching the true extent of such attacks. Especially since the initial malicious packages served as a mere entry point to a much larger criminal ecosystem.

CONCLUSION

The discovery of the malicious Python packages on PyPI and the subsequent investigation into the Telegram bot have shed light on a sophisticated and widespread cybercriminal operation. What initially appeared to be an isolated incident of malicious packages turned out to be just the tip of the iceberg, revealing a well-established criminal ecosystem based in Iraq.

This particular attack vector is not limited to end-users and can indeed impact enterprises as well. While the initial compromise might occur on an individual developer’s machine, the implications for enterprises can be significant. For instance, if a developer within an enterprise unknowingly uses a compromised package, it could introduce vulnerabilities into the company’s software projects.

As the fight against malicious actors in the open source ecosystem persists, collaboration and information sharing among the security community will be critical in identifying and stopping these attacks. Through collective effort and proactive measures, we can work towards a safer and more secure open source ecosystem for all. Our research team is continuously investigating this attack to gain additional insights into the attacker’s modus operandi and will share further findings with the community as they emerge.

As part of the Checkmarx Supply Chain Security solution, our research team continuously monitors suspicious activities in the open-source software ecosystem. We track and flag “signals” that may indicate foul play and promptly alert our customers to help protect them.

Checkmarx One customers are protected from this attack.

PACKAGES

• testbrojct2
• proxyfullscraper
• proxyalhttp
• proxyfullscrapers

Tip of the Iceberg: Malicious Python Packages Reveal Extensive Cybercriminal Operation Based in… was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.

In December 2023, we reported on how North Korean threat actors, particularly Jade Sleet, have been compromising supply chains through the open-source ecosystem, with one of their key tactics being the exploitation of the public npm registry to distribute malicious packages. Despite the increased exposure and attention brought to this issue by our research and that of others in the field, it is evident that these attackers remain undeterred.

Throughout the first and even second quarter of 2024, we observed the continued publication of malicious packages on NPM, bearing striking similarities to those detailed in our previous blog post. Initially, we believed these packages to be a continuation of Jade Sleet’s campaign in late spring and early summer of 2023. However, new information came to light, making it apparent that a new threat actor was emerging on the scene.

Key Points

• Moonstone Sleet, a newly identified North Korean threat actor, has entered the scene, targeting the open-source software supply chain with tactics similar to other well-known North Korean groups.
• Among Moonstone Sleet’s key tactics is the distribution of malware through malicious NPM packages, which are published on the public NPM registry, exposing a wide range of developers to potential compromise.
• The ongoing activities of Moonstone Sleet, Jade Sleet, and other North Korean state-sponsored actors underscore the constant threat to the open-source ecosystem.

Recent Developments:

In a recent publication, Microsoft shed light on a new rising North Korean threat actor named Moonstone Sleet, which employs various tactics, techniques, and procedures (TTPs) to target companies for financial gain and cyberespionage. With much of These TTPs utilized by Moonstone Sleet closely resemble those employed by other North Korean threat actors

A number of IOCs shared in Microsoft’s blog closely resemble those mentioned in our December blog post and recent publications by Phylum. showing that, in addition to delivering malicious npm packages through freelancing websites and platforms like LinkedIn, Moonstone Sleet has also been attempting to spread their malicious packages through the public npm registry.

This tactic allows them to potentially reach a wider audience and increases the likelihood of their malicious packages being installed by unsuspecting developers.

Differences in Code Style and Structure

The malicious npm packages discovered during the apring and early summer of 2023, affiliated with Jade Sleet, and those found in late 2023 to early 2024, containing IOCs linking them to the Moonstone Sleet group, exhibit distinct code style and structure differences. These differences offer interesting insights into the varying strategies used by different groups when targeting the open-source software supply chain.

Packages attributed to Jade Sleet

Jade Sleet’s packages, discovered throughout summer 2023, were designed to work in pairs, with each pair being published by a separate npm user account to distribute their malicious functionality. This approach was used in an attempt to make it more challenging to detect and trace the malicious activity back to a single source.

The first package in the pair was responsible for creating a directory on the victim’s machine, fetching updates from a remote server, and saving them in a file within the newly created directory. This package laid the groundwork for the second package to execute its malicious payload.

The second package, upon execution, would read a token from the file created by the first package. It would then make a request to a specific URL, passing the token as a parameter. The response from this request, likely containing additional malicious code, would be written to another file on the victim’s machine. Finally, the second package would immediately execute this newly written file as a Node.js script, unleashing the full extent of the malicious functionality.

Packages attributed to Moonstone Sleet

In contrast, the packages published throughout late 2023 and early 2024 adopted a more streamlined single-package approach which would execute its payload immediately upon installation.

The malicious payload was encoded within string constants and included OS-specific code, executing only if it detected that it was running on a Windows machine.

Packages published in the last quarter of 2023 and the first quarter of 2024 shared significant similarities, with only minor variations in file names, URLs, and decryption keys.

Despite these minor changes, the malicious payload’s overall structure and functionality remain largely the same, indicating that the attackers are relying on a proven technique while making small modifications to evade detection:

Malicious Payload Execution:

The malicious payload downloads a file from a remote server, decrypts it using a byte-wise XOR operation, renames the decrypted file, and executes it using rundll32. It then cleans up by deleting the temporary files and replacing the malicious package.json with a clean version.

Changes in the Attack Flow in Second Quarter of 2024
In the second quarter of 2024, the packages increased in complexity, with the attackers adding obfuscation and having it target Linux systems as well. The following code would be executed if the OS was detected as Linux:

For a more detailed explanation of how the various packages operate, you can refer to our past publications.

Blog post describing Jade Sleet — attributed packages.

Blog post describing the Moonstone Sleet — attributed packages

Conclusion

The frequent publication of malicious packages on npm by North Korean threat actors underscores the persistent nature of their campaign. By continually adapting their tactics and techniques, they aim to evade detection and enhance their odds of breaching targeted systems.

With the revelation of this new North Korean group, coupled with the recent attacks by Russian and North Korean threat actors and the recent high-profile XZ attack, it has become increasingly apparent that the open-source ecosystem has become a prime target for powerful and sophisticated adversaries. And while the open-source community plays a crucial role in maintaining the security and integrity of the ecosystem, the primary responsibility for ensuring the safety of the software supply chain lies with the companies that consume these packages.

As the fight against malicious actors in the open-source ecosystem persists, collaboration and information sharing among the security community will be critical in identifying and thwarting these attacks. Through collective effort and proactive measures, we can work towards a safer and more secure open-source ecosystem for all.

A New North Korean Group Emerges, Disrupting the Open Source Ecosystem was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.

Instant Breach: Malicious Package Compromise — Victim vs Attacker’s POV

Open-source packages are an indispensable tool for developers. However, the convenience they offer comes with a significant risk: the potential for instant breaches through malicious packages.

Consuming a malicious open-source package is equivalent to an instant breach. No current update strategy can match the speed at which these packages can compromise your systems.

In contrast to vulnerable packages, which pose a passive risk due to coding errors or oversights and only have potential impacts if exploited, malicious packages represent an active, immediate risk. They are designed with harmful intentions, such as stealing sensitive data and deploying backdoors and keyloggers, just to name a few.

Developers installing these malicious packages are often unaware that their systems have been compromised.

The following video demonstrates the simplicity of falling victim to a malicious package. In this example, the attacker infected the victim with a keylogger which automatically sends all keystrokes to the attacker via a webhook:

Unfortunately, current application security controls often focus on known Common Vulnerabilities and Exposures (CVEs). Since malicious packages very rarely receive CVEs, this leaves organizations vulnerable to attacks.

Even Endpoint Detection and Response (EDR) systems are unable to stop malicious package activity or send relevant alerts. Attackers are well aware of this weakness, which is why we are seeing a massive spike in targeted open-source supply chain attacks.

Conclusion

To fortify our defenses against these relentless cyber threats, our goal should be clear: prevent malicious packages from ever penetrating our Software Development Lifecycle (SDLC). The best approach is to screen open-source packages for malware before allowing them into the network.

By proactively addressing this risk, we can protect our systems and data from the instant breaches caused by malicious packages.

As part of the Checkmarx Supply Chain Security solution, our research team continuously monitors suspicious activities in the open-source software ecosystem. We track and flag “signals” that may indicate foul play and promptly alert our customers to help protect them.

Instant Breach: Malicious Package Compromise — Victim vs Attacker’s POV was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.

In a recent attack campaign, cybercriminals were discovered cleverly manipulating GitHub’s search functionality, and using meticulously crafted repositories to distribute malware.

Key points

• GitHub search manipulation: Attackers create malicious repositories with popular names and topics, using techniques like automated updates and fake stars to boost search rankings and deceive users.
• Malicious code is often hidden within Visual Studio project files (.csproj or .vcxproj) to evade detection, automatically executing when the project is built.
• The attacker had set up the stage to modify the payload based on the victim’s origin, checking specifically if the victim is based in Russia. At this point, we don’t see this ability activated.
• The recent malware campaign involves a large, padded executable file that shares similarities with the “Keyzetsu clipper” malware, targeting cryptocurrency wallets.
• The malware establishes persistence on infected Windows machines by creating a scheduled task that runs the malicious executable daily at 4AM without user confirmation.
• Developers should be cautious when using code from public repositories and watch for suspicious repository properties, such as high commit frequencies and stargazers with recently created accounts.

Exploiting GitHub’s Search Functionality:

Our recent findings reveal a threat actor creating GitHub repositories with names and topics that are likely to be searched by unsuspecting users. These repositories are cleverly disguised as legitimate projects, often related to popular games, cheats, or tools, making it difficult for users to distinguish them from benign code.

To ensure maximum visibility, the attackers employ a couple of clever techniques that consistently place their malicious repositories at the top of GitHub search results.

Automatic updates

By leveraging GitHub Actions, the attackers automatically update the repositories at a very high frequency by modifying a file, usually called “log”, with the current date and time or just some random small change. This continuous activity artificially boosts the repositories’ visibility, especially for instances where users filter their results by “most recently updated,” increasing the likelihood of unsuspecting users finding and accessing them.

Faking Popularity

While automatic updates help, the attackers combine another technique to amplify the effectiveness of their repo making it to the top results.

The attackers employed multiple fake accounts to add bogus stars, creating an illusion of popularity and trustworthiness. This artificially boosts the repositories’ visibility further, especially for instances where users filter their results by “most stars.”

In contrast to past incidents where attackers were found to add hundreds or thousands of stars to their repos, it appears that in these cases, the attackers opted for a more modest number of stars, probably to avoid raising suspicion with an exaggerated number.

This social engineering technique is designed to manipulate users into believing that the repository is widely used and reliable, preying on the inherent trust users place in highly-starred repositories.

Unsuspecting users, often drawn to the top search results and repositories with seemingly positive engagement, are more likely to click on these malicious repositories and use the code or tools they provide, unaware of the hidden dangers lurking within.

For a deeper dive into the tactic of fake stars, check out our recent blog that explores this manipulation technique in greater detail.

Hidden Malware in Project Files:

The attackers conceal their malware primarily as obfuscated code deep within the .csproj or .vcxproj files of the repository (files commonly used in Visual Studio projects) to decrease the chances of the average user detecting it unless they proactively search for suspicious elements.

However, it’s worth noting that there have been a small number of other detected repos that contained different malware within other files.

The malicious script is embedded within a pre-build event of a Visual Studio project file (.vcxproj) and is designed to be executed automatically during the build process. The script consists of two main parts:

1. A batch script that sets up the environment and executes a VBScript file.

2. A base64-encoded PowerShell script that is decoded and executed by the VBScript file.

The batch script creates a temporary directory, generates a VBScript file, and decodes the base64-encoded PowerShell script. It then executes the decoded PowerShell script and cleans up the temporary files.

The decoded PowerShell script performs the following malicious actions:

1. Retrieves the country code of the machine’s IP address, determining whether the machine is based in Russia.

2. Downloads content from specific URLs based on the country code (content is continuously updated by the attacker)

3. Downloads encrypted files from each URL, extracts them with a predefined password, and executes the extracted files.

The script also employs error handling to silently catch exceptions and continue execution.

Active Campaign

On April 3rd, the attacker updated the malicious code within one of their repositories, pointing to a new URL that downloads a different encrypted .7z file containing an executable named feedbackAPI.exe.

The attacker had padded the executable with many zeros, a technique used to artificially boost the file size. Due to this padding, the file size exceeded the threshold of many security solutions, VirusTotal being a notable one, preventing the possibility of it from being scanned. According to VirusTotal’s documentation,

“If the file to be uploaded is bigger than 32MB, please use the /private/files/upload_url endpoint instead which admits files up to 650MB.”

The padded feedbackAPI.exe file was 750MB in size, exceeding even the increased limit for the alternative endpoint.

The results of our analysis of this malware suggest that the malware contains similarities to the “Keyzetsu clipper” malware, a relatively new addition to the growing list of crypto wallet clippers commonly distributed through pirated software.

This executable file also attempts to create persistence on Windows machines. It achieves this by creating a shortcut to the exe file and then establishing a daily scheduled task named “Feedback_API_VS_Services_Client” that executes the shortcut at 4AM. Notably, this task is created without any confirmation prompts, making it stealthier and more likely to go unnoticed by unsuspecting users.

Indicators of Successful Exploitation

Evidence indicates that the attackers’ campaign has successfully deceived unsuspecting users. Numerous malicious repositories have received complaints through Issues and pull requests from users who experienced problems after downloading and using the code.

Conclusion:

The use of malicious GitHub repositories to distribute malware is an ongoing trend that poses a significant threat to the open-source ecosystem. By exploiting GitHub’s search functionality and manipulating repository properties, attackers can lure unsuspecting users into downloading and executing malicious code.

To prevent falling victim to similar attacks, it is recommended to keep an eye on the following suspicious properties of a repo:

1. Commit frequency: Does the repo have an extraordinary number of commits relative to its age? Are these commits changing the same file with very minor changes?

2. Stargazers: Who is starring this repo? Do most of the stargazers appear to have had accounts created around the same time?

By being aware of these red flags, users can better protect themselves from inadvertently downloading and executing malware.

In the aftermath of the XZ attack and many other recent incidents, it would be irresponsible for developers to rely solely on reputation as a metric when using open source code. A developer who blindly takes code also blindly takes responsibility for that code. These incidents highlight the necessity for manual code reviews or the use of specialized tools that perform thorough code inspections for malware. Merely checking for known vulnerabilities is insufficient.

As part of Checkmarx’s commitment to supply chain security, our research team continuously monitors and detects suspicious activities in the open-source software ecosystem. We track and flag potential indicators of malicious behavior and promptly alert our customers and the community to help protect them from these evolving threats.

Working together to keep the open source ecosystem safe.

IOC

• hxxps[:]//cdn.discordapp[.]com/attachments/1192526919577649306/1211404800575537304/VisualStudioEN.7z?ex=6612fda3&is=660088a3&hm=5ae3b1b5d2c7dc91a9c07a65dbf8c61d3822b1f16a2d7c70eb37a039979e8290&
• hxxps[:]//cdn.discordapp[.]com/attachments/1192526919577649306/1211403074799804476/VisualStudioRU.7z?ex=6612fc07&is=66008707&hm=0a7fc9432f5ef58960b1f9a215c3feceb4e7704afd7179753faa93438d7e8f54&
• 08b799d56265e93f6aae4f089808d1cb
• cc9d54b78688ef6f41e4f4d0c8bced3e04bfcedc
• ooocyber[.]keenetic[.]pro
• 188[.]113[.]132[.]109
• https://rentry.co/MuckCompanyMMC/raw
• hxxps[:]//rentry[.]co/hwqfx/raw
• hxxps[:]//rentry[.]co/q3i7zp/raw
• hxxps[:]//rentry[.]co/tvfwh/raw
• hxxps[:]//cdn[.]discordapp.com/attachments/1193658583947149322/1218876343232630844/main.exe?ex=6609420d&is=65f6cd0d&hm=f5a0af7499e892637935c3e4071f2dc59d48214f56a1c1d7aedc3392f58176db&
• hxxps[:]//paste[.]fo/raw/dd6cd76eb5a0
• hxxps[:]//paste[.]fo/raw/efda79f59c55
• hxxps[:]//rentry[.]co/4543t/raw
• hxxps[:]//rentry[.]co/a2edp
• hxxps[:]//textbin[.]net/raw/gr2vzmwcvt

New Technique to Trick Developers Detected in an Open-Source Supply Chain Attack. was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.

In March 2024, the software supply chain faced unprecedented threats, including one of the most advanced supply chain attacks known to date, where an advanced persistent threat actor hid a backdoor in a software package used in many Linux distributions. The Python ecosystem also found itself the target of numerous abuses, while the continued misuse of GitHub repositories for malware distribution persisted. Additionally, Tornado Cash, a decentralized privacy solution and cryptocurrency mixer on the Ethereum blockchain, fell victim to a stealthy attack.

Let’s delve into some of the most striking events of March:

Backdoor Discovered in xz: The Most Advanced Supply Chain Attack Known to Date

In what is probably one of the biggest, most advanced supply chain attacks in recent years was discovered accidentally on Friday 30th of March. The xz project, a tool used by many Linux distributions for compressing files, was compromised by a malicious actor who gradually took over the project and inserted a backdoor, allowing the attackers unauthorized access on systems that have the compromised versions installed. (report)

Over 170K Users Affected by Attack Using Fake Python Infrastructure

A software supply chain attack campaign, involving multiple TTPs, was launched by an attacker. The attacker created malicious open-source tools with clickbait descriptions and distributed a malicious dependency through a fake Python infrastructure, linking it to hijacked popular GitHub projects and legitimate Python packages. Among the victims of this attack was the Top.gg GitHub organization (a community of over 170k users) and several individual developers. The multi-stage malicious payload harvests sensitive and valuable data from infected systems and exfiltrates them to the attacker’s infrastructure. (report)

PyPi Is Under Attack: Project Creation and User Registration Suspended

On Mar 28, 2024–02:16 UTC, the Python Package Index (PyPi) suspended new project creation and new user registration to mitigate an ongoing malware upload campaign. (report)

Tornado Cash Theft Uncovered: Stealthy Attack Quietly Drains Funds from Decentralized Finance Platform for Months

The open-source codebase of Tornado Cash, a decentralized privacy solution and cryptocurrency mixer on the Ethereum blockchain, was compromised by a malicious developer. The attacker secretly embedded malicious JavaScript code within the project’s user interface, which captured and sent users’ private deposit notes to an unauthorized external server. (report)

GitHub Repos used for Distributing Malware

A report that delves into the escalating issue of malware distribution on GitHub, and underscores the diverse methods cybercriminals employ, ranging from attacks on legitimate repositories and social engineering to exploiting GitHub actions. (report)

Our team will continue to hunt, squash attacks, and remove malicious packages in our effort to keep the open-source ecosystem safe.

I encourage you to stay up to date with the latest trends and tactics in software supply chain security by tuning into our future posts and learning how to defend against potential threats.

Stay tuned…

Checkmarx Supply Chain Security,

Working to Keep the Open Source Ecosystem Safe

March 2024 in Software Supply Chain Security was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.

PyPi Is Under Attack: Project Creation and User Registration Suspended — Here’s the details

A few hours ago, The Python Package Index (PyPi) suspended all new project creation and new user registration to mitigate an ongoing malware upload campaign.

The research team of Checkmarx simultaneously investigated a campaign of multiple malicious packages appearing to be related to the same threat actors.

The threat actors target victims with Typosquatting attack technique using their CLI to install Python packages.

This is a multi-stage attack and the malicious payload aimed to steal crypto wallets, sensitive data from browsers (cookies, extensions data, etc..) and various credentials.

In addition, the malicious payload employed a persistence mechanism to survive reboots.

PyPi Suspended User and Project Creation

A few hours ago, on Mar 28, 2024–02:16 UTC, The Python Package Index (PyPi) added a new website banner and released an official update: “We have temporarily suspended new project creation and new user registration to mitigate an ongoing malware upload campaign”

Evidence of Multiple Malicious Typosquatting Packages

Between March 27 and March 28, 2024, multiple malicious Python packages were uploaded on the Python Package Index (PyPI). These packages most likely created using automation.

The Malicious Payload

The malicious code is located within each package’s setup.py file, enabling automatic execution upon installation.

employed a technique where the setup.py file contained obfuscated code that was encrypted using the Fernet encryption module. When the package was installed, the obfuscated code was automatically executed, triggering the malicious payload.

Upon execution, the malicious code within the setup.py file attempted to retrieve an additional payload from a remote server. The URL for the payload was dynamically constructed by appending the package name as a query parameter.

The retrieved payload was also encrypted using the Fernet module, Once decrypted, the payload revealed an extensive info-stealer designed to harvest sensitive information from the victim’s machine.

The malicious payload also employed a persistence mechanism to ensure it remained active on the compromised system even after the initial execution.

Summary

The discovery of these malicious Python packages on PyPI highlights the ongoing nature of cybersecurity threats within the software development ecosystem.

This incident is not an isolated case, and similar attacks targeting package repositories and software supply chains are likely to continue.

As this situation unfolds, we will provide updates on any new developments.

Working together to keep the open source ecosystem safe.

Package List

IOCs

• hxxps://funcaptcha[.]ru/paste2
• hxxps://funcaptcha].[ru/delivery
• hxxps://funcaptcha.ru/atomic/app.asar
• ABE19B0964DAF24CD82C6DB59212FD7A61C4C8335DD4A32B8E55C7C05C17220D
• 0C1DDD33E630F4AC684880F0E673DFA84919272494C11DA0F1EC05FB4F919CE8

PyPi Is Under Attack: Project Creation and User Registration Suspended — Here’s the details was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.

Key Points:

• Widespread Malware Distribution on GitHub: Recent discoveries, including Apiiro’s report on over 100,000 infected GitHub repositories, highlight a growing trend of using GitHub for malicious purposes.
• Diverse Attack Methods: GitHub-based cyber threats employ various sophisticated strategies, including attacks on legitimate repos, social engineering, and exploiting GitHub actions. This variety in attack vectors signifies the adaptability and ingenuity of cyber attackers in exploiting GitHub’s functionalities.
• Critical Role of Continuous Monitoring in Cybersecurity: The evolving nature of threats on platforms like GitHub underscores the imperative for robust, continuous monitoring solutions.
• Checkmarx’s Proactive Defense Against Supply Chain Cyber Threats: Checkmarx’s Supply Chain Security solution vigilantly monitors malicious activities, swiftly identifying and alerting on suspicious actions in the open source ecosystem to effectively counteract these cyber threats.

Malicious Repo Confusion Campaign

In light of a recent blog released by Apiiro, the cybersecurity landscape is yet again reminded of the innovative ways attackers exploit platforms like GitHub to host and spread malware. Apiiro’s findings reveal a large-scale malicious repo confusion campaign impacting over 100,000 GitHub repositories, shedding light on the evolving tactics of cybercriminals. Interestingly, part of the attackers’ strategy involved creating fake forks to make their repositories seem legitimate, a tactic we have discussed extensively in relation to repository spoofing.

The attacker took the following steps: they first cloned existing repos and infected them with malware loaders. Next, they uploaded them back to GitHub under identical names, automatically forking each one thousands of times. Finally, they covertly promoted them across the web via forums, discord, etc.

This is not an isolated case. The use of GitHub for malicious purposes has been a recurring theme, as evidenced by several incidents in the past.

Attacks on legitimate Repos

A notable method of exploiting GitHub involves attacking legitimate repos. A prime example is an incident in mid-2023 where attackers, leveraging stolen GitHub personal access tokens, impersonated Dependabot, a well-known dependency update helper tool. These tokens bypassed two-factor authentication, allowing malicious code to be committed under the guise of Dependabot. This code aimed to extract sensitive information and inject malware into JavaScript files.

Nation-State Social Engineering using GitHub:

Another tactic is the use of social engineering. In contrast to the scrutiny typically given to public open-source repositories, GitHub’s private repositories provide a more concealed avenue for attackers. A recent discovery revealed how North Korean state actors were using these malicious repos to then integrate into software through social engineering, targeting specific organizations or individuals.

Attacking GitHub Actions for Public Repos

In mid-2023, GitHub user account, pastramahodu, forked nearly 2,000 repositories, with 319,191 total stars combined, as part of a widespread bug bounty hunt attempt for finding misconfigurations in popular project’s CI pipelines. The procedure was most likely automated and created Pull Requests which in some projects triggered the project’s CI pipeline and executed the custom commands. This highlighted the increasing focus on pipeline security as an entry point for supply chain attacks.

Conclusion

The recurring theme across these examples is clear: GitHub, a platform integral to the development community, has become a focal point for cybercriminals looking to exploit the software supply chain. The sophistication and variety of these attacks demonstrate the evolving and persistent nature of these threats. As part of the Checkmarx Supply Chain Security solution, we continuously monitor and detect suspicious activities in the open-source software ecosystem, such as these. We track and flag “signals” that may indicate foul play and promptly alert our customers to help protect them. In the face of these sophisticated attacks, it is more important than ever for developers and organizations to stay alert, regularly review code sources, even from trusted platforms like GitHub, and implement robust security measures.

GitHub Repos used for Distributing Malware was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.