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.

Terminal output on an Ubuntu system showing the ‘ls’ command execution, its PATH location using ‘which ls’, and the system’s PATH environment variable, displaying the ‘ls’ PATH priority.

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.

Comparison of Ubuntu terminal outputs before and after installation of a malicious package. An ‘ls’ command is added to the PATH /home/ubuntu/.local/bin/ls, which takes priority over the PATH of the legitimate ls command.

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.

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.

Original obfuscated malicious function within the “cipherbcryptors” package

After deobfuscation – malicious function within the “cipherbcryptors” package

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

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.

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

Key Points

• A package called “lr-utils-lib” was uploaded to PyPi in early June 2024, containing malicious code that executes automatically upon installation.
• The malware uses a list of predefined hashes to target specific macOS machines and attempts to harvest Google Cloud authentication data.
• The harvested credentials are sent to a remote server.

Attack Flow

The malicious code is located within the setup.py file of the python package, which allows it to execute automatically upon installation.

This is the simplified code version, as the original was obfuscated.

Upon activation, the malware first verifies that it’s operating on a macOS system, its primary target. It then proceeds to retrieve the IOPlatformUUID of the Mac device (a unique identifier) and hashes it using the SHA-256 algorithm.

This resulting hash is then compared against a predefined list of 64 MAC UUID hashes, indicating a highly targeted attack strategy, and suggesting the attackers have prior knowledge of their intended victims’ systems.

If a match is found in the hash list, the malware’s data exfiltration process begins. It attempts to access two critical files within the ~/.config/gcloud directory: application_default_credentials.json and credentials.db. These files typically contain sensitive Google Cloud authentication data. The malware then attempts to transmit the contents of these files via HTTPS POST requests to a remote server identified as europe-west2-workload-422915[.]cloudfunctions[.]net.

This data exfiltration, if successful, could provide the attackers with unauthorized access to the victim’s Google Cloud resources.

CEO Impersonation

The social engineering aspect of this attack, while not definitively linked to the malware itself, presents an interesting dimension. A LinkedIn profile was discovered under the name “Lucid Zenith”, matching the name of the package owner. This profile falsely claims that Lucid Zenith is the CEO of Apex Companies, LLC. The existence of this profile raises questions about potential social engineering tactics that could be employed alongside the malware.

We queried various AI-powered search engines and chatbots to learn more about Lucid Zenith’s position. What we found was a variety of inconsistent responses. One AI-powered search engine, “Perplexity”, incorrectly confirmed the false information, without mentioning the real CEO.

This response was pretty consistent even with various phrasings of the question.

This was quite shocking since the AI-powered search engine could have easily confirmed the fact by checking the official company page, or even noticing that there were two LinkedIn profiles claiming the same title.

Other AI platforms, to their credit, when repeatedly questioned about Lucid Zenith’s role, correctly stated that he was not the CEO and provided the name of the actual CEO. This discrepancy underscores the variability in AI-generated responses and the potential risks of over-relying on a single AI source for verification. It serves as a reminder that AI systems can sometimes propagate incorrect information, highlighting the importance of cross-referencing multiple sources and maintaining a critical approach when using AI-powered tools for information gathering. Whether this manipulation was deliberate by the attacker, highlights a vulnerability in the current state of AI-powered information retrieval and verification systems that nefarious actors could potentially use to their advantage, for instance enhancing credibility and delivery of malicious packages.

Why does this matter? It shows the possible ways that social engineering attacks can complement technical exploits, like the malicious “lr-util-lib” package.

Conclusion

The analysis of the malicious “lr-utils-lib” Python package, reveals a deliberate attempt to harvest and exfiltrate Google Cloud credentials from macOS users. This behavior underscores the critical need for rigorous security practices when using third-party packages. Users should ensure they are installing packages from trusted sources and verify the contents of the setup scripts. The associated fake LinkedIn profile and inconsistent handling of this false information by AI-powered search engines highlight broader cybersecurity concerns. This incident serves as a reminder of the limitations of AI-powered tools for information verification, drawing parallels to issues like package hallucinations. It underscores the critical need for strict vetting processes, multi-source verification, and fostering a culture of critical thinking.

