How to Detect the North Korean npm Infostealer RAT in Your Supply Chain

The new npm infostealer reports are not interesting because of the label attached to them. They matter because the delivery path is ordinary JavaScript work: install a package, let the lifecycle hooks run, and you may hand an attacker a workstation full of secrets.

What this North Korean npm infostealer RAT is trying to do

The malware in the recent reporting is a RAT-style infostealer aimed at developer environments. The goal is not one token. It is to collect enough local material to move from a single compromised laptop into source control, cloud accounts, and CI systems.

That usually comes down to three steps:

1. execute during install or shortly after,
2. inventory the machine for secrets and identity material,
3. exfiltrate findings to attacker infrastructure.

In practice, the code usually favors quiet collection over flashy behavior. That is what makes it dangerous in a software supply chain: it can look like a normal package install until the damage is already downstream.

Why developers are the target

Developers are high-value because their machines contain trust that production systems often inherit.

A workstation can expose:

• npm or Git credentials
• SSH keys and SSH agent access
• cloud CLI profiles
• browser-saved sessions
• .env files, local config, and build-time secrets
• access to private registries and internal repos

If an attacker gets even one valid developer token, they may be able to publish a poisoned package, read private code, or pivot into CI/CD. The workstation is the bridge, not the endpoint.

Infection paths to watch in the JavaScript supply chain

Typosquats, dependency confusion, and maintainer compromise

The JavaScript ecosystem still gives attackers several easy entry points:

• typosquatted package names
• dependency confusion against internal package names
• compromised maintainer accounts
• malicious updates to otherwise legitimate packages

The issue is not only whether a package is known-bad. It is whether your install policy trusts new code too quickly. If a package can land in node_modules and run arbitrary scripts, the attacker gets execution with your developer’s ambient access.

Post-install scripts and environment harvesting

The highest-risk behavior is still install-time execution.

Watch for packages that use:

• preinstall
• install
• postinstall

Those hooks can read environment variables, inspect the filesystem, and call out over the network before a developer even opens the app.

A small example of what to inspect:

{
  "scripts": {
    "postinstall": "node setup.js"
  }
}

That line is not malicious by itself. The problem is what the script does next: reading ~/.ssh, scraping browser data, or pulling secrets from local config files.

What the malware typically steals

Tokens, SSH material, and local secrets

Based on the behavior described in the report, the target set is what you would expect from a developer infostealer:

• npm auth tokens
• Git credentials
• SSH private keys
• cloud provider credentials
• browser cookies and session artifacts
• environment files and secret-bearing config

A good mental model is: if it helps you authenticate without a password prompt, the malware wants it.

What makes developer workstations especially valuable

Developer machines are attractive because they are noisy in a useful way. They are full of legitimate authentication material, but they also routinely talk to many services. That gives attackers multiple choices for exfiltration and follow-on abuse.

Once a token is stolen, the next stage may not even need malware. It might be a normal API call from a clean host.

Detection signals you can actually test

Package metadata and install-time behavior

Start with the package itself.

Things I check:

• unexpected postinstall or preinstall hooks
• new maintainer accounts with little history
• recent publish activity on a package that used to be quiet
• bin entries that point to opaque scripts
• obfuscated or compressed JavaScript in publish artifacts

You can automate this in CI by flagging packages whose lifecycle scripts change between lockfile updates.

const fs = require("fs");

const pkg = JSON.parse(fs.readFileSync("node_modules/suspicious-package/package.json", "utf8"));

const scripts = pkg.scripts || {};
for (const name of ["preinstall", "install", "postinstall"]) {
if (scripts[name]) {
  console.log(name, "=>", scripts[name]);
}
}

Host and network indicators

On the host, look for unexpected file access in common secret locations:

• ~/.ssh
• ~/.aws
• ~/.config
• project .env files
• browser profile directories

On the network, suspicious signs include:

• outbound requests during install
• POSTs to newly registered or unrelated domains
• short-lived connections after package extraction
• DNS lookups that do not match the package’s normal behavior

If a dependency that used to be local-only suddenly phones home during install, treat that as a review failure.

CI/CD and registry monitoring

Your CI can catch what a laptop misses.

Track:

• changes to lockfiles outside expected updates
• new packages added without a corresponding code review
• registry publish events from your org
• installs that require scripts in build jobs that normally do not

If you mirror packages internally, compare what was published upstream against what your builders actually consume. A poisoned package often becomes obvious only when you diff install behavior, not package names.

Defensive controls that reduce the blast radius

Lockfile and install policy

The most useful guardrails are boring:

• require lockfiles in CI
• use npm ci instead of loose installs where possible
• review lifecycle scripts before approving dependency bumps
• avoid running package installs as a privileged user
• prefer allowlists for critical build environments

If your workflow depends on arbitrary postinstall execution, you already gave the attacker a lane.

Secret handling and machine hygiene

Reduce what the machine can leak:

• keep long-lived tokens off dev laptops
• use short-lived cloud credentials
• store secrets in a manager, not in shell history or dotfiles
• separate browsing, coding, and admin tasks where possible
• keep SSH agents and cached credentials tightly scoped

Registry, publishing, and review safeguards

For the supply chain itself:

• enforce 2FA on publishing accounts
• restrict who can publish maintained packages
• monitor for maintainer changes
• review package diffs, not just version numbers
• use provenance and signing where your tooling supports it

This is especially important for org-owned packages. A compromised maintainer account can look like a normal release if you only check the semver bump.

A practical response workflow if you installed it

1. Disconnect the machine from the network if exfiltration is still a concern.
2. Preserve process, network, and filesystem evidence before wiping anything.
3. Revoke and rotate all credentials that were accessible on the host.
4. Invalidate npm, Git, cloud, and SSO sessions.
5. Check recent package installs, shell history, and browser sessions for follow-on abuse.
6. Rebuild the workstation from a known-good baseline.
7. Hunt for the same package hash or version in CI images and teammate machines.

Do not stop at “remove the package.” The real incident is the credential exposure, not the directory under node_modules.

Conclusion

The lesson is simple: npm malware does not need an exotic exploit when developers already run untrusted code during install. The best detection is a mix of package-review discipline, install-time monitoring, and secret hygiene that assumes a workstation will eventually be touched.

If you can answer “what can this package read, and where can it send it?” before you install it, you are already ahead of most supply-chain failures.