Look for packages that only make sense when installed in a specific order, share hidden token files across local directories, and contact remote endpoints with inconsistent naming. Other indicators include payloads written to disk and then executed immediately, base64-decoded responses, and repeated preinstall hooks across paired packages. Those patterns usually indicate staged control flow, not normal package behavior.
Why staged npm malware looks different from a single bad package
Staged supply chain attacks often separate delivery, coordination, and payload execution into different packages or scripts so each individual component looks less suspicious. In npm, that usually means one package plants a marker, another retrieves or unlocks the next stage, and a later hook or postinstall action completes the malicious chain.
The key difference is control flow. A single malicious package tends to do its work immediately, while a staged operation depends on sequencing, local state, or network responses to decide what happens next. That makes the attack look fragmented, but the fragments are part of one coordinated run.
Behavioral signs that point to staging
Order dependence is one of the clearest signs. If one package only behaves maliciously after a companion package has been installed, or if the malicious behavior depends on a prior file being written into a sibling directory, you are likely seeing a staged chain rather than a self-contained package.
Shared hidden files are another strong indicator. Attackers often use dotfiles, token files, or other local artifacts to pass state between packages, especially when the first package creates the token and the second package reads it to decide whether to fetch the next payload or contact a remote endpoint.
Execution patterns matter as well. When a package writes a file to disk and immediately executes it, decodes a base64 response before running it, or repeats preinstall hooks across paired packages, the behavior is usually designed to move code through several steps instead of exposing a complete payload in one place.
What the remote infrastructure reveals
Network behavior can expose staging even when package names look ordinary. Inconsistent endpoint naming, shifting hostnames, or responses that only make sense after local decoding all suggest the package is using remote infrastructure as a command-and-control layer rather than as a normal dependency service.
That matters because staging helps attackers keep the first package small and bland while reserving the harmful logic for later fetches or follow-on packages. If remote lookups, local writes, and hook execution line up in a sequence, the apparent package boundary is probably not the true boundary of the attack.
For defenders, the practical question is not just whether a package is malicious, but whether it is part of a larger multi-step workflow that spreads risk across several installs, scripts, and directories.
Risk and Threat Considerations
Staged npm attacks increase detection difficulty because no single package may contain the full malicious payload. That creates more opportunities for the attacker to hide in normal dependency installation behavior, especially when each stage is small, conditional, and only becomes harmful after local state is established.
Failure mechanism: The attacker splits logic across packages, install hooks, and downloaded responses so the malicious action is only visible when you reconstruct the full sequence across files, directories, and network traffic.
Impact: Reviewers may approve or miss packages that appear harmless in isolation, while the combined chain still enables payload execution, token theft, and broader compromise of developer or build environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK, OWASP API Security Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Staged npm payloads often execute downloaded code or hook-driven scripts. |
| T1105 — Ingress Tool Transfer | The attack often fetches later-stage payloads from remote endpoints. | |
| T1574 — Hijack Execution Flow | Install hooks and sequencing are used to divert normal package execution. | |
| Recommendation — Map hook-driven execution to script execution techniques and hunt for chained payload launchers. Track remote fetches as ingress tool transfer and block unexpected payload retrieval. Inspect install-time execution paths for flow hijacking and unauthorized script chaining. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Sequenced install, write, decode, and execute events need correlated logging. |
| CIS-16 — Application Software Security | npm packages and install hooks are software supply chain inputs that need verification. | |
| Recommendation — Centralize package-install telemetry so staged activity can be correlated across steps. Verify third-party packages before install and restrict execution of untrusted lifecycle scripts. | ||
| SLSA | Supply-chain Levels for Software Artifacts | The question centers on software supply-chain integrity and staged artifact behavior. |
| Recommendation — Require provenance and integrity checks for dependencies that can introduce staged payloads. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Unexpected install hooks, writable paths, and remote fetch behavior reflect unsafe configuration patterns. |
| Recommendation — Harden package-install permissions and disable unnecessary execution paths in build environments. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Shared hidden token files and credential-like artifacts are common staging channels. |
| Recommendation — Rotate exposed tokens and remove shared secret files that enable chained package behavior. | ||
Practitioner Guidance
What to verify: Check whether suspicious packages share filesystem markers, reuse hidden token files, or depend on prior install events before they activate. If the behavior only appears when packages are installed in sequence, treat the set as one incident, not two unrelated package reviews.
What to measure: Correlate preinstall, postinstall, and file-write activity with outbound requests and immediate execution events. A useful threshold is whether the package can explain its behavior without needing another local package, a remote decode step, or a transient token on disk.
Common mistake: Focusing only on the most obviously malicious package and ignoring the enabling companion package. In staged attacks, the support package may look less noisy precisely because its job is to prepare state or unlock the next payload.
Practitioner takeaway: When npm behavior only becomes malicious after sequencing, local state transfer, or remote decoding, investigate the package set as a staged operation and not as isolated artifacts.
Related resources from NHI Mgmt Group
- What are the signs that a malicious package or repository is being used to hide a supply chain attack?
- How should teams reduce risk from malicious npm package installs?
- How do teams respond when a supply chain attack affects a trusted npm package?
- What is the difference between a benign educational package and a malicious package in a supply chain attack?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
