North Korea Hackers Tied to Axios npm Package Supply Chain Attack

North Korea hackers are now at the center of the Axios compromise after Google Threat Intelligence Group said the recent npm package attack was tied to UNC1069, a financially motivated North Korea-nexus threat actor. That attribution changes the shape of the story. What started as a fast-moving open source compromise involving poisoned Axios releases and a malicious dependency now sits inside a much larger picture involving North Korean cyber operations, software supply chain abuse, developer infrastructure, and the growing use of trusted packages as malware delivery channels.

Axios is not a fringe package. It is one of the most widely used JavaScript libraries for making HTTP requests, and its official npm page shows just how deeply embedded it is across web development. Frontend apps use it. Backend services use it. Internal dashboards use it. Build systems pull it in. Countless projects depend on it directly or indirectly. When attackers get control of something that common, the goal is not subtle sabotage inside one niche corner of the software world. The goal is reach.

Google says the malicious activity affected `axios@1.14.1` and `axios@0.30.4`, two npm releases that were modified to pull in `plain-crypto-js@4.2.1`, a dependency that should not have been there. That package then used npm’s `postinstall` hook to silently run an obfuscated JavaScript dropper named `setup.js`, which Google tracks as SILKBELL. The dropper downloaded platform-specific malware for Windows, macOS, and Linux and ultimately delivered a backdoor called WAVESHAPER.V2. That is the technical core of the incident, but the larger significance is easier to say in plain English. A trusted package was turned into a malware path, and ordinary installs became the delivery mechanism.

We already covered the earlier stage of this incident in Axios Supply Chain Attack Pushes RAT Malware Through npm Install, when the main facts were the poisoned package versions, the malicious `plain-crypto-js` dependency, and the install-time RAT deployment. The new Google writeup pushes the story further. It explains why security teams are now looking at this not just as another npm compromise, but as a North Korea-linked supply chain operation tied to a specific threat actor, a specific malware family, and a very recognizable pattern of financially driven intrusion.

What Actually Happened to Axios

According to Google, the attacker introduced `plain-crypto-js@4.2.1` into `axios@1.14.1` and `axios@0.30.4` during a narrow window on March 31, 2026. This was not some optional plugin or harmless extra package. It was a malicious dependency whose only real purpose was to run code during installation.

That matters because many readers hear “package attack” and assume someone had to run suspicious code manually after install. That is not what happened here. npm packages can define lifecycle hooks, and one of those hooks is `postinstall`. If a package uses it, npm runs that script automatically after installation. In this case, the attacker abused that normal behavior so the malicious code would execute in the background without the victim doing anything beyond installing Axios.

For a nontechnical reader, the easiest way to picture it is this. Someone swapped a clean product on a trusted shelf with a poisoned one, and the poison triggered the moment it was brought home and opened. No one had to click a sketchy attachment. No one had to visit a fake download portal. The attack piggybacked on a normal software workflow that developers use every day.

Why Axios Was Chosen

This part is important because it explains why people reacted so strongly.

Axios was valuable because it was everywhere. The package sits inside modern web development in a way that makes it almost invisible until something goes wrong. It handles routine network requests, API calls, response handling, interceptors, uploads, timeouts, and other plumbing that developers often treat as basic infrastructure. The official Axios package page also shows that the project now includes a fetch adapter and explicit support for custom fetch use cases, which makes the online “just use fetch” reaction even more superficial than it looked at first. The point was never that Axios was uniquely outdated. The point was that Axios was trusted, widely deployed, and useful as an access channel.

One of the more accurate reactions to the incident was the observation that the package was chosen for its download volume, not because it was especially hard to compromise. That tracks with how these operations work. The hard part was not writing malware. The hard part was getting into the release chain of a package with enormous reach. Once that happened, the victim pool created itself.

This is one reason the attribution matters. When people hear “North Korea hackers,” they often jump straight to a movie version of cyber warfare. What Google described is more practical and more dangerous. This looks like a financially motivated operation that went after trust and scale, not theatrics.

How the Malicious Dependency Worked

Google says the malicious `plain-crypto-js` package used a `postinstall` hook to execute `setup.js`, the obfuscated dropper that kicked off the rest of the compromise. That script checked which operating system it was running on, decoded its hidden strings, contacted a command and control server, downloaded the appropriate payload, and then tried to clean up after itself.

That cleanup behavior deserves attention because it tells you what kind of operation this was. The malware did not just execute and leave everything behind in plain view. Google says `setup.js` attempted to delete itself and restore the modified `package.json` by renaming a stored `package.md` back into place. In other words, the attacker wanted the package directory to look more normal after the malicious code had already run.

