In November 2024, supply chain attacks featured two key trends: attackers’ persistent use of “legitimate-first” package strategies and creative approaches like exploiting official documentation. Cryptocurrency remained the primary target through both credential theft and mining operations.
Let’s delve into some of the most striking events of November:
Dozens of Machines Infected: Year-Long NPM Supply Chain Attack Combines Crypto Mining and Data Theft
A malicious NPM package, masquerading as a legitimate XML-RPC implementation, operated for over a year — stealing data and mining cryptocurrency. Dozens of systems were affected. (Link to report).
xml-rpc attack flow
Malicious NPM Package Exploits React Native Documentation Example
An attacker published a malicious NPM package that mirrors an example from React Native’s official documentation, in an attempt to trick developers following the official guide. This highlights the need for careful package verification even when following official guides. (Link to report).
From React Native’s official documentationMalicious npm package mirroring example from React Native’s official documentation
Falling Stars
Two years after the discovery of StarJacking, an analysis of 21 package repositories reveals improved security measures against this threat — though the risk still persists in some repositories. (Link to report).
Example of PyPi ecosystem process — adding verification of the package metadata.
“aiocpa” Python Package Transforms From Legitimate Package to Crypto Thief
In November 2024, PyPI published an advisory about the aiocpa package, which was compromised when versions 0.1.13 and 0.1.14 introduced obfuscated malware designed to steal cryptocurrency credentials via Telegram. The attack was notable for its patience — the attacker maintained a legitimate package for months before adding malware, while keeping the GitHub repository clean. With thousands of downloads in its final month, aiocpa joins a growing trend where attackers establish legitimate packages before weaponizing them, in most cases to target cryptocurrency assets.
Our team will continue to hunt, squash attacks, and remove malicious packages in our effort to keep the open-source ecosystem safe.
I encourage you to stay up to date with the latest trends and tactics in software supply chain security by tuning into our future posts and learning how to defend against potential threats.
A recent discovery revealed how official documentation can become an unexpected attack vector for supply chain attacks. It happened when an npm package called “rtn-centered-text” exploited an example from React Native’s Fabric Native Components guide in an attempt to trick developers into downloading their package, putting systems at risk.
Key Findings
An attacker published a malicious package that mirrors an example from React Native’s official documentation, in an attempt to trick developers following the official guide.
By leveraging a subtle imprecision in package management instructions, the attack demonstrates how documentation can inadvertently become an attack vector
This incident highlights the importance of the principle “trust but verify”.
The Attack Vector: Documentation as an Entry Point
The React Native documentation for Fabric Native Components includes a detailed guide for creating custom components, using “RTNCenteredText” as an example. While the documentation is comprehensive and well-maintained, a subtle detail in the package update instructions created an unexpected security vulnerability.
The guide suggests using “yarn upgrade rtn-centered-text” to update local development packages.
However, this command first checks the npm registry for packages before looking at local files. An attacker exploited this behavior by publishing a malicious package with the same name on npm.
Community Response and Discovery
The security issue was first identified by a vigilant community member who submitted a pull request to the React Native documentation repository. The contributor noticed the malicious package on npm while following the documentation guide and immediately raised the alarm. Their quick action in reporting both to npm and the React Native team demonstrates the crucial role that community vigilance plays in maintaining ecosystem security.
Impact and Implications
The implications of this attack extend beyond immediate data exposure. It demonstrates how attackers are becoming increasingly sophisticated in their approach to supply chain attacks. By targeting documentation examples from trusted sources, they exploit the implicit trust developers place in official documentation.
This incident serves as a reminder that supply chain security requires vigilance at every level. Documentation must be precise about package management commands, developers need to verify package sources, and security tools should monitor for packages that may be impersonating official examples.
When working with package managers and following documentation, it is recommended for developers to use explicit paths when adding local packages. Instead of using “yarn upgrade”, use “yarn add ../package-name” to ensure you’re referencing local development packages.
Conclusion
This incident highlights the principle “trust but verify”. While developers naturally trust official documentation and guides from reputable sources, it’s crucial to maintain a careful verification process even when following trusted resources. This approach ensures that every component, package, and instruction is validated before implementation, protecting against potential security breaches that might exploit this trust.
The open-source community’s strength lies in its collaborative approach to identifying and addressing security concerns, but we must remain vigilant.
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.
A malicious campaign involving several python packages, most notably the “spl-types” Python package began on June 25th with the upload of an innocuous package to PyPI. This initial version, devoid of malicious content, was intended to establish credibility and avoid immediate detection. It was a wolf in sheep’s clothing, waiting for the right moment to reveal its true nature. The attacker’s patience paid off on July 3rd when they unleashed multiple malicious versions of the package. The heart of the malware was in the init.py file, obfuscated to evade casual inspection. Upon installation, this code would execute automatically, setting in motion a chain of events designed to compromise and control the victim’s systems, while also exfiltrating their data and draining their crypto wallets.
Key Findings
Multiple malicious Python packages were uploaded to PyPI, targeting cryptocurrency users involved with Raydium and Solana.
The attacker exploited StackExchange as their primary vector to direct people to their malicious package. They posted a seemingly helpful answer on a popular thread that referenced their malicious package, leveraging trust in community-driven platforms.
The multi-stage malware exfiltrated extensive sensitive data and facilitated the draining of victims’ crypto wallets
Windows Virus and Threat Protection failed to detect the active malware on a victim’s system, providing a real-world validation of our previous research demonstrating that modern EDR systems are ineffective against threats from malicious packages.
A backdoor component in the malware granted the attacker persistent remote access to victims’ systems, enabling potential future exploits and long-term compromises.
A Multi-Stage Assault
The initial payload acted as a springboard, reaching out to external resources to download and execute additional malicious scripts. These scripts formed the core of the operation, and meticulously scanned the victim’s system for valuable data. The malware cast a wide net, targeting an array of sensitive information — browser data was readily available, as the malware harvested saved passwords, cookies, browsing history, and even stored credit card information. Cryptocurrency wallets, including popular options like Exodus, Electrum, and Monero, were also prime targets. The attack didn’t stop there; it also sought out data from messaging applications such as Telegram, Signal, and Session. In a particularly invasive move, the malware captured screenshots of the victim’s system, providing the attacker with a visual snapshot of the user’s activities. It also scoured the system for files containing specific keywords related to cryptocurrencies and other sensitive information, including GitHub recovery codes and BitLocker keys. The final part of this digital heist involved compressing the stolen data and exfiltrating it to the attacker’s command and control server via several Telegram bots.
Also included in the malicious scripts was a backdoor that granted the attacker remote control over the victim’s system, allowing for ongoing access and potential future exploits.
One of the attacker’s telegram bots receiving screenshots and data from victims machines.
Profiling the victims & motives behind the attack
As we continued to follow this attack, a clear pattern emerged around the victims. What united them was not their profession or location, but their involvement with Raydium and Solana, two prominent players in the cryptocurrency space. This commonality suggests that the attacker had a specific target in mind.
The focus on users of these platforms indicates a level of strategic thinking on the part of the attacker. By targeting this specific group, they positioned themselves to potentially intercept or manipulate high-value transactions, pointing to clear financial motives behind the attack.
Delivery strategy of the malware
The attacker was strategic when thinking about how to deliver the malicious package to unsuspecting victims. Their approach was twofold: create a seemingly legitimate package and then lending it credibility through manipulative online engagement.
Step 1: Crafting a Deceptive Package
The first step involved creating a package that would raise minimal suspicion.
In screenshots from compromised systems, we observed victims using, or installing, a package named “Raydium”.
It’s crucial to note that while Raydium is a legitimate blockchain-related platform (an Automated Market Maker (AMM) and liquidity provider built on the Solana blockchain for the Serum Decentralized Exchange (DEX)), it does not have an official Python library.
Exploiting this gap, the attacker, used a separate username to publish a Python package named “Raydium” on PyPI.
The malicious packages of this campaign were dependencies within other seemingly legitimate packages.
This package included the malicious “spl-types” as a dependency, effectively disguising the threat within a seemingly relevant and legitimate package.
Step 2: Building Credibility and Ensuring Adoption
To lend credibility to this package and ensure its widespread adoption, the attacker scoured StackExchange, a popular Q&A platform similar to Stack Overflow, for highly viewed threads related to Raydium and Solana development. Upon identifying a suitable and popular thread, the attacker contributed what seemed to be a high-quality, detailed answer. This response, while ostensibly helpful, included references to their malicious “Raydium” package. By choosing a thread with high visibility — garnering thousands of views — the attacker maximized their potential reach.
Developers seeking solutions to Raydium-related questions would likely view the answer as credible and follow the suggestions with minimal suspicion.
This tactic underscores the importance of verifying the authenticity of packages, especially those recommended in forums by unknown individuals.
Case Studies and the personal impact
The impact of this attack goes beyond theory. Behind each compromised system is a real person, and their stories reveal the true cost of such breaches. There were many cases, but in this blog, let’s look at a couple notable ones that highlight different aspects of this attack:
Case Study 1
In one of the malware-captured screenshots, we observed clear personal details of a victim. Cross-referencing this information with LinkedIn allowed us to identify the individual, who happened to also be employed at a respected IT company. This discovery prompted us to take the step of reaching out to warn them about the breach. During our subsequent communication, we learned the victim’s entire Solana crypto wallet had been drained shortly after unknowingly downloading the malicious package. This case vividly illustrates how such attacks can have immediate and severe financial consequences for individuals.
Case Study 2
Bottom left: Screenshot of the victim’s screen. Top right: Windows Defender scan declaring in Dutch that the system is clear of threats after the scan. Top left: victim’s private key.
Another victim’s experience highlighted a critical weakness in current cybersecurity practices. A screenshot from their system showed a private key clearly visible — a goldmine for any attacker since these keys bypass any password or multi factor authentication active on the account that the private key is for.
In addition to that, and what made this image particularly alarming, was the Windows Virus and Threat Protection screen displayed alongside it, declaring that a scan had just been completed and that the system was clear of threats.
The revelation that Windows Virus and Threat Protection failed to detect the threat during active data exfiltration is particularly concerning. It emphasizes a critical blind spot in traditional security measures when it comes to malicious activities initiated through package managers. This failure of detection occurred not just before or after the attack, but during the very moment the malware was active and stealing data.
This incident provides a real-world example of how Endpoint Detection and Response (EDR) systems can fall short in stopping malicious package activity or sending relevant alerts.
Moreover, even if the malicious package is later taken down from the repository and not publicly declared as malicious, EDR systems typically won’t flag the package as vulnerable if it remains installed
on a user’s system. This leaves users potentially exposed to ongoing threats from previously downloaded malicious packages.
PyPi for example, to this day, completely eliminates all traces of a package, leaving no placeholders behind. Although malicious usernames often remain, they appear without any associated malicious packages. Consequently, anyone who encounters these malicious usernames may be unaware of the user’s history of uploading malicious packages.
The “spl-types” malware incident is more than just another data breach. It serves as a stark reminder of the cost of cybersecurity failures and the ongoing challenges we face in securing the software supply chain.
This incident’s impact extends beyond individual users to enterprises. A single compromised developer can inadvertently introduce vulnerabilities into an entire company’s software ecosystem, potentially affecting the whole corporate network.
This attack serves as a wake-up call for both individuals and organizations to reassess their security strategies. Relying solely on traditional security measures is not sufficient. A more comprehensive approach is needed, one that includes rigorous vetting of third-party packages, continuous monitoring of development environments, and fostering a culture of security awareness among developers.
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.
The fight against such sophisticated threats is ongoing, and as we gather more insights into the attacker’s methods and infrastructure, we will continue to share our findings with the community. Together, we can work towards a safer digital future for all.
The xz project, a tool used by many Linux distributions for compressing files, was compromised by a malicious actor who gradually took over the project and inserted a backdoor.
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 for unauthorized 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.
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.
Entrar
