Attribution as a trap: a npm attack and the fragility of the software supply chain

The recent reelaboration of the author of the npm package hijacking - which Amazon Threat Intelligence now associates with North Korea - once again puts on the table a known but insufficiently determined lesson: late and fragmented powers complicate defense and mediation in the software supply chain.

In September 2025, an attack was detected that compromised popular packages such as debug and chalk, and which was initially shown to the public as a cryptographic fraud: a maintainer was the victim of a phishing in a domain that imitated npm and a malicious update included code to rewrite billet addresses in the browser. Since then, other potentially related pieces were identified - such as an axial implantation in March 2026 and a small package called typo-crypto in March 2025 - and Amazon claims that the three campaigns share authoritarian group and tactical pattern. However, the evidence that Amazon publishes is partial: it describes coincidences in the tradecraft, reuse of code, post-installation hooks and some control and command indicators, but does not publicly draw a clear chain that links each incident to those same indicators.

That void matters. For debug and chalk it was documented code that operated exclusively on the browser side, intercepting fitch, XMLHttpRequest and APis of wallets to rewrite addresses before signing transactions; that code did not persist on disk and did not depend on post-install hooks as did the axial payload. In typo- crypto, observed behavior - a waiting trigger and a second stage downloaded from a C2 - suggests a small concept test with few downloads, not a massive campaign from the first day. In addition, in the case of typo-crypto there are inconsistencies in the metadata of the record: a single version published immediately on an account that does not match the declared author and files that appear to impersonate legitimate bookstores, which raises the possibility that it would be published malicious from the beginning, not hijacked by update. Amazon also provides hashes and file names that, according to the public analysis, do not match exactly the content available in the registration tarball, making it even more difficult to publicly verify the relationship between the described artifacts and the mentioned packages.

Technical and political attribution are not the same. While Google and Microsoft quickly attributed the commitment of axiums to actors that their firms track as UNC1069 / WAVESHAPER and Sapphire Sleet (with terminology varying between suppliers), Amazon extends that reading to older and less clear campaigns. The difference in times - almost immediate powers for axiums compared to repowers ten or sixteen months for debug, chalk and typo-crypto - highlights why organizations must demand transparency in evidence and maintain telemetry to allow subsequent forensic reconstructions.

On the defensive side, some recent npm measures help, but do not eliminate the risk of compromising a package via social engineering. The v12 version, released in July, came with the default deactivated life cycle scripts, which reduces the post-install scripts-based operating path that exploded axiums. In addition, npm began scanning new packages at the time of publication. They're steps in the right direction, but do not close the door to attacks that take advantage of the confidence of the maintainer, poorly managed accounts, or packages published malicious from scratch.

For developers and equipment responsible for dependencies, there are immediate and practical recommendations that reduce exposure: use lock files and perform reproducible facilities with 'npm ci' in controlled environments; carefully review small or few maintenance packages before adding them; apply multifactor authentication and rotation of publishing tokens; minimize the privileges of the accounts they publish and do so from CI with ephemeral credentials; audit the transitory dependencies and not install packages in user environments with less restrictions. At the organizational level, it is appropriate to generate and maintain SBOMs, integrate automatic scans into the CI / CD chain, adopt device signature mechanisms (e.g. Sigstore ecosystem projects) and apply admission controls that verify integrity and provenance before including a production unit. Resources that guide these practices are useful, for example the SLSA ( https: / / slsa.dev) and the advice of agencies such as CISA on supply chain security ( https: / / www.cisa.gov / supply-chain).

For registration operators and ecosystem suppliers the lesson is double: improving automated detection is not enough; usability and policies must push the maintainers into safe practices without increasing unnecessary operational friction. This means offering safer publishing options from CI, visibilizing package property changes, detecting abnormal publishing patterns or coincidences between metadata and binary objects, and facilitating quick and transparent processes to mitigate and remove compromised packages when there is solid evidence.

Finally, the episode highlights a political reality: to attribute a campaign to a nation-state has broad consequences that go beyond the technician. It requires a public and reproducible standard of proof when attribution will influence policy decisions, sanctions or international response. Meanwhile, those developing and deploying software must operate under the assumption that the risk exists and apply the principle of less privilege, in-depth defense and hygiene practices in the supply chain to limit the impact of incidents that are sometimes only understood weeks, months or even years later.