Axios npm Compromise: UNC1069 Attribution & Supply Chain Hygiene
Just saw the report from Google Threat Intelligence Group regarding the Axios npm compromise. The attribution to UNC1069 (North Korea) is significant because it confirms they are actively targeting the software supply chain for financial gain rather than just espionage. Axios is ubiquitous in the JS ecosystem, so the blast radius here is terrifying.
The attack involves a malicious update that likely executes a payload during npm install. We need to assume the goal is credential theft or crypto-mining injection in CI/CD pipelines. Since Axios is a dependency for so many frontend and backend projects, the transitive dependency risk is high.
If you are SOC or SecOps, I recommend hunting for unusual process trees originating from build agents. Here is a KQL query to check for Node.js processes spawning shells (common behavior in this type of supply chain attack):
DeviceProcessEvents
| where InitiatingProcessFileName =~ "node.exe"
| where ProcessFileName in~ ("cmd.exe", "powershell.exe", "bash")
| where ProcessCommandLine contains "env" or ProcessCommandLine contains "config"
| project Timestamp, DeviceName, ProcessCommandLine, InitiatingProcessCommandLine
| order by Timestamp desc
On the remediation side, force an audit to catch the tainted versions:
npm audit --force
Are we seeing a shift where state actors are purely financially motivated via supply chains now, or is this just funding for other ops? How is everyone handling the transitive dependency nightmare in larger codebases?
Great query, thanks for sharing. I modified it slightly to include git.exe as a parent process since a lot of these supply chain attacks try to exfiltrate repo data immediately after initialization.
| where InitiatingProcessParentFileName =~ "git.exe" or InitiatingProcessFileName =~ "node.exe"
We found three build servers hitting the UNC1069 C2 infrastructure this morning. The transitive dependency issue is a nightmare—we had a project using a library that used a library that used Axios.
We're moving to an internal proxy registry (Nexus) that caches packages and prevents new versions from being pulled without manual approval. It saved us this time.
If you haven't locked your package-lock. files in git, do it now. Also, consider running npm ci instead of npm install in production builds to ensure consistency:
npm ci --only=production
It ignores the package. semvers and strictly uses what is in the lockfile.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access