What happened
Amazon published its new analysis on July 29, 2026. Amazon said typo-crypto was compromised in March 2025, debug and chalk in September 2025, and axios in March 2026. In each case, the operator socially engineered a trusted maintainer and published malicious code through an established package, allowing automated dependency updates to distribute it downstream.
Attribution posture: Amazon Threat Intelligence assessed with medium confidence that SAPPHIRE SLEET, a DPRK-linked actor also tracked as STARDUST CHOLLIMA, BlueNoroff, CageyChameleon and Alluring Pisces, conducted the four compromises. The axios attribution was already public; Amazon’s material new finding was the connection of typo-crypto, debug and chalk to the same operating pattern.
Amazon reported the typo-crypto malware as MAL-2026-3400. The malicious core.js file used SHA256 2014d09c7ded74d89c885b5f11693865224116f1b25df9330e61fe528f419d73, while the typo-crypto package used SHA256 24604384b0e748ada07923630b3d037489e696284a98c4409fb9b6763565571f. Published infrastructure was npmjs[.]store and 216[.]74[.]123[.]126.
The trojan executed when given a hash input beginning 0098273, downloaded a second-stage payload and selected behaviour for Windows, macOS or Linux. It used Base64 text and an XOR cipher keyed to 01042025. Amazon said the earlier, lower-volume typo-crypto compromise appeared to test techniques later used against more widely deployed packages.
Why this matters now
This is a trust-path decision, not only a malware-signature problem. Social engineering of maintainers converted legitimate publishing rights into mass distribution. Organisations that automatically accepted current versions inherited the maintainer’s compromised authority, so a clean perimeter or patched application estate would not have prevented exposure.
The newly connected timeline supports retrospective investigation. Teams should search old lockfiles, SBOMs, build logs, CI caches, developer workstations and artefact repositories because a malicious package may no longer be present on the public registry. Rebuilding from today’s clean dependency state does not determine whether an earlier release executed the payload.
Amazon also described broader tradecraft involving split functionality, delayed activation and external resources that can change after package review. Security leaders should therefore evaluate runtime behaviour and provenance across the full dependency graph, rather than relying solely on one-time static scanning of individual packages.
The decision for security leaders
Assign application security and CI platform owners to search for the published typo-crypto hashes, domain, IP address and filename. Correlate matches with process execution, network access, developer credentials and production artefacts; package presence alone should not close or confirm compromise.
Review historical axios, debug and chalk use against the exact malicious versions already documented by package ecosystems and internal records. Where version provenance is incomplete, treat the assurance limitation explicitly and prioritise systems that handled signing keys, cloud credentials, cryptocurrency or production deployment.
Strengthen maintainer and registry controls with phishing-resistant authentication, scoped publishing tokens, protected release workflows, independent approval for critical packages and rapid revocation. Dependency updates should be pinned and promoted through evidence-bearing builds rather than pulled directly into production.
Evidence of closure
- SBOM and lockfile searches show documented indicator dispositions.
- CI and artefact caches contain no unapproved affected packages.
- Registry credentials are rotated with stronger authentication enforced.
- Rebuilt artefacts match approved source and dependency provenance.
The Security.io assessment
Amazon’s attribution is medium confidence, but the technical indicators and campaign linkage provide decision value independent of actor identity. The durable finding is a repeated operating model: acquire legitimate maintainer access, publish through trusted channels and exploit automatic downstream consumption.
The precise typo-crypto indicators enable immediate hunting, while the wider attribution changes how earlier package events should be investigated. Treating each compromise as isolated risks missing shared infrastructure, reused code, credential patterns and other packages touched by the same maintainer-focused operation.
Exact indicators have a limited lifespan. Closure requires proving which builds incorporated affected dependencies, whether malicious code executed and which secrets were accessible. A current clean scan, package removal or registry takedown is not evidence that historical artefacts and credentials are safe.
Questions for the morning meeting
- Can historical builds be searched by package version and hash?
- Who can publish updates to critical internal dependencies?
- Are maintainer identities protected with phishing-resistant authentication?
- Can compromised packages be removed from every cache quickly?