New Malicious npm Package "ambar-src" Targets Developers with Open Source Malware

Tenable Research investigated a malicious npm package with around 50,000 downloads in the public registry. We observed various detection-evasion techniques and saw it deploy multiple powerful open-source malware variants.

Introduction 

Tenable Research has conducted an in-depth analysis of a malicious package in the npm public registry called “ambar-src” that was downloaded around 50,000 times before it was removed.

It employs multiple techniques to evade detection, and drops open-source malware with advanced capabilities, targeting developers on Windows, Linux and macOS hosts.

The package was first uploaded on February 13th, and npm users started downloading it right away. A new version containing malicious code was published on February 16th.

Unlike other supply chain attacks targeting the npm registry, such as s1ngularity and Shai-Hulud, in which legitimate packages were compromised, “ambar-src” doesn’t have any valid use cases, meaning all versions of this package must be treated as malicious.

FAQ

What kind of security incident is this?

A malicious npm package was recently uploaded to the npm public registry. The package contains verified malicious code.
The package stealthily executes malicious code during the installation process. It also uses multiple detection evasion techniques, and drops a payload, based on the victim's operating system.

The only initial access vector we have identified is typosquatting of popular npm packages, most likely attempting to mimic the popular package “ember-source”, which has over 11 million downloads.

Unlike security vulnerabilities, which are a potential weak spot or software flaw that might be exploited, a malicious package is a confirmed attack containing harmful code, signifying an immediate security breach.

How to know if I am affected?

To determine if you are affected, inspect your environment for the presence of the “ambar-src” package.

The presence of the package in the filesystem likely means that it was installed using the npm package manager, and therefore, infected the relevant host.

That’s why you should treat any system where it is found as fully compromised, and apply relevant incident response and containment playbooks.

Please refer to the last section of the blog for additional IOCs and details about how Tenable can help you protect yourself.

How does the malware run code?

It abuses npm's preinstall script hook, which is a lifecycle script defined in “package.json” that executes during the package-installation process. 

This means that merely running “npm install ambar-src” (or resolving it as a dependency) is sufficient to trigger the malicious payload, requiring no explicit import or invocation of the package's code by the victim. 

The preinstall script is a file that is part of the npm package itself - “index.js”. It contains a log of legitimate code and various string manipulation utilities, or arithmetic operations utility functions.

However, at the same time it contains code that launches an OS-specific one-liner that kicks off the full infection chain. The one-liner is hex-encoded to make detection and analysis of the malicious code harder.
 

What payload does the malware install?

After the malicious package executes code using a preinstall script, it executes a one-liner shell command that differs based on the operating system the host is running.

In all operating systems, that one-liner is fetching another loader from a remote server and executing it.

For Windows systems, the decoded one-liner looks like this. As you can see, it also uses x-ya[.]ru to download the payload:
 

It downloads and executes a file called “msinit.exe”. It is a fairly small payload of only 400kb.

“msinit.exe” contains encrypted shellcode that is decoded and loaded into memory upon execution of “msinit.exe”.

In Linux systems, although the malicious code identifies the victim’s Linux architecture, it deploys the same one-liner regardless.

Here’s how the decoded hex string one-liner looks like:
 

The one-liner fetches a bash script from x-ya[.]ru and executes it. The bash script that is fetched from the remote URL looks like this:
 

This follows a similar pattern of fetching a payload from a remote server and executing it. However, in this case the malware is fetching an ELF binary from the remote URL, and saving it to the disk as “osa”, and then executing it.

During our own analysis, we identified another Linux ELF file in the memory of “osa” with the hash 83e131a2761d6f3a5636cf329182242a927a618174dd440989dc9286be4edeac
 

Please note that this is an ELF executable file, and not a Windows EXE file as the name suggests.

The binary can be identified as a client of “github.com/NHAS/reverse_ssh”, a reverse shell written in Golang, by inspecting the Golang build metadata: 
 

For macOS systems, the initial hex encoded command line looks like this:
 

It follows a similar pattern by fetching a script from a remote URL and executing it, all while using “nohup” to prevent the malicious code from blocking the installation process. 
The remote URL contains the following script, again fetching a JavaScript payload from a remote URL and executing it using “osascript”

“osascript” is a utility that comes with every macOS computer and that can be used to execute AppleScript or JavaScript for different purposes.

The file that is then fetched from the remote URL (a5aef90) is big, considering it is a JavaScript file: 500kb.

That file is the Apfell payload, which is part of the MythicAgents family of open-source payloads. 
Apfell is written in JavaScript specifically for macOS, and comes with a large set of impressive capabilities including:

• Basic reconnaissance
• Screenshot collection
• Theft of Google Chrome data
• Opening of fake password prompts

How does the malware exfiltrate data?

The initial infection uses the domain “x-ya[.]ru” to download the malicious payloads.
However, after the initial infection, all the different payloads communicate with function.yandexcloud[.]ru.

This is a well known technique (MITRE “Web Service T1102”), where malware uses well-known web services as a command-and-control relay. This technique makes the traffic looks more legitimate and less likely to be blocked by corporate network security solutions.

When did this security incident begin?

The package was first uploaded to the npm public registry on February 13th. However, the first versions of the malware didn’t contain any malicious code. Three days later, specifically at 2026-02-16 12:18:45 UTC, a new version of the package containing malicious code was uploaded to the public registry.

Is it linked to other campaigns?

JFrog Research recently published a blog about a similar malicious package called “eslint-verify-plugin” that was published in a similar timeframe as “ambar-src”.

From our analysis, “ambar-src” looks more mature than “eslint-verify-plugin”, and uses a couple of techniques to make detection harder:

• Hex encoding the malicious command strings
• Publishing multiple versions of the package without any malicious code
• Gaining almost 30k downloads, before publishing the malicious code
• Including legitimate code as part of the package to masquerade the malicious code

In addition, it contains a payload targeting Windows hosts.

What is the impact on a victim of this attack?

If this package is installed or running on a computer, that system must be considered fully compromised. Immediate action is required: all stored secrets and keys on the affected machine should be rotated from a separate, secure computer. 
While the package should be removed, please be aware that because an external entity may have gained full control of the computer, removing the package does not guarantee the elimination of all resulting malicious software.

Has npm addressed this malicious package?

npm removed the package from the public registry at 2026-02-16 17:02:44 UTC, less than five hours after the first version containing the malicious code was published.
In addition, a GitHub Advisory (GHSA), marking this package as malicious, was published.

Do end users need to take any steps to address this in their environment?

End users should check for the presence of the malicious package in their environment using the IOCs we provided.

Which Tenable product can be used to address this security incident and how can it be used to do so? 

Tenable Cloud Security can be used to detect the presence of the malicious package in your cloud environment.

You can do this using the “software” page and looking for a software item with the name “ambar-src”.
 

Any workload with the “ambar-src” package should be considered compromised.

IOCs

Conclusion

We are seeing a rise in the malicious npm packages and supply chain attacks targeting the npm ecosystem, and their sophistication level.

In this blog we have reviewed the malicious package "ambar-src", that despite only being available in the public registry for three days, was downloaded over 50,000 times.

This malicious npm package used a preinstall script to execute code during the installation process. This is a very common technique used by malicious npm packages, and we expect to see more of these in the future.

We identified several intriguing detection evasion techniques used by this malware. In addition we observed it deploying various sophisticated open-source payloads tailored to the host's operating system. 

Although their capabilities differed, each payload was very powerful, potentially leading to a complete compromise of the infected host and subsequent network pivoting.

Learn more about Tenable Cloud Security