2026-07-30 · view entry permalink →
Amazon attributes the axios, debug and chalk npm compromises to a DPRK-linked cluster with medium confidence, and names a small 2025 package compromise as the rehearsal
Amazon's threat-intelligence team published an attribution assessment on 2026-07-29 linking three separate npm package compromises to one actor. The load-bearing sentence carries its own hedge, and it should be read with the hedge intact: "based on analysis of command-and-control (C2) indicators and TTPs, Amazon Threat Intelligence assesses with medium confidence that these campaigns are attributable to the DPRK-linked threat actor tracked as SAPPHIRE SLEET, STARDUST CHOLLIMA, BlueNoroff, CageyChameleon, and Alluring Pisces" (AWS Security Blog, 2026-07-29). CyberScoop notes that researchers also track this cluster as UNC1069 (CyberScoop, 2026-07-29). Medium confidence is not attribution-by-consensus. Amazon is also precise about which part is new: it states that "while the axios compromise has been publicly attributed to this DPRK-linked threat actor, the typo-crypto, debug, and chalk incidents haven't previously been connected to it" (AWS Security Blog, 2026-07-29). For a defender the actor label changes little, but the tradecraft description below changes something real.
The compromises run from March 2025 to March 2026 and escalate in blast radius: debug and chalk in September 2025, then axios in March 2026, which Amazon describes as one of the most widely used JavaScript libraries at more than 100 million weekly downloads (AWS Security Blog, 2026-07-29). None of them involved breaking the registry. In Amazon's words, "in each case, the threat actor gained access by socially engineering a trusted maintainer of the package, then published a software update containing malicious code" (AWS Security Blog, 2026-07-29) — the trust chain held exactly as designed and delivered the malicious version, which is why provenance and signing controls do not help here.
The genuinely new element is the rehearsal. Amazon points at a March 2025 compromise of a package named typo-crypto, into which the actor committed a trojanised file that masqueraded as the unrelated legitimate core-js package, and assesses that "based on the limited number of observed downloads... this campaign was small scale and likely served as a testing ground for the more visible supply chain operations that followed in late 2025 and 2026" (AWS Security Blog, 2026-07-29). That is a patience pattern worth internalising: a package with negligible download counts is not necessarily a failed attack, it may be where the maintainer-social-engineering approach and the payload were refined before being pointed at something with a hundred million weekly installs.
Two mechanics from that rehearsal payload matter for anyone who triages suspicious dependencies. First, detonation was conditional on input rather than on time or environment: the trojanised file executed only when it received a hash input beginning with one specific literal value, and only then downloaded an operating-system-appropriate second stage, with behaviour tailored separately for Windows, macOS and Linux (AWS Security Blog, 2026-07-29). A package like that installs and runs cleanly in any sandbox that does not happen to feed it the trigger value, so "we installed it and nothing happened" is not a clean result. Second, the payload combined file-based persistence with payload rotation and layered obfuscation — base64-encoded text over an XOR cipher under a fixed key (AWS Security Blog, 2026-07-29) — so a static scan of the shipped file yields little without unwrapping those layers.
Amazon separately describes a shift in how these operations are structured, observing that attackers increasingly split one malicious workflow across several individually unremarkable packages, and that "this approach is designed to defeat scanners that evaluate packages one by one instead of reasoning about how they interact in a real dependency graph" (AWS Security Blog, 2026-07-29). Amazon frames that as an observation rather than advice, but the implication for a review process is direct: a per-package verdict is the wrong unit of analysis when the malicious behaviour only exists once the pieces are resolved together.
Triage: a benign minified or bundled dependency also carries base64 blobs and unreadable code, so obfuscation alone does not separate the two. The discriminators are behavioural and structural: a code path that stays inert unless a caller supplies a particular argument value, a second-stage fetch whose destination differs by host operating system, and persistence written outside the package's own installation tree. A dependency that reaches the network at all during a build or test run, when its documented function does not require it, is the anomaly worth pulling.
Based on analysis of command-and-control (C2) indicators and TTPs, Amazon Threat Intelligence assesses with medium confidence that these campaigns are attributable to the DPRK-linked threat actor tracked as SAPPHIRE SLEET, STARDUST CHOLLIMA, BlueNoroff, CageyChameleon, and Alluring Pisces.
In each case, the threat actor gained access by socially engineering a trusted maintainer of the package, then published a software update containing malicious code.
Based on the limited number of observed downloads, Amazon Threat Intelligence assesses that this campaign was small scale and likely served as a testing ground for the more visible supply chain operations that followed in late 2025 and 2026.
This approach is designed to defeat scanners that evaluate packages one by one instead of reasoning about how they interact in a real dependency graph.
When triggered, it downloads a second-stage payload from a hardcoded C2 server, then executes the payload based on the victim's operating system, with behavior tailored for Windows, macOS, or Linux.