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.
October 2024 heralded a new chapter in supply chain security challenges, characterized by innovative attack techniques and cryptocurrency-focused threats. A groundbreaking entry point exploitation technique affecting multiple package ecosystems was unveiled, while the NPM ecosystem witnessed the first-ever use of Ethereum smart contracts for malware C2 infrastructure. The month also saw multiple sophisticated attacks on cryptocurrency wallets through PyPI packages and a notable compromise of the popular lottie-player package, despite 2FA protections, highlighting the increasing complexity of supply chain security threats.
Let’s delve into some of the most striking events of October:
This New Supply Chain Attack Technique Can Trojanize All Your CLI Commands
A new supply chain attack technique exploits entry points in various programming ecosystems, allowing attackers to trojanize CLI commands. This stealthy method poses risks to developers and enterprises, bypassing traditional security checks. (Link to report).
With 2FA Enabled: NPM Package lottie-player Taken Over by Attackers
NPM package lottie-player compromised via leaked automation token, bypassing 2FA. Malicious versions injected code to trick users into connecting crypto wallets. Swift response: safe version released, compromised versions unpublished. (Link to report).
Crypto-Stealing Code Lurking in Python Package Dependencies
A sophisticated cyber attack on PyPI targeted cryptocurrency wallets through malicious packages. The attack used deceptive strategies, distributed malicious code across dependencies, and only activated when specific functions were called, making detection challenging. (Link to report).
Cryptocurrency Enthusiasts Targeted in Multi-Vector Supply Chain Attack
A malicious PyPI package “cryptoaitools” targeted cryptocurrency enthusiasts through a multi-vector supply chain attack. It used deceptive GUI, multi-stage infection, and comprehensive data exfiltration to steal crypto-related information from Windows and macOS users. (Link to report).
Supply Chain Attack Using Ethereum Smart Contracts to Distribute Multi-Platform Malware
A sophisticated NPM supply chain attack uses Ethereum smart contracts for C2 distribution. The cross-platform malware, targeting popular testing packages, affects Windows, Linux, and macOS through Typosquatting and preinstall scripts. (Link to report)
Our team will continue to hunt, squash attacks, and remove malicious packages in our effort to keep the open-source ecosystem safe.
I encourage you to stay up to date with the latest trends and tactics in software supply chain security by tuning into our future posts and learning how to defend against potential threats.
As part of our ongoing security efforts, we continuously monitor and detect malicious packages within various software ecosystems. Recently, we uncovered a unique supply chain attack through the NPM package “jest-fet-mock,” which implements a different approach using Ethereum smart contracts for command-and-control operations. The package masquerades as a popular testing utility while distributing malware across Windows, Linux, and macOS platforms. This discovery represents a notable difference in supply chain attack methodologies, combining blockchain technology with traditional attack vectors in a way not previously observed in npm. jest-fet-mock was the first package identified in a larger ongoing campaign targeting the npm ecosystem. Additional packages connected to this campaign were later reported by security firms Phylum and Socket.
Key Findings
First observed instance of malware utilizing Ethereum smart contracts for C2 server address distribution in the NPM ecosystem.
Typosquatting attack targeting developers by impersonating two legitimate, popular testing packages.
Cross-platform malware targeting Windows, Linux, and macOS development environments.
Uses NPM preinstall scripts to execute malicious code during package installation.
Performs info-stealing actions while establishing persistence mechanisms across infected systems.
The Art of Impersonation
The malicious package “jest-fet-mock”, published in mid-October, was designed to impersonate two legitimate and widely used JavaScript testing utilities.
The first, “fetch-mock-jest” (~200K weekly downloads), is a wrapper around fetch-mock that enables HTTP request mocking in Jest environments.
The second, “Jest-Fetch-Mock” (~1.3M weekly downloads), provides similar functionality through Jest’s native mocking capabilities.
Both legitimate packages are tools for testing HTTP requests in JavaScript applications. The attacker used a classic typosquatting technique by misspelling “fetch” as “fet” while maintaining the key terms “jest” and “mock”. Given that the legitimate packages are primarily used in development environments where developers typically have elevated system privileges, and are often integrated into CI/CD pipelines, we believe this attack specifically targets development infrastructure through the compromise of testing environments.
Attack Flow
Blockchain-Based Command & Control
Etherscan transaction details showing the smart contract’s getString method returning the C2 server address
The most distinctive aspect of this attack is how it leverages the Ethereum blockchain for its command-and-control infrastructure. When executed, the malware interacts with a smart contract at address “0xa1b40044EBc2794f207D45143Bd82a1B86156c6b”. Specifically, it calls the contract’s “getString” method, passing “0x52221c293a21D8CA7AFD01Ac6bFAC7175D590A84” as a parameter to retrieve its C2 server address.
By using the blockchain in this way, the attackers gain two key advantages: their infrastructure becomes virtually impossible to take down due to the blockchain’s immutable nature, and the decentralized architecture makes it extremely difficult to block these communications.
Understanding the Smart Contract Mechanism
Think of a smart contract on the Ethereum blockchain as a public bulletin board — anyone can read what’s posted, but only the owner has the ability to update it. The attackers in this case deployed such a contract, using it to store their C2 server address. Every time the malicious package is installed on a new system, it checks this bulletin board to find out where to download the actual malware. What makes this approach particularly effective is its flexibility. Instead of hardcoding server addresses in their malware, the attackers can simply update their smart contract whenever they need to point to a new server. This means that even if defenders successfully block one C2 server, the attackers can quickly switch to a new one by updating their contract, and all new infections will automatically connect to the new location.
Initial Execution
The attack chain begins during the npm package installation process through the preinstall script. This script determines the host operating system and constructs a platform-specific URL to download the appropriate payload. The malware then spawns a detached process, ensuring the malicious code continues running independently of the installation process.
Multi-Platform Malware
Our analysis revealed distinct malware variants designed for:
Windows (SHA-256: df67a118cacf68ffe5610e8acddbe38db9fb702b473c941f4ea0320943ef32ba),
Linux (SHA-256: 0801b24d2708b3f6195c8156d3661c027d678f5be064906db4fefe74e1a74b17),
and macOS (SHA-256: 3f4445eaf22cf236b5aeff5a5c24bf6dbc4c25dc926239b8732b351b09698653).
Notably, as of this writing, none of these files have been flagged as malicious by any security vendors on VirusTotal.
The malware variants demonstrated various capabilities including system reconnaissance, credential theft, and establishing persistence through platform-specific mechanisms — using AutoStart files in Linux and Launch Agent configuration (~/Library/LaunchAgents/com.user.startup.plist) in macOS.
Throughout their operation, all variants maintain consistent communication with the attacker’s C2 server, showcasing a coordinated cross-platform attack strategy aimed at compromising development environments.
Impact
By targeting development tools and testing utilities, attackers gain potential access to not only individual developer machines but also CI/CD pipelines and build systems. The use of blockchain technology for C2 infrastructure represents a different approach to supply chain attacks in the npm ecosystem, making the attack infrastructure more resilient to takedown attempts while complicating detection efforts.
The cross-platform nature of the malware, coupled with the fact that no security vendors have flagged these files as malicious on VirusTotal at the time of writing, makes this an actively dangerous threat to development environments.
Conclusion
The discovery of “jest-fet-mock” reveals how threat actors are finding different ways to compromise the software supply chain. This case serves as an important reminder for development teams to implement strict security controls around package management and carefully verify the authenticity of testing utilities, especially those requiring elevated privileges.
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.
July 2024 saw a surge in reports from multiple security firms detailing North Korean threat actors targeting developers through malicious npm packages. These reports highlight the continuation and intensification of a campaign that has been ongoing for close to a year now. While the core structure of the malicious code has remained remarkably similar throughout the campaign, the threat actors have been consistently evolving their social engineering tactics to increase their chances of compromising target systems.
Key Points
Multiple security firms reported North Korean threat actors publishing malicious npm packages throughout July 2024, indicating an intensification of an ongoing campaign.
Despite the campaign’s year-long duration, the structure of the malicious code within the packages has remained notably consistent.
The latest tactic involves mimicking trusted and popular npm packages with added malicious functionality, to make the package appear more legitimate and challenging to detect.
Our research team is actively tracking additional undisclosed packages linked to this campaign.
The campaign by North Korean threat actors to target developers through malicious npm packages has been ongoing since at least September 2023.
However, July 2024 saw an uptick in activity and subsequent reports from security firms including Phylum, Stacklok, and Datadog. These reports, along with our own ongoing research, provide a comprehensive view of the threat landscape and the persistent nature of this campaign.
Campaign timeline
Throughout the year-long campaign, North Korean threat actors have consistently published malicious packages on the npm registry.
Typically, when packages are removed by npm, they retain a placeholder on the registry containing the package’s name.
These NK malicious packages are often live for only a short period, sometimes just a few hours, before being unpublished by the attackers themselves. This swift self-removal appears to be a deliberate tactic to evade detection and potential removal by npm’s security measures. Notably, because the attackers unpublish the packages rather than having them removed by npm, no placeholder containing the package’s name is retained in the registry. This means that security researchers and developers searching for these packages on the npm registry will find no mention of them, effectively erasing their malicious history
Typical structure of the code
A key characteristic of this campaign has been the consistency in the structure of the malicious code within the packages.
Despite minor variations in file names, URLs, and decryption keys, the overall functionality and execution flow have remained largely unchanged. This consistency suggests that the attackers are relying on a proven technique, making only small modifications to evade detection.
While the malicious code structure has remained consistent, the social engineering tactics used to lure developers into downloading and installing these packages have continuously evolved. The threat actors have employed various methods, from creating fake job interviews to impersonating legitimate development workflows, each time adapting their approach to exploit the trust within the open-source community.
Typical execution flow
The typical execution flow of these packages includes checking the operating system (usually targeting Windows), downloading a file from a remote server, decrypting the file (often using XOR operation), executing the decrypted file (commonly using rundll32), and cleaning up traces of the attack.
In the most recent packages of this campaign the threat actors implemented an approach of mimicking legitimate packages by copying code from popular packages and then mixing malicious components into it. This tactic makes it more challenging to detect the malicious nature of the package at first glance.
CONCLUSION
The persistent and evolving campaign by North Korean threat actors targeting developers through malicious npm packages represents a significant and ongoing threat to the open-source ecosystem.
The surge of activity observed in July 2024 demonstrates that despite increased awareness and defensive measures, these actors remain undeterred and continue to adapt their tactics.
As part of the Checkmarx Supply Chain Security solution, our research team continuously monitors suspicious activities in the open-source software ecosystem. We track and flag “signals” that may indicate foul play and promptly alert our customers to help protect them.
In a recent investigation, we discovered that the Python package, “lr-utils-lib”, contained hidden malicious code. The code, activated upon installation, targets macOS systems and attempts to steal Google Cloud Platform credentials by sending them to a remote server. Additionally, we discovered a link to a fake LinkedIn profile for “Lucid Zenith,” who falsely claimed to be the CEO of Apex Companies, LLC, indicating possible social engineering tactics. Alarmingly, AI search engines, like Perplexity, inconsistently verified this false information, highlighting significant cybersecurity challenges in the digital age.
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.
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.
Checkmarx One customers are protected from this attack.
Tip of the Iceberg: Malicious Python Packages Reveal Extensive Cybercriminal Operation Based in Iraq
Recently, a series of malicious Python packages surfaced on PyPI, uploaded by a user named “dsfsdfds”. These packages contained a malicious script located within the __init__.py file.
Key Points
Recently, malicious Python packages — uploaded to PyPI by user “dsfsdfds” — were found to be exfiltrating sensitive user data without consent, to a Telegram chat bot.
The Telegram bot is linked to multiple cybercriminal operations based in Iraq. The bot has activity dating back to 2022 and contains over 90,000 messages, mostly in Arabic.
The bot functions also as an underground marketplace offering social media manipulation services. It has been linked to financial theft and exploits victims by exfiltrating their data.
Initially, the malicious packages incident, appeared isolated. However, it is part of a larger, sophisticated cybercriminal ecosystem, emphasizing the importance of thorough investigation and collaboration within the cybersecurity community.
Attack Flow
The malicious script follows a systematic approach to compromise the victim’s system and exfiltrate sensitive data. It begins by scanning the user’s file system and focusing on two specific locations: the root folder and the DCIM folder. The script searches for files during the scanning process, with extensions such as .py, .php, and .zip files, as well as photos with .png, .jpg, and .jpeg extensions.
Once identified, the script sends their file paths, along with the actual files and photos, to the attackers Telegram bot. This all occurs without the end-user’s knowledge or consent.
The following code snippet demonstrates the core functionality of the malicious script:
The inclusion of hardcoded sensitive information, such as the bot token and chat ID, allowed us to gain further valuable insights into the attacker’s infrastructure and operations.
Additional Insights
Further analysis of the Telegram bot to which the exfiltrated data was being sent uncovered additional findings.
The hardcoded “chat_id” and “bot_token” present in the malicious packages allowed us to gain direct access to the attacker’s Telegram bot and monitor its activities. This technique (outlined here) proved to be a valuable tool in understanding the scope and nature of the attack.
This Telegram bot exhibited a significant history of activity. It had records dating back to at least 2022 — long before the malicious packages were released on PyPI, and contained over 90,000 messages.
The messages were primarily in Arabic. Further investigation with GitHub’s “TeleTracker” revealed that the bot operator maintained numerous other bots and was likely based in Iraq.
Initially, the bot appeared to function as a typical underground marketplace, offering various illicit services such as: purchasing Telegram and Instagram views, followers, spam services, and discounted Netflix memberships.
Part of the bot message history, displaying underground market activities
However, upon further examination of the bot’s message history, we found evidence of more sinister activities that appeared to be involved in financial theft. Additional messages suggested they were sent from systems compromised by the harmful Python packages.
Part of the bot message history, displaying evidence of success from the malicious python packages campaign
The discovery of this elaborate Telegram-based cybercriminal operation underscores the importance of thorough and persistent investigation when researching the true extent of such attacks. Especially since the initial malicious packages served as a mere entry point to a much larger criminal ecosystem.
CONCLUSION
The discovery of the malicious Python packages on PyPI and the subsequent investigation into the Telegram bot have shed light on a sophisticated and widespread cybercriminal operation. What initially appeared to be an isolated incident of malicious packages turned out to be just the tip of the iceberg, revealing a well-established criminal ecosystem based in Iraq.
This particular attack vector is not limited to end-users and can indeed impact enterprises as well. While the initial compromise might occur on an individual developer’s machine, the implications for enterprises can be significant. For instance, if a developer within an enterprise unknowingly uses a compromised package, it could introduce vulnerabilities into the company’s software projects.
As the fight against malicious actors in the open source ecosystem persists, collaboration and information sharing among the security community will be critical in identifying and stopping these attacks. Through collective effort and proactive measures, we can work towards a safer and more secure open source ecosystem for all. Our research team is continuously investigating this attack to gain additional insights into the attacker’s modus operandi and will share further findings with the community as they emerge.
As part of the Checkmarx Supply Chain Security solution, our research team continuously monitors suspicious activities in the open-source software ecosystem. We track and flag “signals” that may indicate foul play and promptly alert our customers to help protect them.
Checkmarx One customers are protected from this attack.
Alert: CDN Service “polyfill.io” Used by 100K+ Websites Provided Malicious Code in Responses — Do Not Use It Anymore!
It’s not uncommon for things like domains and open-source projects to change hands. While many such transitions occur without incident, the recent case of Polyfill.io serves as a stark reminder of the inherent risks.
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.
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 do 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.
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.
In December 2023, we reported on how North Korean threat actors, particularly Jade Sleet, have been compromising supply chains through the open-source ecosystem, with one of their key tactics being the exploitation of the public npm registry to distribute malicious packages. Despite the increased exposure and attention brought to this issue by our research and that of others in the field, it is evident that these attackers remain undeterred.
Throughout the first and even second quarter of 2024, we observed the continued publication of malicious packages on NPM, bearing striking similarities to those detailed in our previous blog post. Initially, we believed these packages to be a continuation of Jade Sleet’s campaign in late spring and early summer of 2023. However, new information came to light, making it apparent that a new threat actor was emerging on the scene.
Key Points
Moonstone Sleet, a newly identified North Korean threat actor, has entered the scene, targeting the open-source software supply chain with tactics similar to other well-known North Korean groups.
Among Moonstone Sleet’s key tactics is the distribution of malware through malicious NPM packages, which are published on the public NPM registry, exposing a wide range of developers to potential compromise.
The ongoing activities of Moonstone Sleet, Jade Sleet, and other North Korean state-sponsored actors underscore the constant threat to the open-source ecosystem.
Recent Developments:
In a recent publication, Microsoft shed light on a new rising North Korean threat actor named Moonstone Sleet, which employs various tactics, techniques, and procedures (TTPs) to target companies for financial gain and cyberespionage. With much of These TTPs utilized by Moonstone Sleet closely resemble those employed by other North Korean threat actors
A number of IOCs shared in Microsoft’s blog closely resemble those mentioned in our December blog post and recent publications by Phylum. showing that, in addition to delivering malicious npm packages through freelancing websites and platforms like LinkedIn, Moonstone Sleet has also been attempting to spread their malicious packages through the public npm registry.
This tactic allows them to potentially reach a wider audience and increases the likelihood of their malicious packages being installed by unsuspecting developers.
Differences in Code Style and Structure
The malicious npm packages discovered during the apring and early summer of 2023, affiliated with Jade Sleet, and those found in late 2023 to early 2024, containing IOCs linking them to the Moonstone Sleet group, exhibit distinct code style and structure differences. These differences offer interesting insights into the varying strategies used by different groups when targeting the open-source software supply chain.
Packages attributed to Jade Sleet
Jade Sleet’s packages, discovered throughout summer 2023, were designed to work in pairs, with each pair being published by a separate npm user account to distribute their malicious functionality. This approach was used in an attempt to make it more challenging to detect and trace the malicious activity back to a single source.
The first package in the pair was responsible for creating a directory on the victim’s machine, fetching updates from a remote server, and saving them in a file within the newly created directory. This package laid the groundwork for the second package to execute its malicious payload.
Code of the first package in the pair
The second package, upon execution, would read a token from the file created by the first package. It would then make a request to a specific URL, passing the token as a parameter. The response from this request, likely containing additional malicious code, would be written to another file on the victim’s machine. Finally, the second package would immediately execute this newly written file as a Node.js script, unleashing the full extent of the malicious functionality.
Code of second package in pair
Packages attributed to Moonstone Sleet
In contrast, the packages published throughout late 2023 and early 2024 adopted a more streamlined single-package approach which would execute its payload immediately upon installation.
The malicious payload was encoded within string constants and included OS-specific code, executing only if it detected that it was running on a Windows machine.
Packages published in the last quarter of 2023 and the first quarter of 2024 shared significant similarities, with only minor variations in file names, URLs, and decryption keys.
Despite these minor changes, the malicious payload’s overall structure and functionality remain largely the same, indicating that the attackers are relying on a proven technique while making small modifications to evade detection:
Malicious Payload Execution:
The malicious payload downloads a file from a remote server, decrypts it using a byte-wise XOR operation, renames the decrypted file, and executes it using rundll32. It then cleans up by deleting the temporary files and replacing the malicious package.json with a clean version.
Overall structure of malicious code
Changes in the Attack Flow in Second Quarter of 2024 In the second quarter of 2024, the packages increased in complexity, with the attackers adding obfuscation and having it target Linux systems as well. The following code would be executed if the OS was detected as Linux:
For a more detailed explanation of how the various packages operate, you can refer to our past publications.
The frequent publication of malicious packages on npm by North Korean threat actors underscores the persistent nature of their campaign. By continually adapting their tactics and techniques, they aim to evade detection and enhance their odds of breaching targeted systems.
With the revelation of this new North Korean group, coupled with the recent attacks by Russian and North Korean threat actors and the recent high-profile XZ attack, it has become increasingly apparent that the open-source ecosystem has become a prime target for powerful and sophisticated adversaries. And while the open-source community plays a crucial role in maintaining the security and integrity of the ecosystem, the primary responsibility for ensuring the safety of the software supply chain lies with the companies that consume these packages.
As the fight against malicious actors in the open-source ecosystem persists, collaboration and information sharing among the security community will be critical in identifying and thwarting these attacks. Through collective effort and proactive measures, we can work towards a safer and more secure open-source ecosystem for all.
Instant Breach: Malicious Package Compromise — Victim vs Attacker’s POV
Open-source packages are an indispensable tool for developers. However, the convenience they offer comes with a significant risk: the potential for instant breaches through malicious packages.
Consuming a malicious open-source package is equivalent to an instant breach. No current update strategy can match the speed at which these packages can compromise your systems.
In contrast to vulnerable packages, which pose a passive risk due to coding errors or oversights and only have potential impacts if exploited, malicious packages represent an active, immediate risk. They are designed with harmful intentions, such as stealing sensitive data and deploying backdoors and keyloggers, just to name a few.
Developers installing these malicious packages are often unaware that their systems have been compromised.
The following video demonstrates the simplicity of falling victim to a malicious package. In this example, the attacker infected the victim with a keylogger which automatically sends all keystrokes to the attacker via a webhook:
Unfortunately, current application security controls often focus on known Common Vulnerabilities and Exposures (CVEs). Since malicious packages very rarely receive CVEs, this leaves organizations vulnerable to attacks.
Even Endpoint Detection and Response (EDR) systems are unable to stop malicious package activity or send relevant alerts. Attackers are well aware of this weakness, which is why we are seeing a massive spike in targeted open-source supply chain attacks.
Conclusion
To fortify our defenses against these relentless cyber threats, our goal should be clear: prevent malicious packages from ever penetrating our Software Development Lifecycle (SDLC). The best approach is to screen open-source packages for malware before allowing them into the network.
By proactively addressing this risk, we can protect our systems and data from the instant breaches caused by malicious packages.
As part of the Checkmarx Supply Chain Security solution, our research team continuously monitors suspicious activities in the open-source software ecosystem. We track and flag “signals” that may indicate foul play and promptly alert our customers to help protect them.
In a recent attack campaign, cybercriminals were discovered cleverly manipulating GitHub’s search functionality, and using meticulously crafted repositories to distribute malware.
Key points
GitHub search manipulation: Attackers create malicious repositories with popular names and topics, using techniques like automated updates and fake stars to boost search rankings and deceive users.
Malicious code is often hidden within Visual Studio project files (.csproj or .vcxproj) to evade detection, automatically executing when the project is built.
The attacker had set up the stage to modify the payload based on the victim’s origin, checking specifically if the victim is based in Russia. At this point, we don’t see this ability activated.
The recent malware campaign involves a large, padded executable file that shares similarities with the “Keyzetsu clipper” malware, targeting cryptocurrency wallets.
The malware establishes persistence on infected Windows machines by creating a scheduled task that runs the malicious executable daily at 4AM without user confirmation.
Developers should be cautious when using code from public repositories and watch for suspicious repository properties, such as high commit frequencies and stargazers with recently created accounts.
Exploiting GitHub’s Search Functionality:
Our recent findings reveal a threat actor creating GitHub repositories with names and topics that are likely to be searched by unsuspecting users. These repositories are cleverly disguised as legitimate projects, often related to popular games, cheats, or tools, making it difficult for users to distinguish them from benign code.
To ensure maximum visibility, the attackers employ a couple of clever techniques that consistently place their malicious repositories at the top of GitHub search results.
Automatic updates
By leveraging GitHub Actions, the attackers automatically update the repositories at a very high frequency by modifying a file, usually called “log”, with the current date and time or just some random small change. This continuous activity artificially boosts the repositories’ visibility, especially for instances where users filter their results by “most recently updated,” increasing the likelihood of unsuspecting users finding and accessing them.
Faking Popularity
While automatic updates help, the attackers combine another technique to amplify the effectiveness of their repo making it to the top results.
The attackers employed multiple fake accounts to add bogus stars, creating an illusion of popularity and trustworthiness. This artificially boosts the repositories’ visibility further, especially for instances where users filter their results by “most stars.”
In contrast to past incidents where attackers were found to add hundreds or thousands of stars to their repos, it appears that in these cases, the attackers opted for a more modest number of stars, probably to avoid raising suspicion with an exaggerated number.
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.
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:
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.
In March 2024, the software supply chain faced unprecedented threats, including one of the most advanced supply chain attacks known to date, where an advanced persistent threat actor hid a backdoor in a software package used in many Linux distributions. The Python ecosystem also found itself the target of numerous abuses, while the continued misuse of GitHub repositories for malware distribution persisted. Additionally, Tornado Cash, a decentralized privacy solution and cryptocurrency mixer on the Ethereum blockchain, fell victim to a stealthy attack.
Let’s delve into some of the most striking events of March:
Backdoor Discovered in xz: The Most Advanced Supply Chain Attack Known to Date
In what is probably one of the biggest, most advanced supply chain attacks in recent years was discovered accidentally on Friday 30th of March. The xz project, a tool used by many Linux distributions for compressing files, was compromised by a malicious actor who gradually took over the project and inserted a backdoor, allowing the attackers unauthorized access on systems that have the compromised versions installed. (report)
Over 170K Users Affected by Attack Using Fake Python Infrastructure
A software supply chain attack campaign, involving multiple TTPs, was launched by an attacker. The attacker created malicious open-source tools with clickbait descriptions and distributed a malicious dependency through a fake Python infrastructure, linking it to hijacked popular GitHub projects and legitimate Python packages. Among the victims of this attack was the Top.gg GitHub organization (a community of over 170k users) and several individual developers. The multi-stage malicious payload harvests sensitive and valuable data from infected systems and exfiltrates them to the attacker’s infrastructure. (report)
PyPi Is Under Attack: Project Creation and User Registration Suspended
On Mar 28, 2024–02:16 UTC, the Python Package Index (PyPi) suspended new project creation and new user registration to mitigate an ongoing malware upload campaign. (report)
Tornado Cash Theft Uncovered: Stealthy Attack Quietly Drains Funds from Decentralized Finance Platform for Months
The open-source codebase of Tornado Cash, a decentralized privacy solution and cryptocurrency mixer on the Ethereum blockchain, was compromised by a malicious developer. The attacker secretly embedded malicious JavaScript code within the project’s user interface, which captured and sent users’ private deposit notes to an unauthorized external server. (report)
GitHub Repos used for Distributing Malware
A report that delves into the escalating issue of malware distribution on GitHub, and underscores the diverse methods cybercriminals employ, ranging from attacks on legitimate repositories and social engineering to exploiting GitHub actions. (report)
Our team will continue to hunt, squash attacks, and remove malicious packages in our effort to keep the open-source ecosystem safe.
I encourage you to stay up to date with the latest trends and tactics in software supply chain security by tuning into our future posts and learning how to defend against potential threats.
PyPi Is Under Attack: Project Creation and User Registration Suspended — Here’s the details
A few hours ago, The Python Package Index (PyPi) suspended all new project creation and new user registration to mitigate an ongoing malware upload campaign.
The research team of Checkmarx simultaneously investigated a campaign of multiple malicious packages appearing to be related to the same threat actors.
The threat actors target victims with Typosquatting attack technique using their CLI to install Python packages.
This is a multi-stage attack and the malicious payload aimed to steal crypto wallets, sensitive data from browsers (cookies, extensions data, etc..) and various credentials.
In addition, the malicious payload employed a persistence mechanism to survive reboots.
PyPi Suspended User and Project Creation
A few hours ago, on Mar 28, 2024–02:16 UTC, The Python Package Index (PyPi) added a new website banner and released an official update: “We have temporarily suspended new project creation and new user registration to mitigate an ongoing malware upload campaign”
Evidence of Multiple Malicious Typosquatting Packages
Between March 27 and March 28, 2024, multiple malicious Python packages were uploaded on the Python Package Index (PyPI). These packages most likely created using automation.
The Malicious Payload
The malicious code is located within each package’s setup.py file, enabling automatic execution upon installation.
employed a technique where the setup.py file contained obfuscated code that was encrypted using the Fernet encryption module. When the package was installed, the obfuscated code was automatically executed, triggering the malicious payload.
Upon execution, the malicious code within the setup.py file attempted to retrieve an additional payload from a remote server. The URL for the payload was dynamically constructed by appending the package name as a query parameter.
The retrieved payload was also encrypted using the Fernet module, Once decrypted, the payload revealed an extensive info-stealer designed to harvest sensitive information from the victim’s machine.
The malicious payload also employed a persistence mechanism to ensure it remained active on the compromised system even after the initial execution.
A small piece of the larger script
Summary
The discovery of these malicious Python packages on PyPI highlights the ongoing nature of cybersecurity threats within the software development ecosystem.
This incident is not an isolated case, and similar attacks targeting package repositories and software supply chains are likely to continue.
As this situation unfolds, we will provide updates on any new developments.
Working together to keep the open source ecosystem safe.
The Checkmarx Research team recently discovered an attack campaign targeting the software supply chain, with evidence of successful exploitation of multiple victims. These include the Top.gg GitHub organization (a community of over 170k users) and several individual developers. The threat actors used multiple TTPs in this attack, including account takeover via stolen browser cookies, contributing malicious code with verified commits, setting up a custom Python mirror, and publishing malicious packages to the PyPi registry. This report will cover the attack and the techniques used by the attackers.
Key Points
An attacker distributed a malicious dependency hosted on a fake Python infrastructure by linking it to popular projects on GitHub and legitimate Python packages.
The malicious dependency, masquerading as the popular “colorama” package, contained hidden malware designed to steal sensitive data from infected systems.
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.
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.
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.
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 security researcher 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
Hosting a poisoned “colorama”
The threat actors took Colorama (a highly popular tool with 150+ million monthly downloads), copied it, and inserted malicious code. They then concealed the harmful payload within Colorama using space-padding and hosted this modified version on their typosquatted-domain fake-mirror. This strategy makes it considerably more challenging to identify the package’s harmful nature with the naked eye, as it initially appears to be a legitimate dependency.
GitHub Account Takeover
The attacker’s reach extended beyond creating malicious repositories through their own accounts. They managed to hijack GitHub accounts with high reputations and use the resources under those accounts to contribute malicious commits.
One of the victims is the GitHub account editor-syntax who is also a maintainer of Top.gg GitHub organization and has write permissions to Top.gg’s git repositories.
With control over this trusted account, the attacker made a malicious commit to the top-gg/python-sdk repository using the stolen GitHub identity of editor-syntax. They added to the requirements.txt instructions to download the poisoned version of colorama from their fake Python mirror.
They also used that account to star multiple malicious GitHub repositories to increase their visibility and credibility.
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 Top.gg community (which boasts over 170K members) was also a victim of this attack.
On March 3rd, 2024, users alerted “editor-syntax” on the community’s Discord chat about the malicious activities originating from his 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.
A Needle in a Haystack
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.
Deep Dive into the Malicious 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 contains 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
Nov 2022: Pypi User “felpes” added three packages to the Python Package Index (PyPI) that contained various forms of malicious code.
Feb 01, 2024: The domain pypihosted[.]org was registered by the attacker.
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.
Mar 13, 2024: The attacker registered the domain pythanhosted.org, further expanding their typosquatting infrastructure.
Mar 05, 2024: “felpes” published the malicious package “yocolor” on PyPI, acting as a delivery mechanism for the malware.
Widespread Malware Distribution on GitHub: Recent discoveries, including Apiiro’s report on over 100,000 infected GitHub repositories, highlight a growing trend of using GitHub for malicious purposes.
Diverse Attack Methods: GitHub-based cyber threats employ various sophisticated strategies, including attacks on legitimate repos, social engineering, and exploiting GitHub actions. This variety in attack vectors signifies the adaptability and ingenuity of cyber attackers in exploiting GitHub’s functionalities.
Critical Role of Continuous Monitoring in Cybersecurity: The evolving nature of threats on platforms like GitHub underscores the imperative for robust, continuous monitoring solutions.
Checkmarx’s Proactive Defense Against Supply Chain Cyber Threats: Checkmarx’s Supply Chain Security solution vigilantly monitors malicious activities, swiftly identifying and alerting on suspicious actions in the open source ecosystem to effectively counteract these cyber threats.
Malicious Repo Confusion Campaign
In light of a recent blog released by Apiiro, the cybersecurity landscape is yet again reminded of the innovative ways attackers exploit platforms like GitHub to host and spread malware. Apiiro’s findings reveal a large-scale malicious repo confusion campaign impacting over 100,000 GitHub repositories, shedding light on the evolving tactics of cybercriminals. Interestingly, part of the attackers’ strategy involved creating fake forks to make their repositories seem legitimate, a tactic we have discussed extensively in relation to repository spoofing.
The attacker took the following steps: they first cloned existing repos and infected them with malware loaders. Next, they uploaded them back to GitHub under identical names, automatically forking each one thousands of times. Finally, they covertly promoted them across the web via forums, discord, etc.
This is not an isolated case. The use of GitHub for malicious purposes has been a recurring theme, as evidenced by several incidents in the past.
Attacks on legitimate Repos
A notable method of exploiting GitHub involves attacking legitimate repos. A prime example is an incident in mid-2023 where attackers, leveraging stolen GitHub personal access tokens, impersonated Dependabot, a well-known dependency update helper tool. These tokens bypassed two-factor authentication, allowing malicious code to be committed under the guise of Dependabot. This code aimed to extract sensitive information and inject malware into JavaScript files.
Nation-State Social Engineering using GitHub:
Another tactic is the use of social engineering. In contrast to the scrutiny typically given to public open-source repositories, GitHub’s private repositories provide a more concealed avenue for attackers. A recent discovery revealed how North Korean state actors were using these malicious repos to then integrate into software through social engineering, targeting specific organizations or individuals.
Attacking GitHub Actions for Public Repos
In mid-2023, GitHub user account, pastramahodu, forked nearly 2,000 repositories, with 319,191 total stars combined, as part of a widespread bug bounty hunt attempt for finding misconfigurations in popular project’s CI pipelines. The procedure was most likely automated and created Pull Requests which in some projects triggered the project’s CI pipeline and executed the custom commands. This highlighted the increasing focus on pipeline security as an entry point for supply chain attacks.
Conclusion
The recurring theme across these examples is clear: GitHub, a platform integral to the development community, has become a focal point for cybercriminals looking to exploit the software supply chain. The sophistication and variety of these attacks demonstrate the evolving and persistent nature of these threats. As part of the Checkmarx Supply Chain Security solution, we continuously monitor and detect suspicious activities in the open-source software ecosystem, such as these. We track and flag “signals” that may indicate foul play and promptly alert our customers to help protect them. In the face of these sophisticated attacks, it is more important than ever for developers and organizations to stay alert, regularly review code sources, even from trusted platforms like GitHub, and implement robust security measures.
Entrar
