Skip to content
securitynpmsupply-chain

Axios supply chain attack: why the advice going around only checks macOS

Dadaist collage on a dark desk — Apple logo with a red checkmark, Windows and Linux logos with red question marks, connected by red string, surrounded by torn code fragments and a broken chain link

After the axios compromise on March 31, 2026, a compact set of shell commands spread through developer chats and social media: blackhole the C2 domain via /etc/hosts, flush the DNS cache, check for a file in /Library/Caches. The advice looks reasonable, thousands of people are reposting it, and there is a kernel of truth in it. But it covers exactly one of the three platforms targeted by the malware, and on the other two it creates a false sense of security: a developer runs the check, finds nothing, and assumes they are clean.

What people recommend — and what is missing

A typical set of commands that spread through chats:

# blackhole C2 domain
echo '127.0.0.1 sfrclak.com' | sudo tee -a /etc/hosts

# flush DNS cache
sudo dscacheutil -flushcache

# check for IoC — if this file exists, the machine is compromised
ls /Library/Caches/com.apple.act.mond

Blackholing the domain via /etc/hosts is a sensible but partial measure. The C2 server has a known IP address (142.11.206.73), and if the malware contacts it directly, bypassing DNS, the domain block does nothing. For proper protection, the IP itself needs to be blocked at the firewall level.

dscacheutil -flushcache is a command that exists only on macOS. On Windows and Linux it is meaningless, and developers copying the advice on those platforms will simply get an error.

Checking /Library/Caches/com.apple.act.mond is a valid indicator of compromise, but exclusively for macOS. On Windows the malware drops different artifacts in different directories; on Linux, yet another set. A developer who runs ls /Library/Caches/com.apple.act.mond on a Linux machine will find nothing and draw the wrong conclusion.

The main problem, however, is different: the advice skips the first step — checking which version of axios is installed. If it is not 1.14.1 or 0.30.4, no further checks are needed. This step is trivial (npm ls axios), yet people skip it and go straight to searching for artifacts on disk.

To understand which artifacts to look for on each platform, it helps to understand how the attack itself worked.

What happened

The attacker prepared for at least 18 hours, hit two major release branches simultaneously, and built self-destruction into the dropper itself. Timeline in UTC:

March 30, 05:57 — a package [email protected] appears on npm from the account nrwise (email: [email protected]). Version 4.2.0 is clean, no malicious code. It is a decoy: the package is registered in advance so that by the time of the attack it looks like an ordinary dependency.

March 30, 23:59[email protected] is published. This version contains a postinstall script with a cross-platform RAT dropper.

March 31, 00:05 — Socket Research’s automated malware detection fires six minutes after the publication of [email protected].

March 31, 00:21 — from the hijacked account jasonsaayman, the primary axios maintainer, [email protected] is published. A dependency on [email protected] is added to package.json. The publication goes through npm CLI directly, bypassing the project’s GitHub Actions CI/CD pipeline.

March 31, 01:00 — a second poisoned version, [email protected], is published on the 0.x branch. Both branches are compromised within 39 minutes.

March 31, 03:15 — npm pulls both axios versions.

March 31, 04:26 — a security hold is placed on the package; clean stubs are published.

The attacker compromised the jasonsaayman account via a stolen long-lived npm token, changed the email to [email protected], and published the packages manually, bypassing CI/CD.

How the malware works

The dependency plain-crypto-js is never imported anywhere in the axios source code. Its only purpose is to execute a postinstall script, setup.js, when the package is installed. The script uses two-layer obfuscation: reversed Base64 and XOR encryption with the key OrDeR_7077.

After deobfuscation, the dropper detects the platform and downloads the corresponding payload from the C2 server sfrclak.com:8000 (IP: 142.11.206.73). The traffic is disguised as requests to the npm registry — POST bodies contain strings like packages.npm.org/product0, product1, product2 to identify the platform.