While it is not clear whether this attack targeted individuals or enterprises, these kinds of attacks can significantly impact enterprises. While the initial compromise usually occurs on an individual developer’s machine, the implications for enterprises can be substantial. For instance, if a developer within an enterprise unknowingly uses a compromised package, it could introduce vulnerabilities into the company’s software projects. This could lead to unauthorized access, data breaches, and other security issues, affecting the organization’s cybersecurity posture and potentially causing financial and reputational damage.

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

• lr-utils-lib

IOC

• europe-west2-workload-422915[.]cloudfunctions[.]net
• lucid[.]zeniths[.]0j@icloud[.]com

Key Points

• Polyfill.io, is a service used by over 100,000 websites, providing polyfill javascript code for backward compatibility for older browsers.
• This service recently switched owners and was sold to a Chinese company, Funnull, in February 2024.
• The new owners modified Polyfill.io service to silently inject malicious code.
• This attack employs evasion techniques and apparently focuses on attacking mobile devices.
• Do not use polyfill.io. Website owners and developers must immediatelyremove references from cdn.polyfill.io to trusted alternatives such as https://cdnjs.cloudflare.com/polyfill/.
• This attack is NOT affecting the popular NPM package polyfill. If you’re using the NPM package directly and not cdn.polyfill.io, you’re on the safe side.
• We advise not using the NPM package polyfill-service because of the new owners’ low reputation.

Pollyfill.io – What you need to know?

From Popular and Trusted Service to Trojan Horse

Polyfill.io, a service utilized by over 100,000 websites, enables modern JavaScript features to function seamlessly across older browsers. However, this widely trusted tool has recently become the epicenter of a significant supply chain attack, affecting its vast user base and beyond.

The sequence of events unfolded in February 2024 when the polyfill.io domain was acquired by Funnull, a Chinese company. This transaction immediately raised red flags among security experts, including Andrew Betts, the original developer of the Polyfill project. Betts swiftly cautioned the community against using the service, anticipating potential security vulnerabilities.

These concerns were validated when security researchers uncovered that the new owners had modified the script served by cdn.polyfill.io to inject malicious code. This transformation turned the once-reliable and trusted service into a vehicle for supply chain attacks.

Websites using the compromised cdn.polyfill.io unknowingly served this malicious code to their visitors.

The Anatomy of the Attack

At the heart of this security breach is malicious JavaScript code, injected directly through the compromised cdn.polyfill.io domain. When a website includes a script tag pointing to cdn.polyfill.io, it unknowingly pulls in this malicious code, executing it in users’ browsers.

Not A Malicious Package

It’s crucial to distinguish this attack from vulnerabilities in NPM packages, as this is not related to the polyfill NPM package or open-source software packages generally. While packages such as NPM packages are downloaded and installed locally in a project’s dependencies, this malicious code is served dynamically from the CDN each time a page loads. This means that even if a developer’s local environment and code repository are secure, the live website could still be serving malicious code to end users.

The Malicious Code

The attack utilizes dynamic payload generation, creating customized malicious content based on HTTP headers. This allows it to adapt its behavior to different environments, making it more difficult to identify and mitigate. Furthermore, the code is selective in its activation, targeting specific mobile devices.

To further evade discovery, the malicious code incorporates several evasion techniques. It avoids execution when it detects admin users or the presence of web analytics services. The code also employs delayed execution, postponing its actions to reduce the likelihood of being caught by immediate security scans.

Adding another layer of complexity, the entire malicious payload is obfuscated, making it more challenging to analyze its full capabilities.

In some instances, the attack introduces a fake Google Analytics script. Users receive tampered JavaScript files that include a link to “https://www.googie-anaiytics.com/gtags.js” (note the misspelling of “analytics”). This fraudulent script was found to redirect users to various malicious sites, including sports betting and pornographic websites, apparently based on the user’s geographic location.

While the current known actions of the malicious code are primarily focused on redirects, the nature of JavaScript means that the attack could evolve at any moment. Potential future threats include formjacking, where data from online forms could be stolen; clickjacking, which tricks users into clicking on disguised elements; and broader data theft, involving the collection and exfiltration of user information.

