The Axios NPM Supply Chain Attack: What Happened, How to Check If You're Affected, and How to Remediate

All times are UTC:

Time (UTC)	Event
Mar 30, 05:57	[email protected] published to npm — a clean decoy package establishing version history
Mar 30, 23:59	[email protected] published — the malicious version containing the RAT dropper
Mar 31, 00:21	[email protected] published (tagged latest) — adds plain-crypto-js as a dependency
Mar 31, 01:00	[email protected] published (tagged legacy) — same malicious dependency
Mar 31, ~03:15	npm unpublishes both compromised axios versions
Mar 31, 03:25	npm places security hold on plain-crypto-js
Mar 31, 04:26	Security stub [email protected] published to block reinstalls

The malicious versions were live for approximately 3 hours before npm took action. During that window, an estimated 3% of Axios's userbase — potentially tens of thousands of developer workstations and build servers — installed the compromised packages.

---

The Compromised Maintainer Account

The attacker gained access to the npm account of jasonsaayman, a legitimate Axios maintainer. Every legitimate Axios 1.x release is published via GitHub Actions using npm's OIDC Trusted Publisher mechanism — a cryptographic binding between GitHub CI and npm. The malicious [email protected] was published manually using a stolen npm access token with no OIDC binding, and the account email was changed to [email protected].

The Malicious Dependency: plain-crypto-js

The compromised Axios versions added a single new dependency: [email protected]. This package was never imported anywhere in Axios source code. Its sole purpose was executing a postinstall script — a 4.2KB obfuscated JavaScript dropper called setup.js that used dual-layer XOR encryption to hide its true behavior.

What the Dropper Does

Within 1.1 seconds of npm install completing, the dropper:

1. Detects the operating system (Windows, macOS, or Linux)
2. Contacts the C2 server at sfrclak[.]com:8000 (IP: 142.11.206.73)
3. Downloads a platform-specific RAT payload
4. Executes the RAT in a detached background process
5. Cleans up all evidence — deletes setup.js, replaces the malicious package.json with a clean stub reporting version 4.2.0 instead of 4.2.1

Platform-Specific Payloads

macOS

• RAT binary saved to: /Library/Caches/com.apple.act.mond
• Executed via AppleScript dropper in /tmp/6202033
• Code-signed with codesign --force --deep --sign to bypass Gatekeeper

Windows

• RAT binary saved to: %PROGRAMDATA%\wt.exe (disguised as Windows Terminal)
• Temporary files: %TEMP%\6202033.ps1, %TEMP%\6202033.vbs
• PowerShell executed with -ExecutionPolicy Bypass

Linux

• Python RAT script fetched to: /tmp/ld.py
• Executed via nohup python3 detached from parent process

RAT Capabilities (WAVESHAPER.V2)

Once installed, the RAT — identified by Google as WAVESHAPER.V2 — beacons to the C2 server every 60 seconds using a spoofed IE8/Windows XP User-Agent string. It collects hostname, username, OS version, CPU architecture, boot/install times, and running processes. The RAT accepts four commands:

• peinject — Downloads and executes additional binaries (Base64-encoded, code-signed on macOS)
• runscript — Executes shell commands or AppleScript
• rundir — Enumerates filesystem metadata from /Applications, ~/Library, and ~/Application Support
• kill — Terminates the RAT process

---

Run these commands on every developer workstation, build server, and CI/CD runner in your organization.

Step 1: Check for Compromised Axios Versions (All Platforms)

# Check if plain-crypto-js exists in any project
find / -name "plain-crypto-js" -type d 2>/dev/null

# Check npm global packages
npm list -g plain-crypto-js 2>/dev/null

# Check package-lock.json for compromised versions
grep -r '"axios"' --include="package-lock.json" . 2>/dev/null | grep -E "1\.14\.1|0\.30\.4"

# Check yarn.lock
grep -E "axios@.*1\.14\.1|axios@.*0\.30\.4" yarn.lock 2>/dev/null

# Check pnpm-lock.yaml
grep -E "axios.*1\.14\.1|axios.*0\.30\.4" pnpm-lock.yaml 2>/dev/null

Step 2: Check for RAT Indicators — macOS