After execution, the dropper deletes itself and replaces its own package.json with a clean version from a pre-staged file called package.md, making forensic analysis harder.

macOS

The dropper launches AppleScript, which downloads a binary to /Library/Caches/com.apple.act.mond, disguising it as an Apple system daemon. The binary is a full-featured RAT: command execution, binary injection, filesystem enumeration. The process detaches from its parent and runs in the background.

Windows

The mechanism is more complex and uses three components. First, the dropper copies powershell.exe to %PROGRAMDATA%\wt.exe, disguising it as Windows Terminal — a known EDR evasion technique. Then a VBScript file %TEMP%\6202033.vbs is created and launched via cscript //nologo in a hidden window. The VBScript downloads a PowerShell payload to %TEMP%\6202033.ps1 and executes it with -WindowStyle Hidden -ExecutionPolicy Bypass flags.

The critical detail: the VBS file self-deletes after execution (del "%TEMP%\6202033.vbs" /f). This means the temporary files in %TEMP% may be absent even on a compromised machine. The persistent artifact is wt.exe — it is created once and survives reboots.

Linux

The dropper downloads a Python script to /tmp/ld.py and executes it. The payload functions as a RAT similarly to the macOS version.

How to actually check

Step 0: check your axios version

Before searching for files on disk, find out whether the compromised version was even installed:

npm ls axios

If the output does not show version 1.14.1 or 0.30.4, your project is not affected. If you use a monorepo, check all workspaces. If you have multiple projects, check each one.

macOS

# check for the RAT binary
ls -la /Library/Caches/com.apple.act.mond

# check if the process is running
ps aux | grep com.apple.act.mond | grep -v grep

# check network connections to C2
lsof -i -nP | grep 142.11.206.73

If the file exists or the process is running, the machine is compromised.

Windows (PowerShell)

# check for the persistent artifact (primary indicator)
Test-Path "$env:ProgramData\wt.exe"

# check for temporary files (may be absent — they self-delete)
Get-ChildItem $env:TEMP -Filter '6202033.*' -Force -ErrorAction SilentlyContinue

# check network connections to C2
Get-NetTCPConnection | Where-Object { $_.RemoteAddress -eq '142.11.206.73' }

If wt.exe exists, the machine is compromised. The absence of 6202033.* files does not guarantee safety: they self-delete after execution.

Linux

# check for the payload
ls -la /tmp/ld.py

# check for running Python processes
ps aux | grep ld.py | grep -v grep

# check network connections to C2
ss -tnp | grep 142.11.206.73

Network level (all platforms)

Regardless of the OS, check whether there have been connections to the C2 server:

# block both the domain and the IP
# domain:
echo '127.0.0.1 sfrclak.com' | sudo tee -a /etc/hosts
# IP — at the firewall level (iptables, pf, Windows Firewall)

What to do if compromised

If any of the checks above returned a positive result:

  1. Disconnect the machine from the network — pull the cable, turn off Wi-Fi. Do not shut down the machine: data in RAM may be needed for investigation.

  2. Rotate all secrets the machine had access to: API keys, tokens, database passwords, SSH keys, AWS/GCP/Azure credentials. The malware exfiltrated environment variables, so anything stored in environment variables or .env files should be considered compromised.

  3. Downgrade axios to a safe version: 1.14.0 (for the 1.x branch) or 0.30.3 (for the 0.x branch).

  4. Remove persistent artifacts: wt.exe on Windows, com.apple.act.mond on macOS.

  5. Check cron / Task Scheduler for suspicious entries — the RAT may have set up autostart.

Conclusion

An incomplete security instruction is worse than no instruction, because it creates an illusion of verification. A developer on Windows runs three macOS commands, finds nothing, and is confident they are not affected. Before reposting security advice, it is worth reading it through and asking one question: does this work on my platform?


Sources: Socket Research, StepSecurity, Aikido, The Hacker News, Snyk, Wiz