Nisos
Operation Red Card 2.0: Cybercrime Disruption
On February 18, 2026, INTERPOL announced the results of Operation Red Card 2.0, a sweeping multinational law enforcement action targeting online scams across sixteen African countries...
The post Operation Red Card 2.0: Cybercrime Disruption appeared first on Nisos by Nisos
The post Operation Red Card 2.0: Cybercrime Disruption appeared first on Security Boulevard.
The post Software License Scanning vs. Manual License Review: The True Cost of Compliance appeared first on Security Boulevard.
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.
Key takeawaysTenable 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.
FAQWhat 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:
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:
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.
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.
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.
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.
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.
Key takeawaysTenable 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:
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:
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.
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.
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 Type IOC Description Package name ambar-src Name of malicious npm package filename msinit.exe Windows Payload sha256 9b76e275d989ebc3b43911a5e1d2b64ef9544a6b1dbc69a3412bd0ccadaed567 msinit.exe filename f8ca2c8d74f0785c549f09c36147cd0e Linux shell script sha256 8963568963f770e237bff2b228106e4ce7ebb0a1af0e0cf7b26028bdc8515bc5 Linux shell script called “f8ca2c8d74f0785c549f09c36147cd0e” sha256 83e131a2761d6f3a5636cf329182242a927a618174dd440989dc9286be4edeac Linux payload called “osa” sha256 1e6fa5021db4dd40b571cc4e654a71c22d0f607d13fb8a4a5a46a64060f3071e Linux payload of type “NHAS/reverse_ssh” filename 9a8c2a83f66f49b88e36d28894a34009 Mac shell script sha256 521ade4aeb95039e1712f8284eba333199fc819f1e0f9db41d6bc9849b131109 Mac shell script calledWe 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
The post New Malicious npm Package “ambar-src” Targets Developers with Open Source Malware appeared first on Security Boulevard.
As one of the most popular open-source databases, widely used for web applications, MySQL is no stranger to PII and sensitive data. At the same time, its users need production-like data for effective development and testing. Here are the challenges involved in anonymizing MySQL databases and solutions for tackling them.
The post Generating high quality test data for MySQL through de-identification and synthesis appeared first on Security Boulevard.
Figuring out how to dockerize and seed your development mongoDB database for consistent replication across environments might not seem so straightforward. Check out this tutorial highlighting learnings that have worked for Tonic!
The post Dockerize Mongo to get consistent data across your development environments appeared first on Security Boulevard.