Industry Giants Respond

In response to the attack, major players in the tech industry have taken action. Cloudflare and Fastly set up their own mirrors of the Polyfill.io service to provide a trusted alternative, and Google has begun notifying advertisers whose landing pages include the compromised code, warning of potential ad disapprovals due to unwanted redirects.

Checkmarx Customers – What You Can Do

To find out if you are impacted by this attack, scan your web application with this custom SAST query below:

result = Find_Strings().FindByRegex(@"https?:\/\/(cdn\.polyfill\.io)");

You can also contact Checkmarx Support or your account manager.

Conclusion

We advise not using the NPM package polyfill-service because of the new owners’ low reputation even though latest release to this day is clean from malicious code.

The Polyfill.io supply chain attack serves as another wake-up call for the web development community, highlighting the vulnerabilities that can arise when widely-used services change hands. In response, website owners and developers should take immediate action: remove all references to cdn.polyfill.io, consider trusted alternatives like Cloudflare or Fastly mirrors, and evaluate self-hosting options.

This incident also underscores the importance of regularly auditing third-party dependencies, staying informed about ownership changes in critical services, and developing contingency plans for rapid migration.

• The critical vulnerability CVE-2024-34359 has been discovered by retr0reg in the “llama_cpp_python” Python package.
• This vulnerability allows attackers to execute arbitrary code from the misuse of the Jinja2 template engine.
• Over 6k AI models om HuggingFace using llama_cpp_python and Jinja2 are vulnerable.
• A fix has been issued in v0.2.72
• This vulnerability underscores the importance of security in AI systems and software supply chain.

Imagine downloading a seemingly harmless AI model from a trusted platform like Hugging Face, only to discover that it has opened a backdoor for attackers to control your system. This is the potential risk posed by CVE-2024-34359. This critical vulnerability affects the popular llama_cpp_python package, which is used for integrating AI models with Python. If exploited, it could allow attackers to execute arbitrary code on your system, compromising data and operations. Over 6,000 models on Hugging Face were potentially vulnerable, highlighting the broad and severe impact this could have on businesses, developers, and users alike. This vulnerability underscores the fact that AI platforms and developers have yet to fully catch up to the challenges of supply chain security.

Understanding Jinja2 and llama_cpp_python

Jinja2: This library is a popular Python tool for template rendering, primarily used for generating HTML. Its ability to execute dynamic content makes it powerful but can pose a significant security risk if not correctly configured to restrict unsafe operations.

`llama_cpp_python`: This package integrates Python’s ease of use with C++’s performance, making it ideal for complex AI models handling large data volumes. However, its use of Jinja2 for processing model metadata without enabling necessary security safeguards exposes it to template injection attacks.

[image: jinja and llama]

What is CVE-2024-34359?

CVE-2024-34359 is a critical vulnerability stemming from the misuse of the Jinja2 template engine within the `llama_cpp_python` package. This package, designed to enhance computational efficiency by integrating Python with C++, is used in AI applications. The core issue arises from processing template data without proper security measures such as sandboxing, which Jinja2 supports but was not implemented in this instance. This oversight allows attackers to inject malicious templates that execute arbitrary code on the host system.

The Implications of an SSTI Vulnerability

The exploitation of this vulnerability can lead to unauthorized actions by attackers, including data theft, system compromise, and disruption of operations. Given the critical role of AI systems in processing sensitive and extensive datasets, the impact of such vulnerabilities can be widespread, affecting everything from individual privacy to organizational operational integrity.

The Risk Landscape in AI and Supply Chain Security

This vulnerability underscores a critical concern: the security of AI systems is deeply intertwined with the security of their supply chains. Dependencies on third-party libraries and frameworks can introduce vulnerabilities that compromise entire systems. The key risks include:

• Extended Attack Surface: Integrations across systems mean that a vulnerability in one component can affect connected systems.
• Data Sensitivity: AI systems often handle particularly sensitive data, making breaches severely impactful.
• Third-party Risk: Dependency on external libraries or frameworks can introduce unexpected vulnerabilities if these components are not securely managed.

A Growing Concern

