Import-time npm malware shows why scripts-only defences fail

At a glance

What this is: This is a supply chain malware analysis showing that malicious npm code can execute when a package is imported, bypassing install-time controls and delivering a staged loader with anti-analysis and persistence features.

Why it matters: It matters to IAM and NHI practitioners because package compromise, runtime execution, and stealthy loader behaviour all expand the attack surface around secrets, service accounts, build pipelines, and software supply chain trust.

By the numbers:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Xygeni's analysis of import-time npm malware and staged loader behaviour

Context

The security gap here is not just malware in a package, but the assumption that install-time safeguards are enough. In practice, software supply chain abuse often shifts execution to a later runtime trigger, which means build systems can approve a dependency that only becomes active when application code imports it.

For identity and access teams, that matters because imported code frequently runs in environments that already hold tokens, service credentials, or CI permissions. Once malicious code executes inside a trusted pipeline or developer workstation, the boundary between application dependency abuse and NHI exposure disappears. That pattern is now familiar rather than exceptional.

Xygeni’s analysis fits a broader trend in which attackers prefer stealthy delivery paths that evade common hardening guidance. The package shape is unusual, but the underlying governance problem is typical: teams still over-rely on install-time controls while runtime trust remains under-governed.

Key questions

Q: How should security teams handle npm packages that run code during install?

A: Security teams should treat install-time scripts as executable code and restrict them by policy. That means allowlisting trusted packages, blocking unnecessary lifecycle hooks, and testing dependency changes in isolated environments before they reach CI. The main goal is to prevent package installation from becoming a hidden execution path for secret theft.

Q: Why do import-time payloads increase supply chain risk for NHI secrets?

A: Because they execute inside the same environments that usually hold API keys, tokens, certificates, and automation accounts. Once malicious code runs in a build runner or developer machine, it can search memory, environment variables, and cached credentials before traditional malware controls notice. That turns package trust into a direct path to NHI exposure.

Q: What breaks when teams rely only on --ignore-scripts?

A: They miss code that runs outside npm lifecycle hooks. A malicious package can stay silent during installation and activate later when the application imports it, which is why install hardening must be paired with source review, runtime monitoring, and dependency provenance checks. Scripts-only thinking creates a false sense of control.

Q: Who is accountable when a trusted dependency steals build-time secrets?

A: Accountability is shared across application owners, platform teams, and identity governance. Application teams own dependency review, platform teams own runner hardening, and identity teams own the scope and lifetime of the credentials exposed to those environments. If the same secrets are available everywhere, ownership has not been translated into control.

Technical breakdown

Why import-time execution bypasses install-script controls

npm lifecycle scripts such as preinstall, install, and postinstall are only one execution path. Here, the malicious code sits in the module entry point, so the payload runs when a developer, test suite, bundler, or linter imports the package. That design defeats the common belief that --ignore-scripts is a sufficient guardrail. It also means the attack can remain dormant until code execution occurs in a trusted environment with access to credentials, build artifacts, and internal network paths.

Practical implication: treat module import as an execution boundary and review package entry points, not just lifecycle hooks.

How the staged loader hides delivery and persistence

The first stage fetches a platform-specific executable from Cloudflare Workers hosts, then writes it to a temporary path, marks it executable, and launches it detached. The second stage is a loader that enumerates security products, checks for analysis-environment usernames, and targets AMSI and ETW telemetry interfaces to reduce visibility. Persistence is established through Windows Run keys, scheduled tasks, and macOS LaunchAgents, which gives the malware multiple paths to survive reboots and process termination.

Practical implication: monitor temporary-file execution, outbound retrieval to rotating infrastructure, and persistence artefacts across Windows and macOS.

Why in-memory execution complicates detection and forensics

The final stage is delivered encrypted and then decrypted in memory, which removes the need to write a readable payload to disk. That reduces the value of file-based scanning and makes post-incident analysis harder because the payload may never exist as a recoverable executable on the filesystem. When combined with telemetry suppression and reflective execution, the operator is aiming for the same outcome seen in many advanced supply chain incidents: short-lived initial access, minimal artefacts, and delayed detection.

Practical implication: prioritise process telemetry, network indicators, and memory-focused detection over disk-only triage.

Threat narrative

Attacker objective: The attacker’s objective is to gain durable, stealthy execution on developer and build systems while bypassing endpoint visibility and preserving access for follow-on payloads.

1. Entry occurs when a trusted npm package is imported and the module-level require statement executes hidden code outside the normal lifecycle-script path.
2. Escalation happens as the first stage retrieves a platform-specific loader, writes it to a temporary directory, launches it detached, and then chains into a second-stage binary.
3. Impact follows when the loader suppresses telemetry, installs persistence, and executes an encrypted third stage in memory to preserve access and reduce detection.

NHI Mgmt Group analysis

