Axios Compromised: The 2-Hour Window Between Detection and Damage

Another Week, Another Supply Chain Attack

On March 30, 2026, an attacker compromised the npm maintainer account jasonsaayman (email changed to ifstap@proton.me) and published two malicious axios versions:

The attack was detected by CI/CD scanners within minutes. The malicious versions were pulled within hours. On paper, this is a success story.

In reality, the window between "malicious package published" and "npm takes it down" is all the attacker needs. Any npm install that ran during those 2-3 hours executed the payload. And here's the part that keeps SOC teams up at night: the malware cleans up after itself.

The Infection Chain (Summary)

The CI/CD infection mechanics are well-documented at this point. Here's what matters for the SOC side:

npm install axios@1.14.1
  └─ installs plain-crypto-js@4.2.1
       └─ postinstall: node setup.js
            └─ _entry("6202033")
                 ├─ Detects OS via os.platform()
                 ├─ Contacts C2: http://sfrclak[.]com:8000/6202033
                 └─ Downloads platform-specific RAT
                      ├─ macOS: /Library/Caches/com.apple.act.mond
                      ├─ Windows: %PROGRAMDATA%\wt.exe + PowerShell chain
                      └─ Linux: /tmp/ld.py via nohup python3

Obfuscation: Two-layer encoding - reversed Base64 + XOR cipher with key OrDeR_7077 and constant 333. Encoded strings stored in an stq[] array, decoded at runtime.

Anti-forensics: After execution, the malware deletes setup.js, removes the malicious package.json, and renames a clean package.md back to package.json. Post-install inspection shows a clean package with no scripts section. The infection traces are gone from the package directory.

This is where the CI/CD story ends and the SOC story begins.

‍

The SOC Problem: Detection That Arrives Too Late

Let's be honest about the detection timeline from a SOC perspective:

T+0h        Malicious package published
T+0.1h      CI/CD scanner flags it (impressive!)
T+2-3h      npm removes the package
T+3-6h      First IOC reports published by researchers
T+6-12h     SOC teams begin adding IOCs to detection rules
T+12-24h    IOCs propagated to SIEMs, EDRs, firewall rules
T+24-48h    SOC runs retroactive hunts (if they do at all)

Now consider the attacker's side:

T+0h        Payload executes during npm install
T+0.001h    RAT downloaded, running with persistence
T+0.002h    setup.js deleted, package.json replaced - no local traces
T+24-48h    C2 infrastructure rotated or burned
T+1 week    sfrclak[.]com is dead. IOCs are useless.

‍

The gap is structural. By the time IOCs reach your SIEM, the C2 domain may already be offline. Your retroactive hunt for sfrclak[.]com in DNS logs finds nothing - not because you weren't compromised, but because the C2 already served its purpose and moved on. Or worse: the second-stage payload (the actual RAT) communicates over different infrastructure that was never identified in the original scanner analysis.

This is the fundamental problem with IOC-first detection for supply chain attacks:

1. IOCs arrive with delay. Even when scanners catch the package in minutes, the IOC-to-SIEM pipeline takes hours to days.
2. IOCs expire fast. Attacker infrastructure is ephemeral. The domain, IP, and file paths in this post will be irrelevant within a week.
3. IOCs are incomplete. The scanner analyzed the dropper. The RAT's stage-2 and stage-3 C2 infrastructure may never be fully mapped. You're blocking the front door while the back door was never identified.
4. Retroactive hunts miss the window. If your SIEM retention is 30 days but your IOC hunt runs 48 hours after the event, you'll find the IOC. If it runs 2 weeks later? The C2 domain is dead, the process exited, and the only artifacts left are the persistent RAT - which uses different indicators.

CI/CD malware scanners are a great first line of defense. But even if they catch 99% of supply chain attacks, what about the remaining 1% - the ones with real obfuscation, the ones that clean up after themselves, the ones where the scanner catches the package but your build already ran npm install - those are the ones that matter. And they will keep getting better at evasion. This is an arms race, and the attacker only needs to win the 2-3 hour window.

SOC teams need to operate from a different assumption: compromise will happen, and we need to know when, what, and who - in real time, not after a blog post tells us what to grep for.

‍

The Pattern Is Clear

This is the second major supply chain attack in a single week. TeamPCP's campaign hit LiteLLM, Trivy, and 64+ npm packages. Now axios. We don't have evidence linking these campaigns (different TTPs, different infrastructure), but the pattern is undeniable: supply chain attacks are accelerating, and the packages getting hit are the ones with tens of millions of downloads.

The detection approaches that work for this class of attack are behavioral:

• Runtime process monitoring that knows what processes your applications normally spawn, and flags deviations - not just known-bad signatures
• Network baseline detection that flags unexpected outbound connections from production workloads, regardless of whether the destination is in a threat feed
• File integrity monitoring that detects artifacts appearing in sensitive locations (/Library/Caches, %PROGRAMDATA%, /tmp) that don't match the expected system state
• Contextual correlation that connects a suspicious npm install process chain → outbound C2 connection → file drop → persistent beaconing into a single investigation, not 4 separate low-priority alerts

If your detection strategy for supply chain attacks is "wait for the IOC list, add it to the SIEM, run a retro hunt" - you're always investigating yesterday's attack. The next one is already running.

‍

How Stream.Security Detects This - Before Any IOC Is Published

This is exactly the class of threat Stream.Security's CDR platform is built for. No IOC feed. No signature update. No waiting for the blog post. The detection fires because the behavior is wrong.

Appendix: Full Campaign IOCs

Apply these now for detection of this specific campaign, but remember: these indicators have a short shelf life.

‍

Malicious Packages

‍

Network Indicators

sfrclak[.]com                           # C2 domain
142.11.206.73                           # C2 IP
Port: 8000                              # C2 port
http://sfrclak[.]com:8000/6202033       # Full C2 URL (campaign ID: 6202033)

‍

File System Artifacts

# macOS
/Library/Caches/com.apple.act.mond      # RAT binary (masquerades as Apple daemon)

# Windows
%PROGRAMDATA%\wt.exe                    # Renamed PowerShell copy
%TEMP%\6202033.ps1                      # PowerShell payload
%TEMP%\6202033.vbs                      # VBScript launcher

# Linux
/tmp/ld.py                              # Python RAT script

‍

Package Hashes