With over 6,000 models on the HuggingFace platform using `gguf` format with templates—thus potentially susceptible to similar vulnerabilities—the breadth of the risk is substantial. This highlights the necessity for increased vigilance and enhanced security measures across all platforms hosting or distributing AI models.

Mitigation

The vulnerability identified has been addressed in version 0.2.72 of the llama-cpp-python package, which includes a fix enhancing sandboxing and input validation measures. Organizations are advised to update to this latest version promptly to secure their systems.

Conclusion

The discovery of CVE-2024-34359 serves as a stark reminder of the vulnerabilities that can arise at the confluence of AI and supply chain security. It highlights the need for vigilant security practices throughout the lifecycle of AI systems and their components. As AI technology becomes more embedded in critical applications, ensuring these systems are built and maintained with a security-first approach is vital to safeguard against potential threats that could undermine the technology’s benefits.

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.

Many of the stargazers are created on the same date. A red flag for fake accounts.

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.

Technical Analysis of the Common Malicious Payload

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

The attack, discovered accidently on March 29, 2024, by a developer named Andres Freund, during performance testing, was carried out over several years by the GitHub account Jia Tan (JiaT75), who gained the trust of the long-time maintainer of the xz project and eventually replaced them as the main point of contact.

The backdoor was added in versions 5.6.0 and 5.6.1 of xz Utils, a software package that includes the xz library. This backdoor allows attackers unauthorized access on systems that have the compromised versions installed.

The impact of this backdoor is significant because of xz’s use in many systems around the world, including popular Linux distributions like Red Hat and Debian.

In this blog post, we will provide a timeline of the events, look at the key people involved, and discuss what this incident means for the open-source community and the importance of maintaining the security and integrity of widely-used software libraries.

Key Findings

• xz, a widely-used compression library, was compromised with a backdoor (CVE-2024-3094) that allows forunauthorized access on systems with compromised versions (5.6.0 and 5.6.1) installed.
• The attack was carried out over several years by a user named Jia Tan (JiaT75), who gradually gained maintainer status after continuous pressure from unknown accounts on the long-time maintainer, Lasse Collin, to add a new maintainer and approve Jia Tan’s patch.
• The widespread use of xz in Linux distributions makes the impact of the backdoor significant.
• The backdoor was accidentally discovered on March 29, 2024, by the developer Andres Freund.

Gaining Reputation Over Time

The xz compression library, a widely-used tool for compressing files, found across Linux distributions, community projects, and commercial products, was compromised by a malicious actor named Jia Tan (JiaT75) who gradually and patiently gained maintainer status in order to pull off the attack, ultimately introducing a backdoor identified as CVE-2024-3094.

The attack began in 2021 when Jia Tan created their GitHub account and began using it for various activities.

In April 2022, Jia Tan submitted a patch to the xz project via a mailing list. Soon after, unknown accounts, including one named Jigar Kumar and another named Dennis Ens , began pressuring the long-time maintainer of xz, Lasse Collin, to merge the patch and add a new maintainer to the project. Lasse Collin, who had limited availability to take care for the project, eventually agreed to add Jia Tan as a maintainer. A decision that is in fact not unusual in the open-source community, where maintainers often hand off projects to others due to various reasons.

Over the next two years, Jia Tan became a regular contributor to the xz project, gaining trust within the community.

By March 2023, Jia Tan had become the primary contact for xz in Google’s oss-fuzz, a platform for finding vulnerabilities in open-source software.

Most Sophisticated Supply Chain Attack We Know

The backdoor itself was introduced in versions 5.6.0 and 5.6.1 of xz Utils, a software package that includes the xz library. The malicious code allows attackers unauthorized access by infecting the SSH on systems with the compromised versions installed, making it a significant threat to users of the library.

A Discovery

The backdoor was accidentally discovered on March 29, 2024, by Andres Freund during routine performance testing. Freund noticed unusual CPU usage in the sshd process, which led him to investigate further and uncover the malicious code. This accidental discovery, the backdoor could have gone unnoticed for a longer period, effecting a large part of the open source ecosystem.

Impact