Import-time execution is the new supply chain blind spot: this campaign shows that install-time hardening is necessary but not sufficient. Packages can be weaponised in the module entry point, which means code review must extend to package initialisation paths and dependency provenance. For IAM and NHI teams, that is the point where trusted build activity becomes credential exposure risk.

Runtime control, not package trust, determines blast radius: the malicious package did not need broad privileges at install time because it waited for a trusted runtime context. That is a governance failure of assumption, not just hygiene. The practical lesson is to separate dependency approval from execution approval and to treat imported code as a potential access path to secrets and service identities.

Telemetry suppression turns supply chain abuse into an identity problem: once the loader patches AMSI and ETW, the environment loses visibility into process behaviour that could expose abused tokens, service accounts, or internal pivots. This is where NHI governance intersects with endpoint security, because credentials embedded in pipelines or developer workstations become the real target surface.

Delayed unpublication does not equal containment: the registry cleanup described in the article removed names, not infrastructure. That distinction matters because the operational model behind the campaign can survive package takedown, republishing, or name rotation. Practitioners should assume the attacker cares more about execution paths and delivery hosts than about the package name itself.

Build systems need a secrets-aware supply chain model: package compromise becomes materially worse when CI runners, developer machines, or internal tooling can reach long-lived tokens or privileged automation accounts. The right control lens is not just malware scanning but the lifecycle of non-human identities that the malware can steal or reuse. Teams should align package governance with secrets governance, not manage them separately.

What this signals

Package trust now needs an identity control plane: when imported code can reach secrets, the real question is not whether the dependency is legitimate, but whether the runtime identity it inherits is constrained enough to survive compromise. Teams should assume a malicious package will target the weakest NHI in the environment first.

The next control frontier is the intersection of software supply chain assurance and credential governance. Build runners, developer laptops, and internal toolchains must stop being generic trust zones and start behaving like scoped execution environments with explicit identity boundaries.

Execution-on-import is a governance concept teams should start tracking: it describes code that stays dormant until application runtime, bypassing install-centric controls and reaching trusted data paths later. That pattern is becoming more common because it aligns with attacker goals: reduce early detection, increase credential access, and leave fewer artefacts.

For practitioners

• Inspect module entry points for hidden execution Review package index files, bootstraps, and require chains for code that executes on import, not only during npm lifecycle scripts. Flag any bottom-of-file require pattern that reaches out to network, child_process, or persistence logic.
• Harden CI and developer environments against secrets exposure Reduce the blast radius of imported code by limiting which service credentials, API keys, and tokens are available on build runners and developer workstations. Use short-lived credentials and scope them to the smallest possible identity boundary.
• Detect temporary-file launch and persistence artefacts Look for executables written to temporary directories, launched detached, and followed by Run key, scheduled task, or LaunchAgent creation. Those combinations are strong signals of staged loader activity rather than ordinary package behaviour.
• Add telemetry for endpoint-security evasion Monitor for in-process modification patterns around AMSI, ETW, and debugger checks, especially when they follow a new npm dependency import. Pair process telemetry with network detection so hidden loader stages still surface.

Key takeaways

• This campaign shows that supply chain malware can bypass install-time hardening by activating only when a package is imported.
• The broader risk is not just malicious code, but the exposure of build-time secrets, service accounts, and automation credentials inside trusted environments.
• Effective defence now requires runtime code review, secrets scoping, and telemetry that can see loader behaviour before it becomes persistent access.

Key terms

• Import-time execution: Import-time execution is code that runs when a Python module is loaded rather than when a user deliberately calls a function. That behaviour matters in security reviews because it can trigger secret access, network calls, or persistence before an application has meaningfully started operating.
• Staged loader: A first-stage payload whose job is to retrieve, prepare, and launch additional malware. Staged loaders reduce the initial footprint of the attack, allow platform-specific delivery, and often use persistence or anti-analysis checks before handing control to a second or third stage.
• Telemetry Suppression: Telemetry suppression is the deliberate reduction, deletion, or distortion of security evidence so defenders cannot reconstruct what happened accurately. It includes log deletion, metadata rewriting, and hiding victim identifiers, all of which degrade investigation quality and slow containment.
• Secrets-aware supply chain: A software delivery model that assumes build systems, developer workstations, and package dependencies may be exposed to malicious code. It combines package provenance, least privilege, and limited secret exposure so compromised dependencies cannot automatically reach long-lived credentials or automation accounts.

What's in the full report

Xygeni's full analysis covers the operational detail this post intentionally leaves for the source:

• Package-by-package indicators that distinguish the malicious names from the benign lookalikes
• Binary-level inspection notes on the loader, persistence mechanisms, and anti-analysis behaviour
• The full timeline of publication, unpublication, and republishing across the affected npm names
• Additional infrastructure details around the delivery hosts and DNS fallback path

👉 Xygeni's full post covers the package anatomy, delivery infrastructure, and persistence details in depth

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and machine identity security. It helps practitioners connect identity controls to the broader supply chain and runtime risks exposed by cases like this.