The campaign that hacked Axios exposes the fragility of software supply chains

This week the development community of Node.js had to fit in an uncomfortable reminder: the supply chains of the software are as fragile as the people who maintain them. Popular HTTP Axios client leaders published a detailed report on an incident in which attackers managed to compromise a maintenance account and publish two malicious versions of the package in the npm record. These versions, labeled as 1.14.1 and 0.30.4, they introduced a unit calledplain-crypto-jswhich deployed a remote access Trojan capable of running on macOS, Windows and Linux.

The exposure window was short - the malicious versions were in the register about three hours before they were removed - but that short period was enough for projects and environments that downloaded them to be at risk. Axio maintainers have warned that any system that installed these versions during that period should be considered compromised and have recommended rotating credentials and authentication keys. In addition, the affected team erased compromised machines and re-established access while implementing measures to reduce the likelihood that something similar will happen again. You can read the official post-mortem in the Axios repository in GitHub: https: / / github.com / axios / axios / issues / 10636.

What makes this incident particularly disturbing is not just malware itself, but the way the attackers got access: a much-worked social engineering campaign aimed at maintainers. According to the chronicle of those affected, the attack began with the implantation of a legitimate company, replicating its corporate image and creating false profiles that simulated employees and collaborators of the open source ecosystem. From there, they invited developers to a "reliable" Slack space and organized video calls that seemed authentic.

During one of these simulated meetings, the attackers showed a supposed technical error that motivated the installation of a Microsoft Teams update. That "update" was nothing but an installer who deployed a RAT on the maintainer's team, allowing attackers to access authenticated sessions and extract npm credentials. In other words, MFA-based protection was undermined because access materialized from already authenticated sessions. The explanation and analysis of Google Threat Intelligence Group, which attributes the operation to the actor traced as UNC1069, includes more details about the infrastructure used and its parallels with previous campaigns: https: / / cloud / google.com / blog / topics / amenat-intelligence / north-korea-amenat-actor-targets -axios-npm-package.

Security groups that have followed the lead on this activity point out that this is not an isolated attack, but a coordinated and targeted campaign for projects with much dependence on the Node.js. ecosystem The Socket firm, which published an analysis of the attack pattern, has documented how attackers contacted multiple maintainers through LinkedIn, Slack or other platforms and replicated the same operandi mode: invitations to private spaces, meetings with apparently real actors and pressure to install "native" software or run console commands that ended up downloading malware. Socket summarizes its findings and concerns about the impact on high-use packages in this article: https: / / socket.dev / blog / attackers-hunting-high-impact-nodejess-maintainers.

Not all the objectives gave way. Several maintainers shared how they rejected requests to install binaries or run commands, and one of them, Pelle Wessman, showed a capture of the fraudulent message they presented to them - an alleged RTC connection error - and explained that when he refused to run the installer the attackers even tried to convince him to run a curl command to download code. Your testimony is available in LinkedIn and the post-mortem threads: published by Pelle Wessman.

A relevant technical dimension here is that the attackers did not directly modify the source code of the Axios project. Instead they injected a malicious dependence into legitimate packages, a tactic that allows malicious actors to pack harmful code into an apparently reliable update. This strategy underlines why software supply chains, and in particular package repositories, are so attractive: compromising a popular bookstore can amplify an attack on thousands or millions of users.

What can a developer or a team do if you suspect you have installed one of the affected versions? The most immediate and prudent thing is to act as if the system was committed: to assume that tokens, npm credentials and sessions were exposed, and to rotate and revoke them. It is also appropriate to audit the locking files (package-lock.json, yarn.lock) to detect unexpected dependencies, examine installation histories, and review CI / CD logs for unusual activity. For specific npm account management, activate or strengthen the authentication of two factors and review automation tokens is recommended; npm documents good practices and 2FA configuration on its site: https: / / docs.npmjs.com / configuring-two-factor-authentication.

Beyond emergency operations, this episode opens up broader questions about how to protect the open source ecosystem. Maintainers often work with limited resources and receive legitimate requests for collaboration with assiduity; however, the sophistication of these campaigns requires more stringent protocols: identity verification of new collaborators, clearly defined communication channels, maintenance machine hardening practices (dedicated and segregated machines), and publishing processes that minimize the use of personal tokens in favour of short-time credentials or CI flows with minimum permits.

Finally, it should be remembered that actors with financial or state motivations have used similar tactics before, deploying a variety of tools such as backdoors, download and infostealers to collect credentials, cookies and other secrets. Google's attribution to UNC1069 mentions the use of a named variant WAVESHAPER.V2, which connects this incident to patterns observed in previous campaigns against victims of the critical sector and other infrastructure: GTIG analysis.

The lesson is clear and hard: software security is not only a technical problem, it is also a human issue. Protecting high-impact projects requires not only automatic controls, but training, protocols and resources so that those who maintain critical parts are not the weakest link. Meanwhile, if you manage projects that depend on Axios or work with npm packages, check your facilities, take care if the mentioned and broken key and tokens versions were downloaded.

To expand the reading of the incident and its investigation, in addition to Axios' post-mortem and Google's report, you can consult the technical coverage in specialized media, for example in BleepingComputer, which summarizes the attack and its scope: https: / / www.bleepingcomputer.com / news / security / hackers-compromise-axios-npm-package-to-drop-cross-platform-malware /.