The impact of the backdoor could have had particularly severe consequences due to the widespread use of xz in compressing critical software components, including popular Linux distributions like Red Hat and Debian. Many systems worldwide rely on xz for compressing and decompressing files, making the potential reach of the backdoor extensive.

Advanced Persistent Threat

The involvement of multiple identities. The complexity of the payload, and the high level of technical expertise required, along with the patience and persistence shown in gradually gaining trust within the xz community over several years before introducing the backdoor. All these are consistent with the capabilities of nation-state actors and are qualities of advanced persistent threats (APTs). 

This incident is part of a growing and alarming trend of advanced persistent threats (APTs) targeting critical open-source projects.

Conclusion

The xz compromise highlights the urgent need for the open-source community to improve its security practices and tools to prevent similar attacks in the future. Collaboration, transparency, and shared responsibility are essential to detecting and mitigating advanced persistent threats (APTs) targeting critical open-source projects. 

We, the community must develop more effective strategies, to strengthen the security of open-source software. By learning from this incident and taking proactive measures, the open-source community can build a more resilient and trustworthy ecosystem, ensuring the long-term success and integrity of open-source projects in the face of ever-evolving cybersecurity threats.

Working together to keep the opensource ecosystem safe.

Key Points

1. An attacker distributed a malicious dependency hosted on a fake Python infrastructure by linking it to popular projects on GitHub and legitimate Python packages.
2. The malicious dependency, masquerading as the popular “colorama” package, contained hidden malware designed to steal sensitive data from infected systems.
3. The attacker hijacked GitHub accounts, including one belonging to a top.gg contributor, using it to make malicious commits and spread the malware to a community of over 170K members.
4. Employing a multi-stage execution process, the malware fetches and executes obfuscated code from multiple external sources, using techniques like encryption, encoding, compression, and misleading characters to evade detection.
5. Targeting a wide array of applications, such as web browsers, social media platforms, email services, and messaging apps, the malware harvests sensitive information, including login credentials, session tokens, and personal data.
6. Stolen data is exfiltrated to the attacker’s server, and persistence is established through Windows registry modifications.

Weird Message, Got Hacked

“I was using my laptop today, just the regular messing around with python and other stuff on my command line, until I seen a weird message on my command line saying that there’s something wrong with colorama on python, I didn’t care much cause I’m used to this stuff so I just skipped it, Few minutes later I got the same error message but in a different script I’m using. The moment I seen this I knew what’s going on, I got hacked.”

This chilling account comes from a recent blog post by Mohammed Dief, a Python developer who fell victim to a sophisticated malware attack while cloning the repository “maleduque/Valorant-Checker”.

Mohammed’s story is just one example of the far-reaching impact of this malware campaign. The attacker behind the campaign employed a devious strategy to spread the malware through malicious GitHub repositories.

Fake Python Mirror

The attack infrastructure included a website that appeared to be a Python package mirror and was registered under the domain “files[.]pypihosted[.]org”.

This domain selection is a clever typosquat of the official Python mirror “files.pythonhosted.org,” as the latter is where the official artifact files of PyPi packages are typically stored.

In the attacker’s footprints, we saw they utilized a feature in pip (package manager for Python) where you can specify a URL to grab your package dependency and use their fake Python mirror to download packages.

Requirement.txt file, Fake mirror URL vs legitimate URL

Fake Mirror Is Hosting a Poisoned “colorama”

The threat actors used Colorama,  and added malicious code inside, then hosted the poisoned Colorama package on their typosquatted domain; the attacker was able to use the exact same name as the popular “Colorama” package without raising immediate suspicion. This tactic makes it significantly harder for users to detect the malicious nature of the package, as it appears to be a legitimate dependency at first glance.

To further conceal their malicious intent, the attacker employed a strategic approach when committing changes to many of the malicious repositories. They would simultaneously commit multiple files, including the requirements file containing the malicious link, along with other legitimate files. This calculated move aimed to minimize the chances of detection, as the malicious link would blend in with the legitimate dependencies, reducing the likelihood of users spotting the anomaly during a cursory review of the committed changes.

Example of the attacker hiding Fake mirror URL within a commit of multiple files.

Hijacked GitHub Account