That is an anti-forensics choice. It is meant to frustrate retrospective analysis and reduce the obvious signs that something bad happened during install. It also means defenders cannot rely on a superficial glance at a package directory after the fact and assume they are safe.

The dropper also used obfuscation to hide the command and control address and platform-specific execution logic. Google says the script relied on custom XOR and Base64 routines, dynamically loaded `fs`, `os`, and `execSync`, and concealed the host-specific commands it needed to execute. This was not a crude package compromise. It was built to survive first contact with analysts and automated scanning.

What the Malware Did on Windows, macOS, and Linux

The operating-system-specific logic in Google’s writeup makes clear that the attacker had real developer environments in mind.

On Windows, the dropper searched for `powershell.exe`, copied it to `%PROGRAMDATA%\wt.exe`, downloaded a PowerShell script into the temp directory, and executed it with hidden and execution-policy-bypass flags. It also created persistence using `%PROGRAMDATA%\system.bat` and a Run-key entry named `MicrosoftUpdate`. That gave the attacker a way to come back after the initial infection.

On macOS, the malware downloaded a native Mach-O binary to `/Library/Caches/com.apple.act.mond`, modified permissions to make it executable, and launched it in the background. The file path was chosen to look system-like, which is exactly what you would expect from someone trying to hide malicious code on a Mac used by engineers, developers, founders, or DevOps staff.

On Linux, the dropper downloaded a Python backdoor to `/tmp/ld.py` and executed it detached in the background.

All three branches point to the same conclusion. The attack was not built around one operating system. It was designed to compromise the mixed environments that modern developers and software teams actually use. That includes MacBooks, Windows workstations, Linux CI systems, cloud runners, and build servers. The package ecosystem is cross-platform, so the malware was cross-platform too.

What WAVESHAPER.V2 Means in Practice

Google says the payload delivered by the Axios compromise was WAVESHAPER.V2, an updated backdoor linked to UNC1069. The name alone does not tell most readers much, so it is worth spelling out what the malware could actually do.

WAVESHAPER.V2 is a remote access trojan. That means it gives the attacker a foothold on the infected system and a way to send commands, collect data, and deploy additional payloads later. Google says the malware can gather system telemetry such as hostname, username, boot time, time zone, operating system details, and running processes. It can enumerate files and directories, execute scripts and commands, and inject or run additional binaries.

The malware also beacons back to its command and control server over port 8000 every 60 seconds using Base64-encoded JSON, with a fake user-agent string pretending to be Internet Explorer 8 on Windows XP. That is a strange fingerprint, but that is exactly why it matters. It gives defenders something distinctive to hunt for in logs and network telemetry.

On Windows, Google says persistence is achieved through the Run key and a hidden batch file. On macOS, the payload appears as a native binary. On Linux, it takes the form of a Python backdoor. The implementation changes by platform, but the end result is the same. The victim host stops being just a machine that installed a bad dependency and becomes a system the attacker can interact with.

That is why this incident cannot be brushed off as a package scare. A poisoned install delivered a working backdoor.

Why Google Linked the Attack to North Korea

This is the part that changed the story most dramatically.

Google Threat Intelligence Group attributes the Axios attack to UNC1069, a financially motivated North Korea-nexus threat actor active since at least 2018. The company says the attribution is based on several overlapping factors, including the use of WAVESHAPER.V2, which it describes as an updated version of WAVESHAPER malware already associated with UNC1069, as well as infrastructure overlaps seen in past operations.

Google says the command and control domain `sfrclak[.]com`, which resolved to `142.11.206.73`, showed links to infrastructure previously associated with UNC1069, including connections from a specific AstrillVPN node. The company also says adjacent infrastructure hosted on the same ASN had earlier ties to the same actor’s operations.

That is real attribution work. It is not a lazy jump from “this feels like North Korea” to “therefore it is North Korea.” That distinction matters, especially in a week where a lot of people online immediately started lumping this incident in with TeamPCP activity or broader supply chain chaos.

Austin Larsen, one of the Google analysts behind the writeup, addressed that directly in a public post by saying “They weren’t involved with this one.” That is an important clarification because it cuts against the early speculation that the Axios attack might simply be another TeamPCP incident. Google’s attribution points elsewhere.

Why North Korea Keeps Appearing in High-Trust Software Attacks

North Korea-linked cyber operations are often discussed in terms of crypto theft, espionage, deepfake job scams, and sanctions evasion, but those are really parts of a larger pattern. The common thread is leverage.

