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 FindingsAn attacker published a malicious package that mirrors an example from React Native’s official documentation, in an attempt to trick developers fol
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.
Dozens of Machines Infected: Year-Long NPM Supply Chain Attack Combines Crypto Mining and Data TheftThrough our continuous monitoring of software supply chain threats, the Checkmarx Research team identified a supply chain attack that has remained active for over a year. The package, @0xengine/xmlrpc, began its life as a “legitimate” XML-RPC implementation in October 2023, but strategically transformed into a malicious tool in later versions and has remained active through November of 2024. This
Dozens of Machines Infected: Year-Long NPM Supply Chain Attack Combines Crypto Mining and Data Theft
Through our continuous monitoring of software supply chain threats, the Checkmarx Research team identified a supply chain attack that has remained active for over a year. The package, @0xengine/xmlrpc, began its life as a “legitimate” XML-RPC implementation in October 2023, but strategically transformed into a malicious tool in later versions and has remained active through November of 2024. This discovery serves as a stark reminder that a package’s longevity and consistent maintenance history do not guarantee its safety. Whether initially malicious packages or legitimate ones becoming compromised through updates, the software supply chain requires constant vigilance — both during initial vetting and throughout a package’s lifecycle.
Key Findings
A malicious NPM package masquerading as an XML-RPC implementation has maintained an unusually long presence on the NPM registry from October 2023 to November 2024, receiving 16 updates during this period.
The package started as a “legitimate” XML-RPC implementation and strategically introduced malicious code in later versions.
The malware steals sensitive data (SSH keys, bash history, etc..) every 12 hours while mining cryptocurrency on infected systems. Data is exfiltrated through Dropbox and file.io.
The attack achieved distribution through multiple vectors: direct NPM installation and as a hidden dependency in a legitimate-looking repository.
Evasion techniques include system monitoring detection and activity-based mining
At the time of investigation, it appeared that up to 68 compromised systems were actively mining cryptocurrency through the attacker’s Monero wallet.
Package History and Evolution
The malicious package “@0xengine/xmlrpc” first appeared on the NPM registry on October 2nd, 2023, presenting itself as a pure JavaScript XML-RPC server and client implementation for Node.js.
What makes this package particularly interesting is its strategic evolution from legitimate to malicious code. The initial release (version 1.3.2) and its immediate follow-up appeared to be legitimate implementations of XML-RPC functionality. However, starting from version 1.3.4, the package underwent a significant transformation with the introduction of malicious code in the form of heavily obfuscated code within the “validator.js” file.
Part of the obfuscated code
Over its year-long presence on NPM, the package has received 16 updates, with the latest version (1.3.18) published on October 4th, 2024. This consistent update pattern helped maintain an appearance of legitimate maintenance while concealing the malicious functionality.
Distribution Strategy
Our research uncovered a calculated supply chain attack involving two distribution vectors. The first involves direct installation of @0xengine/xmlrpc from NPM. The second, more sophisticated approach, involves a GitHub repository named “yawpp” (hxxps[:]//github[.]com/hpc20235/yawpp), which presents itself as a WordPress posting tool.
The yawpp repository appears legitimate, offering functionality for WordPress credential checking and content posting. It requires @0xengine/xmlrpc as a dependency, claiming to use it for XML-RPC communication with WordPress sites. This dependency is automatically installed when users set up the yawpp tool through standard npm installation.
This strategy is particularly effective as it exploits the trust developers place in package dependencies, potentially leading to inadvertent installation of the malicious package through what appears to be a legitimate project dependency.
The combination of regular updates, seemingly legitimate functionality, and strategic dependency placement has contributed to the package’s unusual longevity in the NPM ecosystem, far exceeding the typical lifespan of malicious packages that are often detected and removed within days.
Attack Flow
The attack orchestrated through @0xengine/xmlrpc operates through a sophisticated multi-stage approach that combines cryptocurrency mining with data exfiltration capabilities. The malicious functionality, concealed within validator.js, remains dormant until executed through one of two vectors:
Direct package users execute any command with the ‘ — targets’ or ‘-t’ flag. This activation occurs when running the package’s validator functionality, which masquerades as an XML-RPC parameter validation feature.
Users installing the “yawpp” WordPress tool from GitHub automatically receive the malicious package as a dependency. The malware activates when running either of yawpp’s main scripts (checker.js or poster.js), as both require the ‘ — targets’ parameter for normal operation.
This implementation ensures the malware activates through legitimate-looking tool usage, making detection more difficult.
Initial Compromise
Once triggered, the malware begins gathering system information:
Deobfuscated version of the system information gathering code
Following the initial data collection phase, the malware deploys its cryptocurrency mining component with a particular focus on Linux systems. The deployment process involves downloading additional payloads from a Codeberg repository disguised as system authentication services. The mining operation utilizes XMRig to mine Monero cryptocurrency, directing all mining rewards to a predetermined wallet address while connecting to the mining pool.
Deobfuscated configuration revealing the attacker’s Codeberg repository URLs used to fetch mining components
These downloaded components include:
XMRig: The actual cryptocurrency mining software
xprintidle: Used to detect user activity
Xsession.sh: The main script that orchestrates the mining operation
The mining operation is configured with specific parameters targeting Monero:
Monero mining configuration found in the downloaded Xsession.sh script
At the time of our investigation, we observed 68 miners actively connected to this wallet address through the hashvault.pro mining pool, indicating a possible significant number of compromised systems actively mining cryptocurrency for the attacker.
Sophisticated Evasion Mechanisms
The malware implements an advanced process monitoring system to avoid detection. It maintains a list of monitoring tools and continuously checks for their presence.
Deobfuscated version of the process monitoring evasion logic found in Xsession.sh — checks for and terminates mining when system monitoring tools are detected
The malware also carefully monitors user activity through the xprintidle utility. It only initiates mining operations after a specified period of inactivity (default: 1 minute) and immediately suspends operations when user activity is detected. This behavior is controlled by the INACTIVITY_IN_MINS parameter.
Maintaining Persistence
To ensure long-term survival on infected systems, the malware establishes persistence through systemd, disguising itself as a legitimate session authentication service named “Xsession.auth”. This service is configured to automatically start with the system, ensuring the mining operation resumes after system reboots. The malware also implements a daily check-in mechanism, regularly sending system status updates and potentially receiving new commands or configurations.
Deobfuscated systemd service configuration from Xsession.sh used for maintaining persistence
Data Exfiltration Pipeline
The malware implements a comprehensive data collection and exfiltration system that operates continuously. Every 12 hours, it performs a systematic collection of sensitive system information through a “daily_tasks” function found in Xsession.sh:
During each collection cycle, the malware systematically gathers a wide range of sensitive data including:
SSH keys and configurations from ~/.ssh
Command history from ~/.bash_history
System information and configurations
Environment variables and user data
Network and IP information through ipinfo.io
The stolen data is exfiltrated through two channels. One, using the Dropbox API with hardcoded credentials.
Additionally, the malware employs file.io as a secondary exfiltration channel, using a bearer token for authentication and setting automatic file deletion after download to minimize detection risks.
Conclusion
This year-long campaign serves as a stark reminder of the critical importance of thoroughly vetting open-source projects before incorporation into any software development process. Projects can be malicious from the start, maintaining a long-term presence while hiding their true nature, or legitimate projects can later become compromised and introduce malicious code through updates.
This dual threat emphasizes why developers and organizations must remain vigilant not only during initial vetting but also in monitoring package updates, implementing robust security measures, and conducting regular audits of their dependencies to mitigate the risks associated with supply chain attacks.
As part of the Checkmarx Supply Chain Security solution, our research team continuously monitors suspicious activities in the open-source software ecosystem. We track and flag “signals” that may indicate foul play, including suspicious entry points, and promptly alert our customers to help protect them from potential threats.
Checkmarx One customers are protected from this attack.
For over a year, a persistent malware campaign has been targeting Roblox developers through malicious NPM packages. By mimicking the popular “noblox.js” library, attackers have published dozens of packages designed to steal sensitive data and compromise systems. This campaign exploits trust in the open-source ecosystem, particularly targeting the Roblox platform, an attractive target due to its massive user base of over 70 million daily active users. Despite multiple package takedowns, new malic
For over a year, a persistent malware campaign has been targeting Roblox developers through malicious NPM packages. By mimicking the popular “noblox.js” library, attackers have published dozens of packages designed to steal sensitive data and compromise systems. This campaign exploits trust in the open-source ecosystem, particularly targeting the Roblox platform, an attractive target due to its massive user base of over 70 million daily active users. Despite multiple package takedowns, new malicious packages continue to appear on the NPM registry at the time of publication, requiring developers to remain vigilant against this ongoing threat.
Key Points
Dozens of malicious npm packages mimicking the popular “noblox.js” library have been identified in a campaign dating back to August 2023, with the most recent ones appearing in late August 2024.
The attackers of this campaign have employed techniques including brandjacking, combosquatting, and starjacking to create a convincing illusion of legitimacy for their malicious packages.
The malware’s capabilities include Discord token theft, system information harvesting, system persistence, and deployment of additional payloads such as Quasar RAT.
The malware employs a sophisticated persistence technique by manipulating the Windows registry, causing it to execute every time a user opens the Windows Settings app.
While the identified malicious packages have been removed from npm, the attacker’s GitHub repository containing malicious executables remains active, posing a potential threat for future attacks.
Malware in Disguise: The Social Engineering Aspect
The attackers have employed a multi-faceted approach to craft an illusion of authenticity around their malicious packages.
One deceptive tactic combines brandjacking and combosquatting — two methods that fall under the broader category of typosquatting. This strategy creates the illusion that their packages are either extensions of or closely related to the legitimate “noblox.js” library.
For example: noblox.js-async, noblox.js-thread, and noblox.js-api.
Since libraries commonly have multiple versions or extensions for specific use cases, mimicking this naming pattern increases the likelihood that developers will install the attackers’ packages, assuming they’re official extensions of “noblox.js.”
Another tactic used is starjacking, a popular method attackers employ to fake their package stats. In this instance, the malicious packages were linked to the GitHub repository URL of the genuine “noblox.js” package. This tactic falsely inflates the perceived popularity and trustworthiness of the malicious packages.
The attackers also used tactics to disguise the malware within the package itself. They meticulously mimicked the structure of the legitimate “noblox.js” but introduced their malicious code in the “postinstall.js” file. They heavily obfuscated this code, even including nonsensical Chinese characters to deter easy analysis.
These combined techniques create a convincing façade of legitimacy, significantly increasing the chances of the malicious packages being installed and executed on developers’ systems. As reported in previous analyses by Socket, Stacklok and Reversinglabs, these tactics have been consistently employed and refined throughout the year-long campaign.
Attack Flow
The malicious code exploits NPM’s postinstall hook, ensuring automatic execution when the package is installed. This hook, designed for legitimate setup processes, becomes a gateway for running the obfuscated malware without the user’s knowledge or consent.
At first glance, the obfuscated code appears daunting and impenetrable. However, by simply using an online automated JavaScript deobfuscation tool, we were able to gain significant insight into the malicious code’s operation. This initial deobfuscation revealed the general steps the malware takes to achieve its objectives. Yet, the resulting code still contained confusing elements and required additional cleaning to fully comprehend its functionality. This process of incremental deobfuscation and analysis allowed us to piece together the complete attack flow, with its most notable details listed below.
Discord Token Theft
The malware searches for Discord authentication tokens in multiple locations.
The stolen tokens are then validated to ensure only active ones are exfiltrated.
Antivirus Evasion
The malware aggressively undermines the system’s security measures. It first targets Malwarebytes, attempting to stop its service if running. This is followed by a more comprehensive attack on Windows Defender: the script identifies all disk drives and adds them to Windows Defender’s exclusion list. This action effectively blinds Windows Defender to any file on the system. By disabling third-party antivirus and manipulating built-in Windows security, the malware creates an environment where it can operate freely, significantly increasing its potential for damage and persistence.
Additional Payload Deployment
The malware expands its capabilities by downloading two additional executables from the attacker’s GitHub repository. These files, “cmd.exe” and “Client-built.exe”, are fetched using base64-encoded URLs and saved to the “C:\WindowsApi” directory with randomized names. The malware uses a combination of “nodeapi_” prefix and a unique hexadecimal string, likely to help the malicious files blend in with legitimate system files.
Persistence Mechanism
To ensure long-term access, the malware manipulates a Windows registry key to ensure it runs consistently on the infected system.
Specifically, it adds the path of the downloaded “Client-built.exe” to the strategic registry location:
By modifying this key, the malware hijacks legitimate Windows functionality. As a result, whenever a user attempts to open the Windows Settings app, the system inadvertently executes the malware instead.
Data Exfiltration
Throughout its execution, the malware collects various types of sensitive information from the infected system. This data is packaged and sent to the attacker’s command and control server using a Discord webhook.
QuasarRAT Deployment
The final stage involves deploying QuasarRAT, a remote access tool that gives the attacker extensive control over the infected system.
The Attacker
The second-stage malware originates from an active GitHub repository: https://github.com/aspdasdksa2/callback. As of this writing, the repository remains accessible and potentially in use for distributing malware through other packages. The repository, owned by user “aspdasdksa2”, contains multiple malicious executables. The repository’s continued existence and its content suggest ongoing malware development and distribution.
Notably, the attacker maintains a second repository named “noblox-spoof”, which appears to house the latest malicious npm package content, directly referencing the target of this campaign.
The most recent malicious packages impersonating the popular noblox.js library (four packages published by user “bicholassancheck14” — noblox.js-async, noblox.js-threads, noblox.js-thread, and noblox.js-api) have been taken down after we promptly reported them to npm’s security team. While this is a positive development, it’s important to note that the threat is not entirely neutralized.
We strongly advise the developer community to remain vigilant. The attacker’s continued infrastructure presence and persistence pose an ongoing threat. Developers should exercise caution, particularly when working with packages that resemble popular libraries like noblox.js.
Conclusion
This malware campaign, targeting Roblox developers through npm packages, has persisted for over a year. By mimicking the popular “noblox.js” library, attackers published dozens of malicious packages designed to steal sensitive data and compromise systems.
Central to the malware’s effectiveness is its approach to persistence, leveraging the Windows Settings app to ensure sustained access.
The discovery of these malicious NPM packages serves as a stark reminder of the persistent threats facing the developer community. By masquerading as legitimate, helpful libraries, attackers continue to find new ways to exploit trust within the open-source ecosystem.
This campaign underscores the critical importance of thoroughly vetting packages before incorporation into projects. Developers must remain vigilant, verifying the authenticity of packages, especially those resembling popular libraries, to protect themselves and their users from such sophisticated supply chain attacks.
As part of the Checkmarx Supply Chain Security solution, our research team continuously monitors suspicious activities in the open-source software ecosystem. We track and flag “signals” that may indicate foul play and promptly alert our customers to help protect them.
Checkmarx One customers are protected from this attack.
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 compromisi
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 Perplexi
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.
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, w
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 POVOpen-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 ris
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.
Entrar
