Look for unexpected postinstall activity, outbound traffic to unfamiliar domains, changes to ~/.ssh/authorized_keys, firewall rule edits, and any attempt to open port 22. Those are not normal package behaviours and usually indicate the install path is being used to establish durable access.
How an npm install becomes persistence, not just execution
The giveaway is that the package install stops behaving like a normal dependency action and starts changing the host or network in ways that survive the session. A persistence-oriented install often uses install-time code to plant access, alter startup or trust material, or create a path back in after the original process exits. That is why postinstall scripts, key edits, and firewall changes matter more than the package name itself.
One useful way to read this is to separate noisy installer behaviour from durable changes. A package may run code during install, but persistence is suggested when that code writes to long-lived locations such as shell profiles, SSH trust files, service definitions, scheduled tasks, or network controls. A normal install should not need to preserve attacker reachability.
Signs get stronger when the install is paired with outbound traffic to unfamiliar infrastructure, especially immediately after the package is unpacked. That combination can indicate staged retrieval, command and control setup, or validation that the host is reachable before the implant settles in. In practice, the install path becomes the delivery mechanism for the persistence step.
For broader package abuse patterns, the Shai Hulud npm malware campaign and the Rspack npm compromise 2024 show how install-time activity can move beyond simple execution into credential exposure and follow-on abuse.
Which artefacts show the install path has established durable access?
The most telling artefacts are those that create a repeatable login or execution path after the install process ends. Modifications to ~/.ssh/authorized_keys, new SSH daemons or listeners, firewall edits that open or forward port 22, and changes to startup or login scripts all suggest the install is being used to make access durable. If these appear alongside a new package install, treat the event as a persistence attempt until proven otherwise.
Not every persistence technique is SSH-based, so the same judgment should extend to other startup surfaces. Install-time changes to cron, systemd units, launch agents, user shell init files, or package manager hooks can all preserve execution across reboots or new sessions. The important distinction is whether the change creates future reachability or merely runs once and exits.
The Ledger Connect Kit npm compromise 2023 and the coa and rc npm hijacks 2021 are useful reminders that malicious packages often combine install-time execution with credential abuse, which is why new trust material appearing during install deserves immediate scrutiny.
What should defenders verify before deciding it is persistence?
Verification starts by comparing the file, process, and network changes against a known-good install of the same package version. If the package is now opening ports, editing firewall policy, touching SSH trust files, or launching an unexpected child process tree, that is not routine package initialization. Confirm whether those changes were requested by the package maintainers, whether they persist after uninstall, and whether they are tied to unsigned or unexpected scripts.
It is also worth checking whether the install modified identity-bearing material or remote access settings beyond the local host. Long-lived secrets, tokens, keys, and access files are especially important because they turn a one-time execution into ongoing access. If the install also reached out to unknown domains, assume the package may have been staging follow-on payloads or validating external control.
That is the same pattern seen in the eslint-scope npm compromise 2018 and the TrapDoor supply chain campaign 2026, where install-time behaviour was tied to credential theft and hidden instructions that outlived the initial package action.
Risk and Threat Considerations
A malicious npm install can turn a developer endpoint or build host into a durable foothold very quickly because install scripts run with the trust and reach of the local user or automation identity. Once the package can write startup material, keys, or firewall policy, it can maintain access even if the original package is removed.
Failure mechanism: The attacker abuses package install hooks or dependency trust to drop persistence artefacts, then uses those artefacts to regain access, open remote entry points, or stage later payloads after the install ends.
Impact: The host can be repeatedly re-entered, secrets can be harvested over time, and the install event can become the first step in lateral movement, data theft, or supply-chain propagation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1053 — Scheduled Task/Job | npm install persistence often abuses startup or scheduled execution paths. |
| T1098 — Account Manipulation | authorized_keys edits and other trust changes create durable access. | |
| T1136 — Create Account | install-time backdoors can establish repeatable access through new local accounts. | |
| Recommendation — Map install-time persistence to T1053 and hunt for newly created jobs or startup entries. Map SSH key and trust-file changes to T1098 and alert on unauthorized account modifications. Check for new accounts or service principals created during package installation. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | unexpected install-time changes to services, firewall, and startup settings violate baseline config. |
| Recommendation — Compare package-install changes to hardened baselines and revert unauthorized persistence settings. | ||
| NIST SP 800-53 Rev 5 | CM-7 — Least Functionality | install-time persistence often relies on enabling capabilities unnecessary for the package. |
| Recommendation — Remove unnecessary services, ports, and startup mechanisms introduced by the install. | ||
Practitioner Guidance
What to verify: Check whether the package executed postinstall or similar hooks, then review every file and network change that should not occur during a normal dependency install. Treat SSH trust file edits, firewall changes, new listeners, and outbound connections to unknown domains as high-signal indicators.
Decision rule: If the install created a durable access path, isolate the host first and preserve artefacts before remediation. Rotation, revocation, and cleanup should follow quickly, but containment comes before trying to prove which payload ran.
What good looks like: A legitimate install leaves no new persistence surface, no unexpected external callback, and no modified trust or startup artefact outside the package’s documented behaviour.
Practitioner takeaway: When an npm install starts changing how the machine can be reached later, the question is no longer whether a dependency was added, it is whether the install has already become an access-control event.