The attacker’s reach extended beyond creating malicious repositories through their own accounts. They managed to hijack the GitHub account of a user named “editor-syntax,” who is a member of the company top-gg and a contributor to one of their repositories. With control over this trusted account, the attacker carried out a series of malicious activities:

Starring Malicious Repositories: The compromised account was used to star multiple malicious GitHub repositories created by a user named LoffyNora. This activity aimed to increase the visibility and credibility of the malicious repositories.

Malicious Commit to top-gg Repository: The attacker made a malicious commit to a repository belonging to top-gg, exploiting the trust and privileges associated with the compromised account of “editor-syntax.”

Spreading the Malware: Through the compromised account, the attacker likely spread the malware to unsuspecting users who trusted the reputation of “editor-syntax” and the top-gg organization.

Account Takeover via Stolen Cookies

The GitHub account of “editor-syntax” was likely hijacked through stolen cookies. The attacker gained access to the account’s session cookies, allowing them to bypass authentication and perform malicious activities using the GitHub UI. This method of account takeover is particularly concerning, as it does not require the attacker to know the account’s password.

“Bro What”

The incident caused alarm within the top-gg community (which boasts over 170K members), as users alerted “editor-syntax” on discord about the suspicious activities originating from their account. “editor-syntax” was quite shocked, to say the least, as he realized what had occurred through his GitHub account. It became evident that the malware had compromised multiple individuals, highlighting the scale and impact of the attack.

Interestingly, the attacker’s Typosquatting technique was so convincing that even a user on GitHub fell victim to it without realizing they were under attack. When the malicious domain, piphosted[.]org”, went down, the user opened an issue on one of the malicious repositories, complaining about it, not realizing it had been a host for malicious payloads.

Deep Dive into the Malicious Python Package

In addition to spreading the malware through malicious GitHub repositories, the attacker also utilized a malicious Python package called “yocolor” to further distribute the “colorama” package containing the malware. They employed the same typosquatting technique, hosting the malicious package on the domain “files[.]pypihosted[.]org” and using an identical name to the legitimate “colorama” package.

By manipulating the package installation process and exploiting the trust users place in the Python package ecosystem, the attacker ensured that the malicious “colorama” package would be installed whenever the malicious dependency was specified in the project’s requirements. This tactic allowed the attacker to bypass suspicions and infiltrate the systems of unsuspecting developers who relied on the integrity of the Python packaging system.

Stage 1

The first stage is where the unsuspected user downloads the malicious repo or package which contians the malicious dependency – “colorama” from the typosquatted domain, “files[.]pypihosted.org”.

Example of how the malicious code looks like within the ycolor package

Stage 2

The malicious “colorama” package contains code that is identical to the legitimate package, with the exception of a short snippet of additional malicious code. Initially, this code was located within the file “colorama/tests/__init__.py”, but the attacker later moved it to “colorama/init.py”, likely to ensure that the malicious code is executed more reliably. This code sets the stage for the subsequent phases of the attack.

The attacker employed a clever technique to hide the malicious payload within the code. They used a significant amount of whitespace to push the malicious code off-screen, requiring someone inspecting the package to scroll horizontally for an extended period before discovering the hidden malicious content. This technique aimed to make the malicious code less noticeable during a quick review of the package’s source files.

This code fetches and executes another piece of Python code from “hxxps[:]//pypihosted[.]org/version,” which installs necessary libraries and decrypts hard-coded data using the “fernet” library. The decrypted code then searches for a valid Python interpreter and executes yet another obfuscated code snippet saved in a temporary file.

Stage 3

The malware progresses further, fetching additional obfuscated Python code from another external link: hxxp[:]//162[.]248[.]100[.]217/inj, and executes it using “exec”.

Stage 4

Upon analysis, it’s clear that the attacker has put thought into obfuscating their code. Techniques such as the use of Chinese and Japanese character strings, zlib compression, and misleading variable names are just a few of the techniques employed to complicate the code’s analysis and comprehension.

The simplified code checks the compromised host’s operating system and selects a random folder and file name to host the final malicious Python code, which is retrieved from “hxxp[:]//162[.]248[.]100.217[:]80/grb.”

