Blog

Crypto-Stealing Code Lurking in Python Package Dependencies

7 min.

October 1, 2024

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.

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