# Check for the RAT binary
ls -la /Library/Caches/com.apple.act.mond 2>/dev/null

# Check for the dropper temp file
ls -la /tmp/6202033 2>/dev/null

# Check for the RAT process
ps aux | grep -i "com.apple.act.mond" | grep -v grep

# Check for network connections to C2
lsof -i -n | grep -E "142\.11\.206\.73|sfrclak"

# Check for suspicious codesign activity in logs
log show --predicate 'process == "codesign"' --last 72h 2>/dev/null | head -20

Step 3: Check for RAT Indicators — Windows

# Check for the RAT binary (PowerShell)
Test-Path "$env:PROGRAMDATA\wt.exe"
Get-FileHash "$env:PROGRAMDATA\wt.exe" -ErrorAction SilentlyContinue

# Check for temp dropper files
Test-Path "$env:TEMP\6202033.ps1"
Test-Path "$env:TEMP\6202033.vbs"

# Check for suspicious processes
Get-Process | Where-Object { $_.Path -like "*ProgramData*wt.exe*" }

# Check for network connections to C2
netstat -ano | findstr "142.11.206.73"
netstat -ano | findstr "8000"

# Check recent PowerShell execution bypass events
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-PowerShell/Operational'; ID=4104} -MaxEvents 50 |
  Where-Object { $_.Message -like "*ExecutionPolicy Bypass*" -or $_.Message -like "*6202033*" } |
  Select-Object TimeCreated, Message | Format-List

Step 4: Check for RAT Indicators — Linux

# Check for the Python RAT script
ls -la /tmp/ld.py 2>/dev/null

# Check for the RAT process
ps aux | grep -E "ld\.py|nohup.*python3" | grep -v grep

# Check for network connections to C2
ss -tunapl | grep -E "142\.11\.206\.73|8000"
netstat -tunapl 2>/dev/null | grep -E "142\.11\.206\.73|8000"

# Check for suspicious nohup processes
ps aux | grep nohup | grep -v grep

Step 5: Check Network Logs

Search your firewall, DNS, and proxy logs for any connections to:

IOC Type	Value
Domain	sfrclak[.]com
IP Address	142.11.206.73
Port	8000
Campaign ID	6202033
User-Agent	IE8/Windows XP (spoofed)

Any historical connection to these indicators since March 30, 2026 confirms compromise.

---

If you found ANY indicator of compromise above, treat the affected system as fully compromised. The RAT's capabilities include arbitrary code execution and credential theft — assume the attacker had full access to everything on that machine.

Immediate Actions (First 2 Hours)

1. Isolate affected systems — disconnect from network immediately. Do not shut down (preserve volatile memory for forensics if possible).
2. Block C2 at your firewall — add rules blocking 142.11.206.73 and sfrclak[.]com on all ports, both inbound and outbound.
3. Kill the RAT process:
   • macOS: sudo kill $(pgrep -f "com.apple.act.mond") and sudo rm /Library/Caches/com.apple.act.mond
   • Windows: Stop-Process -Name "wt" -Force; Remove-Item "$env:PROGRAMDATA\wt.exe" -Force
   • Linux: kill $(pgrep -f "ld.py"); rm /tmp/ld.py
4. Downgrade Axios in all projects: npm install [email protected] (or [email protected] for legacy)
5. Clear all package manager caches to prevent re-infection:

   npm cache clean --force
   yarn cache clean
   pnpm store prune

Credential Rotation (First 24 Hours)

Every credential accessible from the compromised machine must be rotated. The RAT could have exfiltrated anything:

• npm tokens — revoke and regenerate all npm access tokens
• Git credentials — rotate GitHub/GitLab/Bitbucket personal access tokens and SSH keys
• Cloud credentials — AWS access keys, Azure service principals, GCP service account keys
• Environment variables — any secrets stored in .env files, CI/CD variables, or shell profiles
• SSH keys — regenerate all SSH key pairs on affected systems
• API keys — any third-party API keys (Stripe, Twilio, SendGrid, etc.) accessible from the machine
• Database credentials — rotate passwords for any database connections configured on the system
• Browser sessions — force sign-out of all browser sessions on affected machines (the RAT can steal session cookies)

System Rebuild (First 48 Hours)

