Malicious code that runs during software installation rather than waiting for later execution. Attackers use this phase because developers often trust setup scripts and may not inspect them closely. When combined with obfuscation or credential harvesting, installation-time behavior can exfiltrate secrets before traditional runtime defenses activate.
What Installation-Time Malware Is Doing
Package installation-time malware abuses the trust developers place in setup scripts, dependency hooks, and install routines. The malicious payload executes before the package is fully in use, which makes the installation phase a high-value moment for stealing tokens, API keys, or other secrets.
This is not just a “bad package” problem. It is a supply-chain and execution-trust problem: the attacker needs the package to run once during installation, and that single window can be enough to capture secrets from local files, environment variables, or build-time tooling.
How Installation-Time Attacks Work
Common delivery paths include malicious npm or PyPI packages, compromised maintainers, typosquatting, and dependency substitution. The install step may trigger preinstall, install, postinstall, or equivalent lifecycle logic, which is why defenders often focus on package provenance and script execution policy rather than only on the final runtime binary.
Attackers often combine obfuscation with light-touch behavior so the package appears functional while it quietly performs credential harvesting. That pattern has shown up in real-world package incidents such as Shai Hulud npm malware campaign and the LiteLLM PyPI package breach, where package installation became the moment of compromise.
Why Secrets Exfiltration Happens So Early
The danger is timing. During installation, developers and CI systems often have broad access to source code, cloud credentials, signing keys, package tokens, and session material. A malicious installer can reach that material before endpoint defenses, sandboxing, or application runtime monitoring have much to observe.
Installation-time abuse is especially effective when secrets are stored in vulnerable locations such as repositories, environment variables, build agents, or developer workstations. NHIMG’s Ultimate Guide to Non-Human Identities notes that 96% of organisations store secrets outside of secrets managers in exposed locations, which helps explain why early-stage package execution can be so productive for attackers.
Security Implications for Software Delivery
Package installation-time malware is a software supply-chain issue, but its impact extends into build integrity, credential protection, and downstream trust. A compromised installer can contaminate local development, CI/CD, and release workflows without leaving an obvious application payload behind.
Because the malicious action occurs before “normal” application use, traditional runtime-only controls are not enough on their own. Teams need to treat package install behavior as part of the trust boundary, especially when install scripts can read secrets, contact external servers, or alter build outputs. CIS Controls v8 and OpenSSF both reinforce the need to reduce software supply-chain exposure and control how untrusted dependencies enter the build path.
Risk and Threat Considerations
Installation-time malware is risky because it exploits a privileged and often under-scrutinised execution moment. The main exposure is not only code compromise, but also secret theft, build tampering, and rapid downstream access if the stolen material is still valid.
Failure mechanism: The package runs during install, executes hidden or obfuscated logic, and harvests secrets before later monitoring or application controls can detect the abuse.
Impact: Attackers can exfiltrate credentials, poison build outputs, pivot into CI/CD or source control, and turn a single dependency install into broader environment compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 6 — Access Control Management | Controls package-install access paths and limits secret exposure during build and setup. |
| CIS 8 — Audit Log Management | Supports detection of suspicious install-script execution and outbound calls during package setup. | |
| CIS 16 — Application Software Security | Directly addresses secure handling of third-party packages and software supply-chain integrity. | |
| Recommendation — Restrict install-time access to secrets and revoke unnecessary build credentials. Log package installation activity and alert on unexpected script or network behavior. Verify package provenance and block untrusted installation scripts in delivery pipelines. | ||
| NIST CSF 2.0 | PR.DS — Data Security | Protects secrets and sensitive build data that install-time malware tries to exfiltrate. |
| PR.PS — Platform Security | Covers hardening of software platforms and package execution paths used during installation. | |
| DE.CM — Continuous Monitoring | Supports monitoring for malicious activity during dependency installation and setup. | |
| Recommendation — Limit secret exposure in build and install environments to reduce theft impact. Harden package execution environments and restrict risky install-time behaviors. Monitor dependency installs for anomalous script execution and exfiltration signals. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secrets and Credential Exposure | Package install malware often targets exposed tokens, keys, and credentials during setup. |
| Recommendation — Reduce secret sprawl so install-time malware has less material to steal. | ||
Practitioner Guidance
What to watch for: Scrutinise any package that depends on install scripts, postinstall hooks, unusual network calls, or unnecessary access to credentials during setup. The most important judgement is whether the install phase truly needs that level of execution and data access.
Practitioner takeaway: Treat package installation as an active execution stage, not a passive file transfer, and assume secrets present in the install environment may be targeted first.
Related resources from NHI Mgmt Group
- How should security teams respond when a widely used package is compromised and executes malware at import time?
- How should security teams detect Python-based malware hidden inside an NPM package before installation completes?
- How do security teams know whether package installation risk is under control?
- What breaks when a malicious package runs during dependency installation?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
