Phished npm Maintainer Led to Debug/Chalk Hijack

How the attack worked

Amazon attributes the compromise of the widely used npm packages debug and chalk to a North Korea-linked actor. The entry point was social engineering rather than a technical exploit: a trusted package maintainer was phished through a lookalike npm domain designed to look like the real sign-in page. Once the attacker captured those credentials, they used the maintainer's legitimate publishing access to push malicious updates into at least 18 packages.

A separate but related incident involved a file named core.js, disguised as the legitimate core-js package inside a repository. This file only activated when it received a specific hash input, at which point it pulled an operating-system-specific second stage from a hardcoded command and control domain, obfuscated using base64 over an XOR cipher.

Why it succeeded

The pattern Amazon describes repeats across multiple campaigns tied to this actor: socially engineer a trusted maintainer, then publish an update. This works because publishing rights are treated as a routine part of a maintainer's job, not as a high-value credential that needs extra scrutiny. A convincing lookalike login page is often enough to bypass a moment of caution, especially when the request looks like a standard re-authentication step.

The payload itself was also built to avoid detection. Researchers at Aikido and Wiz found browser-side code that hooked into fetch, XMLHttpRequest, and wallet APIs to quietly rewrite cryptocurrency transaction addresses before a user signed a transaction. Because it left no persistence on the machine, traditional endpoint detection had little to find.

What to watch for

• Login pages for package registries that use a domain slightly different from the official one
• Unexpected prompts to re-authenticate before routine publishing or release tasks
• Dependency files that mimic well-known library names but appear in the wrong repository
• Obfuscated code, trigger-based logic, or unexplained outbound network calls in a dependency
• Wallet or transaction behavior that changes unexpectedly in the browser

How to build resistance

Defenders can reduce exposure by training developers and maintainers to verify the exact domain before entering registry credentials, and by treating any request tied to publishing rights as high-risk enough to warrant out-of-band verification. Teams should also recognize that supply-chain compromises do not always involve installing malware on a device. Encouraging developers to flag unusual dependency behavior, such as obfuscation or unexpected network calls, before it reaches production gives organizations a chance to catch these updates early rather than after distribution.

How did attackers compromise the npm debug and chalk packages?

Amazon reported that a trusted maintainer was phished through a lookalike npm domain, and the stolen access was used to publish malicious updates to at least 18 packages, including debug and chalk.

What did the malicious code actually do?

Researchers at Aikido and Wiz documented browser-side code that intercepted fetch, XMLHttpRequest, and wallet APIs to rewrite cryptocurrency transaction addresses before a user signed, without leaving persistence on the machine.

Was there a second, related compromise?

Yes, Amazon described a separate package containing a disguised file named core.js that triggered on a specific hash input and pulled a second-stage payload from a hardcoded command and control domain.

What are the indicators of compromise tied to this campaign?

Amazon listed the network indicators npmjs[.]store and the IP address 216[.]74[.]123[.]126 as part of the infrastructure used in the trigger-based payload.