For any system confirmed compromised:

1. Reimage the machine — do not attempt to "clean" a compromised system. The RAT's peinject command means additional payloads may have been deployed that you haven't discovered. Wipe and rebuild from known-good images.
2. Rebuild CI/CD runners — if your build servers ran npm install during the attack window, destroy and recreate them. Persistent CI runners (not ephemeral containers) are highest risk.
3. Verify build artifacts — any code built during the compromise window should be considered tainted. Rebuild and redeploy from clean systems.

Ongoing Monitoring

• Monitor for connections to 142.11.206.73 and sfrclak[.]com for at least 30 days
• Review all npm package installations across your organization for the next 2 weeks
• Enable npm audit in all CI/CD pipelines if not already active
• Consider implementing minimum release-age policies (7-day cooldown) for npm dependencies to prevent future supply chain attacks from exploiting freshly published malicious versions

---

For Development Teams

• Pin exact dependency versions in package.json — use "axios": "1.14.0" not "axios": "^1.14.0". The caret prefix automatically upgrades to new minor/patch versions including compromised ones.
• Use lockfiles and verify checksums — package-lock.json, yarn.lock, and pnpm-lock.yaml pin exact versions with integrity hashes. Never delete lockfiles.
• Run npm audit in CI/CD — fail builds on critical vulnerabilities.
• Use ephemeral CI/CD runners — containers that are destroyed after each build prevent persistent compromise.
• Enable npm OIDC Trusted Publishers — for packages you maintain, bind publishing to your CI/CD pipeline so stolen tokens can't publish directly.
• Implement dependency review — tools like Socket.dev, Snyk, or GitHub Dependabot alert on new dependencies added to packages you depend on.

For IT and Security Teams

• Monitor for unexpected npm postinstall scripts — these are the primary mechanism for supply chain attacks.
• Block known-malicious C2 infrastructure at the firewall level proactively.
• Deploy application allowlisting (like ThreatLocker) on developer workstations — even if npm drops a malicious binary, it won't execute if it's not on the allowlist.
• Segment developer networks — developer workstations should not have unrestricted access to production systems, customer databases, or financial systems.
• Consider a private npm registry — Artifactory, Nexus, or Verdaccio can proxy npm with approval workflows for new packages and versions.

---

Google Threat Intelligence Group (GTIG) attributed this attack to UNC1069, a financially motivated North Korean threat actor active since at least 2018. Microsoft independently attributed the infrastructure to Sapphire Sleet. This threat actor is also tracked as:

• STARDUST CHOLLIMA (CrowdStrike)
• Alluring Pisces (Palo Alto)
• BlueNoroff (Kaspersky)
• CageyChameleon
• CryptoCore

UNC1069 is assessed with high confidence to be associated with BlueNoroff, a financially focused subunit of the broader Lazarus Group. The attribution is based on the use of WAVESHAPER.V2, an updated version of the WAVESHAPER backdoor previously deployed by this actor in cryptocurrency theft campaigns.

The supply chain attack on Axios follows a pattern of North Korean threat actors targeting developer tools and package registries — the same strategic approach used in the SolarWinds (2020), Kaseya (2021), and 3CX (2023) supply chain compromises.

---

If your Houston business has developers, web applications, or custom software — you likely have Axios in your dependency tree. It's used by virtually every React, Vue, Angular, and Node.js application. This isn't a niche library targeting a small audience. This is one of the most foundational packages in the JavaScript ecosystem being weaponized by a nation-state actor.

The immediate action items for every business:

1. Audit every project for [email protected] or [email protected] using the commands above
2. Check every developer workstation and build server for the platform-specific RAT indicators
3. If compromised: isolate, rotate credentials, reimage systems
4. If clean: implement the prevention measures to protect against the next supply chain attack

LayerLogix provides supply chain security assessment and remediation for Houston businesses. If you need help auditing your development environments, rotating credentials across your organization, or implementing the dependency security controls described above — contact us immediately or call 713-571-2390.

Sources: StepSecurity | Elastic Security Labs | Snyk | Google GTIG | Microsoft Security

Related: The Three Cyberthreats Dominating 2026 | Zero Trust with ThreatLocker | Threat Remediation Services | AI Security & Governance