The regime’s cyber operators go after places where access can become money, intelligence, infrastructure reach, or all three. In the past, that has meant exchanges, DeFi projects, companies with valuable credentials, and environments rich in cloud access or wallet secrets. The Axios case fits the same logic. A compromised package in a trusted ecosystem can give an attacker access to developer machines, CI runners, cloud secrets, package publishing credentials, GitHub tokens, and all kinds of downstream infrastructure.

Austin Larsen also noted publicly that UNC1069 typically targets the cryptocurrency and DeFi verticals, and that Google had earlier detailed how the group used AI deepfakes in tailored schemes to steal session tokens. That background matters because it shows continuity. The same actor family tied to targeted access and financially motivated operations is now being linked to a mainstream open source package compromise with massive developer reach.

That is why some observers reacted by saying this looks like the normalization of cybercrime as state policy. It is not just rhetorical overreach. When a North Korea-nexus actor appears to be using open source supply chain compromise as another practical revenue and access mechanism, it looks less like a one-off stunt and more like a durable operating model.

Why the Exposure Window Still Matters Even If It Was Short

One of the easiest mistakes people make after incidents like this is hearing that the malicious package was removed within hours and assuming the danger passed quickly.

That is not how supply chain attacks work.

A short public window can still be enough to hit a large number of environments because dependency installs are constant. Developers rebuild projects. CI systems spin up new jobs. Containers get recreated. Feature branches pull fresh lockfiles. Monorepos churn through automated tasks. Internal mirrors cache packages. A poisoned version does not need to live for days to leave a mess behind.

The damage in incidents like this often comes from what happened during the window, not how long the package stayed publicly visible afterward. Once a compromised version reaches a build cache, a CI runner, a developer workstation, or a corporate mirror, removal from npm is not the end of the incident. It is the start of cleanup.

That is why Google’s guidance treats the problem seriously. If `plain-crypto-js` is found, the company says to assume the host is compromised. That is not phrased like ordinary patch guidance because this is not an ordinary patch problem.

What Organizations Should Check Right Now

Anyone who installed or resolved dependencies during the affected period should look for the poisoned versions and their indicators, starting with:

• `axios@1.14.1`
• `axios@0.30.4`
• `plain-crypto-js@4.2.0`
• `plain-crypto-js@4.2.1`

Google also published network and filesystem indicators that deserve immediate attention. Those include:

• `sfrclak[.]com`
• `142.11.206.73`
• `http://sfrclak[.]com:8000`
• `http://sfrclak[.]com:8000/6202033`
• `/Library/Caches/com.apple.act.mond`
• `%PROGRAMDATA%\wt.exe`
• `%TEMP%\6202033.vbs`
• `%TEMP%\6202033.ps1`
• `/tmp/ld.py`
• `%PROGRAMDATA%\system.bat`

If any of that turns up, the response should be treated as incident response, not dependency cleanup. Google’s recommendations include isolating affected hosts, rotating potentially exposed credentials and tokens, pinning Axios to known-safe versions, clearing npm, yarn, and pnpm caches, and reviewing build systems for evidence that poisoned versions were pulled automatically.

That last part is especially important. Many organizations focus on developer laptops first, but CI/CD runners and build environments may be even more important because they often hold deployment secrets, registry tokens, and privileged access to internal systems.

Why This Story Is Bigger Than Axios

The Axios compromise matters because it is a near-perfect example of where software risk is going.

Attackers did not need a browser exploit, a flashy zero-day, or a convincing phishing lure. They needed a trusted package and control over a release path. Once they had that, the ecosystem did the work for them. Normal software maintenance became distribution.

That is why the attack cannot be reduced to an npm scandal or a debate about whether developers should just switch to native fetch. The bigger issue is that trust itself is now an operational target. Developers trust package managers. Teams trust maintainers. Enterprises trust official releases. Build pipelines trust automation. Every one of those assumptions is useful to an attacker who wants scale.

The North Korea angle pushes that concern even further. If Google is right that UNC1069 was behind this operation, then the lesson is not merely that open source can be abused. It is that a North Korea-nexus actor appears willing to use one of the most common software distribution channels on the internet as a practical means of intrusion, access, and likely financial gain.

That should change how people think about supply chain defense. The question is no longer whether open source trust can be abused. That has already been answered. The question is how many teams are still operating as though a routine install from a familiar package is a neutral event.

Axios was chosen because it was common. The malware was built because common things are where trust lives. And North Korea hackers, if Google’s attribution holds, went after that trust because they understood exactly how much it was worth.