- An attacker compromised the npm account of the primary maintainer of Axios and released versions 1.14.1 and 0.30.4 with a phantom dependency, plain-crypto-js, which deployed a cross-platform RAT during installation.
- The malware contacted a C2 server (sfrclak[.]com) and downloaded specific payloads for Windows, macOS, and Linux, performing system reconnaissance, maintaining periodic beacons, and in some cases, establishing persistence.
- The attack, attributed by Google and other researchers to the North Korean actor UNC1069, combined a window of exposure of about three hours with a sophisticated social engineering campaign against the maintainer to steal their credentials.
- Organizations that were able to install the affected versions must commit to taking action, searching for RAT artifacts, rotating credentials, pinning secure versions of Axios, and strengthening their supply chain, CI/CD, and dependency management controls.
The JavaScript development community has just had one of those scares that makes you rethink how much you trust your dependencies, as shown library failure cases. Axios, one of the most widely used HTTP libraries in the ecosystem, was manipulated in npm to distribute a remote access trojan (RAT). through seemingly legitimate versions. The incident lasted only a few hours, but it has made it clear that the software supply chain hangs by a much thinner thread than many thought.
The serious issue is not only that the attackers managed to sneak malware into a package downloaded tens or hundreds of millions of times a week. The real problem is that they did it by hijacking the main maintainer's npm account, publishing "official" versions that looked normal and didn't touch a single line of the Axios source code.All the malicious behavior resided in a phantom dependency specifically designed for the attack.
How Axios' commitment to npm came about
To understand the magnitude of the incident, it is necessary to start with the entry vector. The attacker managed to take control of the npm account of “jasonsaayman”, the main person responsible for Axios, and changed the associated email to an address under his control.hosted on Proton Mail. From that moment on, he had free rein to publish new versions of the package as if he were the maintainer himself.
With those credentials, He uploaded two malicious versions of Axios: 1.14.1 and 0.30.4encompassing both main branches of the project. The releases were made just 39 minutes apart and, according to StepSecurity's analysis, were made directly from npm using a classic long-lived token, completely bypassing the usual CI/CD pipeline based on GitHub Actions.
Eighteen hours before the final blow, The actor had already published a "clean" version related to the malicious dependency on the npm registryThis preliminary step served to generate a history and prevent some automatic controls from triggering when a completely new packet appeared at the time of the attack.
The striking thing is that The attackers did not modify the Axios source code or introduce any visible changes to the GitHub repository.In fact, versions 1.14.1 and 0.30.4 had no corresponding commits or tags on GitHub; they only existed on npm. The essential difference was in the package's published dependency file.
Under normal conditions, Axios only declares three dependencies: follow-redirects, form-data, and proxy-from-env.However, in the compromised versions, a fourth dependency appeared, one that was nonexistent in the project until that moment: plain-crypto-js in its version 4.2.1. This phantom library was not used anywhere in the Axios code, but it included a postinstall script that ran automatically when installing the package with npm, pnpm, or similar tools.
plain-crypto-js: the phantom dependency deployed by the RAT
The key to the attack lay in that additional dependency. plain-crypto-js was published on npm by a user named “nrwise”, also with a Proton Mail email address, and its sole purpose was to run an obfuscated post-installation script in Node.js (setup.js)That script acted as a dropper, that is, as the initial installer of the second phase of the malware.
By installing Axios in one of its corrupted versions, npm's postinstall lifecycle automatically triggered the plain-crypto-js code without the developer having to do anything special.The dropper connected to a command and control (C2) server active in the sfrclakcom domain, listening on port 8000, and downloaded a payload specific to the operating system of the affected machine; this behavior can be identified by network traffic analysis.
Researchers from StepSecurity and other analysis teams describe very careful behavior. After executing the malicious payload, the dropper removed its own traces: it deleted the postinstall script, replaced the package.json with a "clean" version, and left a node_modules file that, at first glance, seemed harmless.Thus, a subsequent manual inspection did not find the malicious code directly within Axios.
To identify tampering, The only reliable clue was in the lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock) and in the presence of specific versions: axios 1.14.1 or 0.30.4 and plain-crypto-js 4.2.1, in addition to two versions of that package with intermediate numbering (4.2.0, 4.2.2) related in some analyses. Socket, for its part, later detected that the same malware was also distributed through the packages @shadanai/openclaw (various versions 2026.3.xx) and @qqbrowser/openclaw-qbot (0.0.130), and techniques such as honeypots in security They can also help identify similar campaigns.
Cross-platform RAT: Windows, macOS and Linux in the spotlight
Once executed, The setup.js script acted as an orchestrator capable of detecting the operating system and following a platform-specific attack path.The campaign was clearly prepared in advance: according to StepSecurity, the attackers had pre-compiled three separate payloads, one for each system.
On macOS systems, The post-install process launched an AppleScript that downloaded a Trojanized binary from the server sfrclakcom:8000This binary was stored in the path /Library/Caches/com.apple.act.mond, its permissions were adjusted to make it executable, and finally, it was started in the background using /bin/zsh. Once the RAT was running, the AppleScript itself was deleted to further complicate forensic analysis.
On Windows machines, The malware located the system's PowerShell binary, copied it to %PROGRAMDATA%\wt.exe to disguise it as the Windows terminal, and generated a temporary VBScript script.This VBScript contacted the C2 server again to download an additional PowerShell RAT script, executed it, and then deleted the downloaded file. Furthermore, the Windows variant created the %PROGRAMDATA%\system.bat file with a download routine that allowed the malware to be retrieved at each login and added an execution key to the Windows registry to ensure persistence.
On Linux and other Unix-like systems other than macOS, The dropper used Node.js's execSync to launch a shell command that downloaded a Python script from sfrclakcom, saved it as /tmp/ld.py, and executed it with nohup to keep it running in the background.Unlike Windows, this variant did not show a consolidated persistence mechanism, indicating a more focused approach to rapid data exfiltration or the occasional deployment of persistence via subsequent commands.
SafeDep and Elastic Security Labs analyzed second-level loads and concluded that The RATs for macOS (C++ Mach-O binary) and Linux (Python script) shared the same command set, C2 protocol, message format, and operational behaviorThis type of analysis often relies on scanning services such as VirusTotal, which facilitate the correlation of samples and IOC.
In all cases, Each compromised host performed an immediate system reconnaissance: user directories, drive roots, active processes, and other metadata.This information was sent to the command and control server and the agent maintained a beacon loop of about 60 seconds, waiting for new instructions, including the execution of additional scripts or the injection of binaries into memory.
Exposure window, objectives, and attribution to North Korea
The malicious versions of Axios were available on npm for approximately three hours, during a carefully chosen time frame. The compromised packages were released just before midnight on Sunday (at a time that maximized the defenders' reaction time), and the incident was contained by early Monday morning., after security companies alerted authorities to the anomalous behavior.
During that relatively short interval, Huntress detected at least 135 systems that connected to the attacker's server.Given that Axios records more than 80-100 million weekly downloads (according to various sources, even more than 300 million in some periods), that number probably only represents the tip of the iceberg, limited to the systems that come on the radar of the analytics firms that have made their data public.
Google, through its Threat Intelligence team, He attributed the attack to a suspected North Korean actor labeled UNC1069Elastic Security Labs reinforced this hypothesis by finding a strong similarity between the RAT delivered in macOS and WAVESHAPER, a C++ backdoor discovered by Mandiant and also linked to the same threat group.
Google analysts emphasized that North Korean-affiliated groups have spent years specializing in supply chain attacks and cryptocurrency theft operations.The pattern fits: compromising development infrastructures, widely used libraries, or trusted software to move laterally toward targets where economic assets, private keys, or high-value credentials are managed.
Several reports also highlighted that The restraint and design of the attack gave the impression of a well-coordinated team.Three parallel implementations of the same RAT (PowerShell, C++, and Python), a consistent C2 protocol, almost identical behavior across all variants, and a clear self-cleaning strategy to avoid leaving traces. Elastic emphasized that this consistency points to a single developer or a group working on a shared design document, far removed from improvisation.
Beyond the purely technical aspect, one of the most disturbing points of the case is how the main maintainer's npm account was hijacked. The head of Axios himself later explained that he had two-factor authentication enabled on almost all of his services And yet, he ended up granting access without realizing it.
According to the post-mortem analysis shared by the team, The attackers mounted a highly elaborate social engineering operation, supported by AI-powered tools, to gain their trust.They impersonated the founder of a company, copying its visual identity, photograph, and even the corporate branding. They created a real Slack space with the company logo, channels with posts supposedly synced with LinkedIn, and even fake profiles of employees and other open-source software maintainers.
Within that environment, They scheduled a meeting via Microsoft Teams in which a whole group of professionals appeared to participate.During the meeting, they simulated a technical problem and indicated that he had an outdated component of his system. The maintenance technician, assuming it was a legitimate requirement related to the videoconferencing tool itself, downloaded and installed the suggested file.
That file was, in reality, The remote access Trojan allowed attackers to pivot to the attackers' credentials and ultimately take control of the npm account used to publish Axios.The whole process was so well orchestrated, with so many believable details, that the victim described it as "perfectly coordinated, professional and completely convincing".
This human component of the incident makes it clear that Even technical measures like 2FA are not enough when high-level social engineering is combined with visual impersonation, deepfakes, or detailed cloning of organizations.The weakest link is, once again, human interaction.
Impact on organizations and developers using Axios
From a practical point of view, the main problem is determining who was actually affected. Any organization that installed axios@1.14.1 or axios@0.30.4 during the window in which they were available should assume that the machine or pipeline that performed the installation may be compromised..
The recommendations from firms like StepSecurity, Aikido, Huntress or Elastic are compelling. In case of suspicion, commitment must be taken and not simply "delete and reinstall node_modules"The prudent course of action is to rebuild the affected machines or environments from trusted images and carefully review the CI/CD logs to identify which jobs or pipelines may have run the manipulated versions.
Furthermore, It is critical to rotate all credentials and secrets that the RAT may have accessed from those nodesnpm tokens, cloud provider keys, pipeline secrets, database credentials, SSH keys, etc. Leaving these credentials in circulation after such an attack leaves the door open for silent lateral movement.
At a technical level, Teams should review their lock files (package-lock.json, pnpm-lock.yaml, yarn.lock) for references to compromised versions of Axios and plain-crypto-jsIf these items appear, the next step is to inspect for possible RAT artifacts on the affected systems: /Library/Caches/com.apple.act.mond on macOS, %PROGRAMDATA%\wt.exe and %PROGRAMDATA%\system.bat on Windows, or /tmp/ld.py on Linux.
In parallel, It is recommended to explicitly set safe versions of Axios, such as 1.14.0 and 0.30.3, and use overrides or resolutions mechanisms to prevent transitive dependencies from resolving to unintended versions.Blocking outbound traffic to the sfrclakcom domain is also a sensible containment measure, at least while the full scope of the attack is being analyzed.
Security lessons for the software supply chain
The Axios incident is not an isolated event, but another link in a chain of supply chain attacks that includes cases such as SolarWinds, Kaseya, 3CX, Polyfill.io or vulnerabilities exploited in Log4j. The core idea is always the same: to compromise a widely used, trusted piece of equipment to maximize reach, instead of trying to attack machine by machine.
One of the lessons most often repeated by experts is that Trust cannot rest solely on the popularity of a bookstore or the reputation of a maintainerIf the deployment channel (the npm account, the CI/CD pipeline, the build infrastructure) is compromised, everything deployed through it inherits that risk. Manual code review is also insufficient if the malware hides in transitive dependencies and deletes itself after execution.
It has also been highlighted that The "default speed" in dependency updates comes at a cost in attack surface areaAutomatically adopting the latest version is incredibly convenient, but it opens the door for malicious updates to spread in minutes. Some organizations are already considering policies such as requiring a new version to have been in the ecosystem for a certain period before adoption, or requiring changes to critical packages to undergo additional manual review.
Regarding development infrastructure, CI/CD environments should be treated as highly sensitive assetsAny RAT that runs during dependency installation will almost certainly search for pipeline secrets and access to other environments. Segmenting these nodes, monitoring them more closely, and rotating their secrets periodically is no longer just an "ideal" recommendation, but a necessity.
Lastly, Detecting these types of attacks requires combining information from multiple sources: installed versions, lockfiles, indicators of compromise in the operating system, and network telemetry.Tools that generate and manage SBOMs (Software Bill of Materials) help to quickly trace which projects use which packages, something vital when massive alerts like this one occur.
This whole episode with Axios illustrates the extent to which the ecosystem of dependencies, however mature and consolidated it may seem, still relies heavily on trust and constant vigilance. A seemingly innocuous library, maintained by a single person who is the victim of a clever social engineering maneuver, can become in a matter of hours a global vector for deploying cross-platform RATs in companies, freelancers, and organizations of all sizes.Strengthening controls around publishing accounts, pipelines, and critical dependencies is no longer an optional good practice, but a condition for continued development in an environment where attackers are increasingly patient, resourceful, and have better tools.
Table of Contents
- How Axios' commitment to npm came about
- plain-crypto-js: the phantom dependency deployed by the RAT
- Cross-platform RAT: Windows, macOS and Linux in the spotlight
- Exposure window, objectives, and attribution to North Korea
- Advanced social engineering against the Axios maintainer
- Impact on organizations and developers using Axios
- Security lessons for the software supply chain