He promised to talk about the most notorious recent attacks on the supply chain, and the…

He promised to talk about the most notorious recent attacks on the supply chain, and the promise must be kept. Let's go 🫡

Recently, two malicious versions of the popular JavaScript library axios appeared briefly in npm ( https://github.com/axios/axios): 1.14.1 and 0.30.4 (for a second, this is one of the most popular libraries for HTTP requests in JS, I talked about it in the last post ( https://t.me/maxienergy_channel/386) spoke). That is, this package is used in a huge number of completely different software and by different developers. And an attack on such a package automatically means that through it you can attack the very software in which it was used

The most interesting thing about this attack is that the attackers hardly got into the Axios source code itself. Instead, the left dependency plain-crypto-js@4.2.1 was mixed into the release (that is, it was transitive to the developers), which is not needed at all for axios to work. This dependency had to be worked out at the installation stage via postinstall and quietly installed on the RAT machine ( https://www.kaspersky.ru/resource-center/definitions/what-is-a-rat-remote-access-trojan) (remote access trojan)

As a result, we get the following scenario: the developer or CI/CD simply does npm install. It doesn’t launch anything manually, doesn’t open anything, doesn’t download any additional files. The package manager itself pulls the dependency, and it executes a malicious script. All. Compromise occurs during the installation phase. Simply because there was initially trust in the official popular package 😏

Based on the analysis ( https://www.stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan) researchers (for which I am also writing this post), the malicious chain was cross-platform and worked against macOS, Windows and Linux. Then the dropper contacted the C2 server and pulled up the second stage, which depended on the platform. Moreover, after launching, the malware tried to clean up its tracks (it removed installation artifacts and masked its behavior)

Why did I decide to talk specifically about the axios case? Because it breaks the illusion of control very well. We may have normal SSDLC, SAST, SCA, code review, good developers, security specialists, etc. And then one compromised publication in npm... and our pipeline itself gives the attacker access to the infrastructure. A little awkward (and offensive)

How to protect yourself from this? Let's figure it out 🤓

Firstly, you can never live on auto-pull dependencies across version ranges. You can't use latest. It's not safe. Determine the package version and use only that

Secondly, we fix the lockfile and install the dependencies through a reproducible installation. The fewer surprises at the install stage, the better you will sleep (otherwise, you will become an alcoholic)

Third, whenever possible, limit or completely disable postinstall execution, where this is acceptable. A lot of dirt in the supply chain comes through them

Fourth, monitor anomalies in the packages themselves and their strange behavior in runtime... although I will talk about this separately at the Merge Conf report (https://tatarstan2026.mergeconf.ru/speakers/development/cyber-security/knyazev) (and later here)

And lastly, the most practical. If you might have axios@1.14.1 or axios@0.30.4 installed at the time of the incident, check, figure it out, and that’s it, don’t worry about it :) But to be honest, treat such hosts and pipelines as potentially compromised. In such a situation, you need to check where exactly the malicious versions were installed, study the network activity of these machines, look for traces of the execution of postinstall scripts and extraneous files (and as quickly as possible re-release and replace secrets, tokens, keys, etc., that could be available on these hosts)

P.S. See you at Merge Conf ( https://tatarstan2026.mergeconf.ru/speakers/development/cyber-security/knyazev) already this Saturday. There I will talk about CBOM and how important it is now to limit the behavior of the packages themselves at runtime. Just the case with axios turned out to be very indicative 🧐