Amazon Threat Intelligence has tied a DPRK hacking group to four separate NPM package supply chain attacks, including axios.
The company’s security teams have connected the axios, debug, chalk, and typo-crypto package incidents to a single actor tracked across the industry under five names: SAPPHIRE SLEET, STARDUST CHOLLIMA, BlueNoroff, CageyChameleon, and Alluring Pisces. The axios compromise had already been attributed to this group publicly. The links to typo-crypto, debug, and chalk had not.
Amazon Threat Intelligence and the Amazon Inspector team published the findings alongside detail on how open-source attack techniques have evolved and how generative AI is beginning to reshape both malicious packages and the systems built to catch them.
It’s worth noting that the research follows two years after the XZ Utils backdoor, an incident that showed how a patient attacker could exploit the trust and limited bandwidth of volunteer maintainers to compromise software used across the internet.
Four NPM attacks trace to a single actor linked to the DPRK
The timeline runs across roughly a year. In March 2025, the threat actor compromised the typo-crypto package. In September 2025, the same actor hit debug and chalk.
Axios followed in March 2026. It’s one of the most heavily used JavaScript libraries in existence, with more than 100 million weekly downloads by Amazon’s count, and the compromise ran through the same steps as the earlier incidents. A trusted maintainer got socially engineered into handing over access, and a software update carrying malicious code went out under their name. Any organisation set to pull the latest version automatically received that update without further action.
Four campaigns, one set of fingerprints. The use of post-install hooks and reused code were among the details that enabled Amazon Threat Intelligence to draw a line between incidents that otherwise looked unrelated.
Command-and-control indicators and overlapping techniques gave Amazon enough to assess with medium confidence that a single DPRK-linked actor sits behind all four compromises. Typo-crypto, debug, and chalk had never been tied to this group publicly until now.
Amazon assesses the campaign is financially-motivated: compromising a small number of popular packages gives an actor potential access to thousands of downstream environments at once, an approach that’s more efficient than targeting individual organisations one-by-one.
Wiz Research reported that around one in ten cloud environments were affected by the debug and chalk event within a two-hour window, a figure that illustrates how quickly a single compromised dependency can spread once automatic updates are involved.
A quiet 2025 test run preceded the bigger hits
While reviewing indicators tied to the axios activity, Amazon Threat Intelligence traced a connection to a domain registered in 2025, which led to a full investigation into its history. That investigation surfaced a trojanised file committed to the typo-crypto package back in March 2025, roughly six months before the debug and chalk incidents.
The file, core.js, was built to masquerade as the legitimate core-js package. Download volume on typo-crypto stayed low, and Amazon reads that as a sign the operation was never meant to run at scale. Amazon’s working theory is that this was a dry run, a chance to work out the mechanics before the group moved on to bigger targets in late 2025 and 2026.
If that theory is correct, the group had been refining its approach for more than a year before anyone outside Amazon noticed. Amazon Inspector reported the malware to the Open Source Vulnerabilities database, where it now carries the identifier MAL-2026-3400.
Getting the file to run took a specific trigger: a hash input starting with the value 0098273. Once that condition was met, the file reached out to a hardcoded C2 server for a second-stage payload, then ran code suited to whatever operating system it landed on, Windows, macOS, or Linux.
Persistence came through the file system, with payloads rotating over time, and the whole thing hid behind two layers of obfuscation, base64 text wrapped around an XOR cipher keyed to 01042025.
Attackers split malicious code across multiple packages
Amazon Inspector has watched attackers break a single malicious workflow into several ordinary-looking packages rather than concentrating it in one.
One package stores an encrypted blob disguised as configuration data. A second carries the decryption logic. Then there’s a third package, usually pushed out later once the first two are already in place, and its job is simply to fetch what the others prepared and run it.
None of the three looks dangerous on its own. Install hooks appear normal. Nothing handles untrusted input in a way that would catch a reviewer’s eye. Network calls don’t stand out.
The danger only shows up once someone (or something) installs all three in the right order and lets them talk to each other, which is the situation most scanners aren’t built to catch. They’re designed to judge a package in isolation, not to trace how it behaves once it’s sitting inside a real dependency graph alongside two others.
Some actors are now taking a longer view of trust. Instead of publishing malware and waiting for downloads, they publish something useful and keep maintaining it, shipping features and fixing bugs like a real contributor for weeks or months while dependents accumulate.
The same patience shows up on the human side. In some cases, the objective isn’t a new package at all but a contributor role inside an existing project. That was the common thread running from the XZ Utils backdoor through the debug, chalk, and axios maintainer compromises.
In each case, the adversary demonstrated legitimacy once, at the point where access paid off the most.
Payloads that stay clean until an attacker flips a switch
A package can pass every review and still be dangerous if its behaviour depends on resources the attacker controls elsewhere: guard or license scripts fetched at runtime, configuration files that gate certain functions, or remote endpoints consulted at startup.
As long as those external resources stay benign, code reviews pass and automated scans return clean results. The moment an attacker changes that content or arms a previously dormant endpoint, every installed copy can turn malicious simultaneously, without a new release ever going out.
Cryptography inside these packages has also grown more serious. Some use AES-GCM blobs that only open with the right passphrase. Others rely on RC4-style string arrays with a different key for every call, or stack layered XOR on top of base64 encoding. Native loaders now sometimes carry the next stage as an encrypted field that only decrypts in memory.
What ties these approaches together is where the key lives, which is nowhere near the package itself. It gets pulled from a server at runtime, built from context specific to the machine running it, or handed over as a license key, so even someone with the full source code in front of them can’t decrypt the payload without executing it against a live target.
Sandbox evasion has advanced alongside this. Payloads now check for signals of a genuine developer or build environment, including interactive terminals, realistic usernames and hostnames, domain membership, plausible uptime, local file history, and cloud metadata, before deciding whether to act. Some delivery servers tailor responses by client, sending a decoy to generic browser-like requests and reserving the live payload for the exact user agent the malware itself uses.
Generative AI complicates both sides of detection
Generative AI removes the tells that once caught malicious packages: broken language, thin documentation, obvious copy-paste, a function reused across samples.
Amazon reports attackers now producing coherent, well-commented code with convincing documentation, plausible commit histories, and synthetic maintainer identities wrapped around a backdoor. Each variant can be mutated, renamed, and re-encrypted, leaving no stable signature for pattern-based detection to catch.
AI also opens a new access route through slopsquatting, where attackers register package names that exist only because a coding assistant hallucinated them. When a developer or an autonomous agent asks for a recommendation and the model confidently suggests a package that doesn’t exist, an attacker who registered that name beforehand can hand over malware to whoever follows the suggestion, with no typo and no malicious link involved.
Amazon’s more pressing concern is what happens as organisations lean on AI to review code and triage packages: those systems become part of the attack surface themselves.
Hidden instructions built to manipulate an AI reviewer, a technique known as indirect prompt injection, are the next step Amazon expects to see inside malicious packages. The company anticipates this content turning up in source comments, README files, docstrings, and test fixtures, written specifically to talk an automated scanner into approving code it should flag, or into skipping a file it should have inspected.
Amazon Threat Intelligence worked with Amazon Inspector to get the typo-crypto malware tracked, mitigated, and published to the OSV database, and shared the associated indicators with Amazon GuardDuty so customers could check their own environments against the same infrastructure.
See also: VulnCheck data questions AI vulnerability discovery risk
Want to learn more about cybersecurity from industry leaders? Check out Cyber Security & Cloud Expo taking place in Amsterdam, California, and London. The comprehensive event is part of TechEx and is co-located with other leading technology events including the AI & Big Data Expo. Click here for more information.
Developer is powered by TechForge Media. Explore other upcoming enterprise technology events and webinars here.