There’s a ritual that plays out in security teams every time an MDR solution fires: Slack lights up, someone types “nice catch,” and the room exhales. It feels like a victory. But it isn’t.
A supply chain attack on March 31, 2026 made this uncomfortably clear. If you’re responsible for protecting modern infrastructure, it’s worth understanding exactly what happened and what it revealed about how the industry thinks about success.
What happened with Axios
Axios is one of the most universal JavaScript libraries in existence, pulling in roughly 100 million downloads per week. A threat actor later attributed to Sapphire Sleet, a North Korean state-sponsored group, compromised the npm account of the library’s primary maintainer and quietly published two backdoored versions in a 39-minute window.
The poisoned releases didn’t touch Axios’s own source code. Instead, they introduced a hidden transitive dependency called plain-crypto-js, which used a postinstall hook to deploy a cross-platform Remote Access Trojan across Windows, macOS, and Linux. On Windows, the malware established persistence through a batch file in ProgramData and a Registry Run key, ensuring the payload re-executed on every reboot. The malicious packages stayed live for hours before removal.
Many MDR solutions caught the batch file. Alerts fired. Reports were generated.
But here’s the uncomfortable question: were those teams detecting an attack, or just finding the wreckage?
Detection is not prevention
By the time a batch file appears in ProgramData, the attack chain is complete. The package ran. PowerShell executed. The payload downloaded. The RAT phoned home, in some cases before npm install had even finished resolving dependencies.
At that point, your alert isn’t protecting you. It’s documenting what already happened. The attacker is already in the environment; you’re just confirming their address.
Detection, at that stage, is a record-keeping exercise.
What earlier intervention actually looks like
The meaningful intervention point isn’t the batch file. It’s the PowerShell execution that precedes it. Stop the process there and the entire chain collapses: no payload, no outbound connection, no persistence mechanism, nothing to remediate.
That’s the practical difference between preemptive and reactive security. One prevents the attack from landing. The other generates a detailed account of how it did.
Rethinking what a “win” means
Detection still matters. It’s a necessary layer in any serious security strategy. But it shouldn’t be the primary measure of success, and a well-tuned detection dashboard shouldn’t be mistaken for a strong security posture.
If your first meaningful signal appears at the persistence stage, the more important questions are: How long was the attacker present before that alert fired? What did they do in that window? Supply chain attacks are built to exploit trust, and a several-hour window between infection and package removal is more than enough time to establish access and begin moving laterally.
Questions worth asking your vendor
The Axios incident is a useful benchmark. Instead of reviewing dashboards and mean-time-to-detect metrics, push on the specifics:
- Where in the kill chain does your first alert occur?
- Can you demonstrate stopping an attack before persistence is established?
- What visibility do you have into PowerShell execution and outbound connections before payload delivery?
- If detection is your first signal, what assumptions does that imply about attacker dwell time?
The answers will tell you quickly whether a solution is designed to prevent attacks or to report on them.
The bottom line
Catching a batch file in ProgramData looks like a win. In practice, it’s evidence that the attack already succeeded. The goal shouldn’t be finding proof of compromise. It should be making that proof unnecessary.
If your alerts begin at persistence, you weren’t protected.
You were notified.
