One line. 400 million monthly downloads as the delivery vehicle.

Shakespeare once said “What’s Past is Prologue” — and with the Axios supply chain attack feels reminiscent of the headline compromises we’ve experienced before, like XZ Utils (2024) and Log4J (2022).

Software Supply Chain attacks are the Achilles’ Heel of cybersecurity and after reviewing the Axios compromise, it’s easy to see why. The complexity and speed with which malicious software finds its way onto the endpoint is alarming, crossing multiple security modalities in seconds: Software Supply Chain Security, Third Party Risk Management, and Endpoint Security. The complex attacks of today do not respect boundaries between teams, which makes the case for prevention that much more important with respect to the attack surface.

How the Attack Worked

This wasn't opportunistic. It was a five-stage operation planned out for nearly 18 hours before a single developer was affected as reported in the fantastic technical analysis by StepSecurity.  

Stage One - Pre-positioning

The attacker created a throwaway npm account and published a clean, functional version of a package called plain-crypto-js: a deliberate impersonation (or typosquat) of the legitimate crypto-js library. No malicious code. No postinstall hook. The purpose was to age the account and establish publishing history long enough to avoid "brand new package" detection flags in security scanners.

Stage Two - Weaponize 

Two moves happened in parallel. The attacker registered the C2 domain sfrclak.com via NameCheap with privacy protection. Simultaneously, a malicious version of plain-crypto-js went live, adding a single obfuscated file — setup.js — configured to execute automatically via a postinstall hook the moment the package is installed. The dropper was two-layer obfuscated, XOR-encrypted, and designed to self-delete after execution.

Stage Three - Deliver

Using a stolen npm access token, the attacker hijacked the account of jasonsaayman - the lead maintainer of Axios - changed the account email to an attacker-controlled ProtonMail address and published two malicious releases: axios@1.14.1 and axios@0.30.4. The Axios source code was untouched. No CVE. No vulnerability. Just one phantom dependency injected into the package manifest.

Stage Four - Execute

The moment a developer runs npm install, npm resolves the dependency tree and installs plain-crypto-js automatically. The postinstall hook fires setup.js — contacting sfrclak[dot]com:8000 and retrieving a platform-specific RAT payload — all before the developer executes a single line of their own code.

Stage Five - Anti-forensics

After execution, setup.js deleted itself, deleted the malicious package.json, and replaced it with a clean stub pre-staged inside the package. Post-infection inspection of node_modules shows a completely clean manifest. npm audit shows nothing.

 

Crossing Onto the Endpoint

At workstation execution (Stage Four) is where the Supply Chain attack vector crosses onto the endpoint.

On Windows, the dropper:

•  Locates powershell.exe and copies it to %PROGRAMDATA%\wt.exe — disguised as Windows Terminal. The name change and path change are deliberate: powershell.exe becomes wt.exe, executing from an unassuming filepath.
• Writes a hidden VBScript that downloads a PowerShell script from the C2 server
• Executes it with -WindowStyle Hidden -ExecutionPolicy Bypass
• Self-deletes every artifact, then swaps the malicious package.json for a clean stub

On macOS, an AppleScript binary is written to /Library/Caches/com.apple.act.mond — deliberately named to blend in with Apple's daemon naming conventions.

On Linux, a Python RAT is dropped to /tmp/ld.py and executed in the background via nohup.

In all three cases, the dropper erases its tracks. Post-infection inspection of node_modules shows a clean manifest. The attack happened, but the evidence is gone - and the RAT may still be running.

Where Detection-first Security Falls Short

This attack was specifically engineered to evade the tools most organizations rely on today.

The Detection Gap

There was a three-hour window where no detection signals existed. During that time, routine actions like running npm install could pull in a compromised package. Detection platforms are highly effective once indicators or behavioral patterns are established, but in early-stage attacks like this, those signals may not yet exist. 

 The use of legitimate system tools, like PowerShell, further blurred the line between normal and malicious activity. This is where an additional preventive layer becomes valuable, ensuring that only explicitly trusted code can execute, regardless of whether it looks like something that's been executed before.

The Process Chain Looked Legitimate

Node.js spawning a shell, a shell invoking PowerShell, PowerShell downloading a script — this is normal developer activity. Behavioral analytics are tuned to avoid false positives in developer environments precisely because this process chain happens constantly. The attack hid in plain sight.

The Renamed Binary Bypassed Execution Controls

Copying powershell.exe to %PROGRAMDATA%\wt.exe is a classic Living off the Land (LOTL) technique.

SCA Caught it Too Late

Software Composition Analysis (SCA)  tools flagged the malicious package, but only after npm removed it. Any organization running SCA in CI/CD got an alert after execution, not before.

Bottom line: Detection-first security assumes you can identify bad behavior after it starts running. Supply chain attacks and LOTL techniques are specifically designed to make that assumption fail.

A Case for Prevention

Open-source software is fundamental to modern technology as is the trust model that makes them dangerous when compromised. 

Preventing untrusted execution is exactly the problem Airlock Digital was built to solve.

Application control with a Deny by Default posture stops this attack before the payload runs. Most notably through the attack chain untrusted code is executed which is foundational for any attack to succeed, on each platform this can be prevented through this simple but elegant security approach:

• Windows: wt.exe executes a VBS and PS1 script in the user's temp folder

• macOS: /bin/zsh executes Applescript

• Linux: Python interpreter executes .py code
  

These files are unsigned, never before seen code and are blocked under a Deny by Default security posture, breaking the attack chain.

Airlock Digital logs every execution attempt, blocked or allowed with full context including: file path, publisher, parent process, user, timestamp. When an incident like this surfaces, you can query your environment and know exactly whether the chain was attempted and stopped. 

 Next Steps

If you're an Airlock Digital customer: Check your Blocked Execution logs for wt.exe executing untrusted PS1 or VBS code. If your endpoints are in Deny by Default stage (Enforcement), this will have been blocked by default. 

Additionally, use the file search feature to search for the presence of the following hash values as reported by Step Security:

axios@1.14.1 · shasum: 2553649f2322049666871cea80a5d0d6adc700ca
axios@0.30.4 · shasum: d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71
plain-crypto-js@4.2.1 · shasum: 07d889e2dadce6f3910dcbc253317d28ca61c766

Source: https://www.stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan 

For others, audit your environment using the indicators of compromise published by Endor Labs and StepSecurity. Check whether axios@1.14.1 or axios@0.30.4 appear in any lockfiles. Treat any machine that installed either version as fully compromised and rotate all credentials — particularly anything with access to cloud environments, source code repositories, or production infrastructure.

The broader question this incident surfaces is whether your current security posture could have stopped this before it ran - or only detected it after. 

  The Brass Tacks

The Axios compromise is a precise, well-staged attack that defeated detection-first security by design. The malicious code executed and erased itself before any signature existed. The process chain mimicked legitimate developer behavior. The forensic evidence was pre-cleaned.

Application control doesn't try to identify bad behavior after the fact. It prevents unauthorized execution from happening in the first place. Virtually every attack requires remote code execution. That's not a subtle distinction, it's the difference between a breach and a blocked attempt.

 Interested in seeing how Airlock Digital protects developer workstations and endpoints across your environment? Request a demo.