A persistence mechanism is also employed by the malware by modifying the Windows registry to create a new run key, which ensures that the malicious Python code is executed every time the system is rebooted. This allows the malware to maintain its presence on the compromised system even after a restart.

Stage 5 – No One Is Left Behind

The final stage of the malware, retrieved from the remote server, reveals the true extent of its data-stealing capabilities. It targets a wide range of popular software applications and steals sensitive information, some of which include:

Browser Data: The malware targets a wide range of web browsers, including Opera, Chrome, Brave, Vivaldi, Yandex, and Edge. It searches for specific directories associated with each

browser and attempts to steal sensitive data such as cookies, autofill information, browsing history, bookmarks, credit cards, and login credentials.

Discord Data: The code specifically targets Discord by searching for Discord-related directories and files. It attempts to locate and decrypt Discord tokens, which can be used to gain unauthorized access to the victim’s Discord account.

Cryptocurrency Wallets: The malware includes a list of cryptocurrency wallets that it aims to steal from the victim’s system. It searches for specific directories associated with each wallet and attempts to steal wallet-related files. The stolen wallet data is then compressed into ZIP files and uploaded to the attacker’s server.

Telegram Sessions: The malware also attempts to steal Telegram session data. It searches for Telegram-related directories and files, aiming to capture the victim’s session information. With access to Telegram sessions, the attacker could potentially gain unauthorized access to the victim’s Telegram account and communications.

Computer Files: The malware includes a file stealer component that searches for files with specific keywords in their names or extensions. It targets directories such as Desktop, Downloads, Documents, and Recent Files.

Instagram data: The malware attempts to steal sensitive information from the victim’s Instagram profile by leveraging the Instagram session token. The malware sends requests to the Instagram API using the stolen session token to retrieve various account details.

Further analysis of the final payload reveals that the malware also includes a keylogging component. It captures the victim’s keystrokes and saves them to a file, which is then uploaded to the attacker’s server. This capability allows the attacker to monitor and record the victim’s typed input, potentially exposing sensitive information such as passwords, personal messages, and financial details.

The stolen data is exfiltrated to the attacker’s server using various techniques. The code includes functions to upload files to anonymous file-sharing services like GoFile and Anonfiles. It also sends the stolen information to the attacker’s server using HTTP requests, along with unique identifiers like hardware ID or IP address to track the victim.

Conclusion

This campaign is a prime example of the sophisticated tactics employed by malicious actors to distribute malware through trusted platforms like PyPI and GitHub.

This incident highlights the importance of vigilance when installing packages and repositories even from trusted sources. It is crucial to thoroughly vet dependencies, monitor for suspicious network activity, and maintain robust security practices to mitigate the risk of falling victim to such attacks.

As the cybersecurity community continues to uncover and analyze these threats, collaboration and information sharing remain essential in the ongoing battle against malicious actors in the software supply chain.

We reported the abused domains to Cloudflare, and they have since been taken down.

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.

Working together to keep the open source ecosystem safe.

Timeline

1. Nov 2022: Pypi User “felpes” added three packages to the Python Package Index (PyPI) that contained various forms of malicious code.
2. Feb 01, 2024: The domain pypihosted[.]org was registered by the attacker.
3. Mar 04, 2024: The GitHub account of a top.gg contributor was compromised, and the attacker used it to commit malicious code to the organization’s repository.
4. Mar 13, 2024: The attacker registered the domain pythanhosted.org, further expanding their typosquatting infrastructure.
5. Mar 05, 2024: The malicious package “yocolor” was published on PyPI, acting as a delivery mechanism for the malware.

List of Packages

IOC

