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.
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.
Entrar