• hxxps[:]//files[.]pythanhosted.org/packages/d8/53/6f443c9a4a8358a93a6792e2acffb9d9d5cb0a5cfd8802644b7b1c9a02e4/colorama-0.4.5.tar.gz
• hxxps[:]//files[.]pypihosted.org/packages/d8/53/6f443c9a4a8358a93a6792e2acffb9d9d5cb0a5cfd8802644b7b1c9a02e4/colorama-0.4.6.tar.gz
• hxxps://files[.]pypihosted[.]org/packages/d8/53/6f443c9a4a8358a93a6792e2acffb9d9d5cb0a5cfd8802644b7b1c9a02e4/colorama-0.4.3.tar.gz
• 162[.]248.101.215
• pypihosted.org/version
• 162[.]248.100.217
• 162.248.100.117
• 0C1873196DBD88280F4D5CF409B7B53674B3ED85F8A1A28ECE9CAF2F98A71207
• 35AC61C83B85F6DDCF8EC8747F44400399CE3A9986D355834B68630270E669FB
• C53B93BE72E700F7E0C8D5333ACD68F9DC5505FB5B71773CA9A8668B98A17BA8

• Sophisticated Supply chain attack: The Tornado Cash open source project was compromised with malicious JavaScript code inserted by a developer.
• Impact: Users who conducted transactions using the targeted Tornado Cash project through IPFS gateways were unknowingly impacted for a couple of months.
• Discovery: The compromise, discovered by Security researcher Gas404, marks the second major security issue for Tornado Cash within a year, emphasizing the importance of community vigilance in decentralized finance.
• Ongoing risks in decentralized finance: This incident highlights the persistent challenges in ensuring safety and trust in decentralized platforms.

What is Tornado Cash?

Tornado Cash is a decentralized privacy solution built on the Ethereum blockchain, offering users non-custodial and anonymous transactions. Functioning as a cryptocurrency mixer, it provides a mechanism to obfuscate the origins and destinations of digital asset transfers, enhancing user privacy and security. While Tornado Cash has faced scrutiny for its potential misuse in illicit activities, such as money laundering notably by entities like North Korean hackers, it remains an innovative tool in the realm of decentralized finance.

In 2022, The original Tornado Cash service encountered challenges due to U.S. government sanctions, impacting its usage among certain user demographics. Despite this setback, the project’s open-source codebase has fostered the emergence of new independent mixing services.

The Compromise of the Open Source Tornado Cash

Tornado Cash recently fell victim to a sophisticated attack. This attack was executed through a deceptive contribution by a developer, who secretly embedded malicious JavaScript code within the project’s user interface. This code was designed to covertly capture and send users’ private deposit notes to an unauthorized external server. Deposit notes in Tornado Cash act like private keys, crucial for accessing and managing funds within the service.

This exploit specifically targeted users accessing Tornado Cash through IPFS gateways, like ipfs.io and cf-ipfs.com. These gateways are used to enter the decentralized web where Tornado Cash operates. The malicious code was cleverly concealed within a governance proposal by the developer, making it very challenging for an average user to detect.

The code worked by encoding these private deposit notes and sending them to the exploiter’s server under the guise of routine function calls. This meant that whenever a user engaged with certain functions of Tornado Cash, their private information was leaked without their knowledge.

The discovery of this malicious code was credited to a security researcher known as Gas404, and according to their findings, all Tornado Cash servers deployed on the IPFS network since January 1 of this year were believed to be impacted.

In the aftermath of the sanctions imposed on Tornado Cash, the original website of the service was seized. However, the open-source codebase of Tornado Cash continued to exist independently, leading to the emergence of new, shadowy mixing services using the same foundation. This incident of backdoor code implantation marks the second major security breach that Tornado Cash has endured over the past year, with a previous instance in May of the previous year where a hacker briefly seized control of the project’s governance.

In terms of the impact, the exact extent of the funds compromised in this latest breach still remains uncertain.

Conclusion

The Tornado Cash open-source project compromise highlights serious concerns about the safety of decentralized finance platforms and the trustworthiness of developers. It serves as a stark reminder that we cannot simply assume open-source projects are immune from malicious activities. The notion that “someone else is checking” can often lead to a false sense of security. Importantly, this incident illustrates how attackers like to leverage supply chain attacks to compromise sensitive applications and networks. It underscores the importance of thorough security audits, vetting of code and contributions, even from seemingly trustworthy sources, and the need to protect against supply chain vulnerabilities. For users, it’s a reminder to be vigilant about the platforms they use and to understand the associated risks. Clearly, preserving security and trust in decentralized platforms remains a challenging but vital task.