npm install hooks turned into cloud credential theft and remote control

At a glance

What this is: This is an analysis of six malicious npm packages that abused install-time scripts for host reconnaissance, cloud metadata probing, privilege escalation, and command-and-control.

Why it matters: It matters because CI and developer pipelines often run package installs under identities that can reach secrets, tokens, and cloud metadata endpoints, creating an identity and access problem as much as a supply-chain one.

By the numbers:

• 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 the npm install-hook campaign and credential theft

Context

Install-time package execution is a supply-chain control problem, but this case also exposes an identity problem: the code runs under the privileges of the build or developer environment, not under a neutral sandbox. When those identities can reach cloud metadata endpoints or inherited tokens, a package install becomes a path to credential exposure and remote control.

The primary governance gap is trust in dependency metadata. A README that claims benign intent does not constrain what preinstall or postinstall scripts actually do, and that matters for IAM, PAM, and NHI governance because ephemeral build identities still carry standing access while the install completes.

Key questions

Q: What breaks when malicious npm packages execute during CI/CD installs?

A: The main failure is that package installation becomes code execution inside a trusted build context. That lets attacker-controlled scripts read memory, steal secrets, and potentially publish more malicious artifacts before defenders notice. The control that breaks is the assumption that dependency installation is operationally harmless. Treat install-time execution as a governed security boundary, not a routine developer convenience.

Q: Why do package installs create NHI risk in cloud build environments?

A: Because the runner identity is often a workload identity with access to metadata services, tokens, and deployment resources. Malicious install code can use that reach to discover secrets or request temporary credentials. The risk is highest when build systems share the same network path and trust assumptions as production workloads.

Q: How do security teams know if dependency installs are operating outside their intended boundary?

A: Look for evidence of network egress during install, access to metadata endpoints, unexpected privilege changes, and scripts that execute before the package is fully trusted. A normal install should not need SYSTEM execution, UAC bypass, or direct contact with external command servers. Those signals indicate the package has crossed from software delivery into active compromise.

Q: Who is accountable when a build process loads malicious code and exposes credentials?

A: Accountability usually spans engineering, platform, and security teams because the failure sits at the intersection of dependency governance, secret placement, and host hardening. NIST-style access and audit controls apply to the systems that allowed the process to run with excessive trust.

Technical breakdown

Install hooks as execution points in npm

npm lifecycle hooks such as preinstall and postinstall run automatically during package installation. That means arbitrary code can execute before the package is fully trusted or even if later installation steps fail. In this case, the same dispatcher is used across multiple packages, which turns each release into an install-time dropper rather than a normal library. The technical risk is not the package name or README, but the fact that dependency resolution itself becomes an execution boundary with network access, file access, and inherited process privileges.

Practical implication: treat lifecycle hooks as executable content and block or review them in CI before package install.

Cloud metadata probing and credential harvest risk

The Linux payload enumerates the environment, inspects /proc, checks for docker.sock, and probes the AWS ECS metadata endpoint. That endpoint is designed to hand out short-lived role credentials to the running workload, so a simple reachability check from inside an install script can be the first step toward harvesting usable cloud identity material. In build systems, this is especially dangerous because the package manager often runs inside an environment already trusted to access deployment resources, secrets stores, or registries.

Practical implication: isolate package installs from metadata services and rotate any workload credentials reachable from affected runners.

Windows elevation and command-channel abuse

On Windows, the payload adds a DelegateExecute registry entry under ms-settings, a known UAC bypass pattern that can launch elevated code without a prompt. It then uses PowerShell with execution policy bypass and Invoke-Expression, runs as SYSTEM, and polls a remote host for instructions. This shifts the threat from one-off reconnaissance to interactive remote control. The architecture shows how an install script can become both a local privilege escalation primitive and a C2 client in the same chain.

Practical implication: hunt for ms-settings DelegateExecute changes and block unsigned package execution on Windows build hosts.

Threat narrative

Attacker objective: The attacker aims to turn routine dependency installation into access to cloud credentials, elevated host control, and a reusable command channel.

1. Entry occurs through a malicious npm package that runs automatically via preinstall and postinstall hooks during npm install.
2. Escalation follows on Linux through environment profiling and metadata-service probing, and on Windows through UAC bypass plus SYSTEM execution.
3. Impact is credential exposure, remote command execution, and possible cloud or host compromise from the build environment.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Install-time execution is an identity event, not just a packaging event. This campaign succeeds because npm install runs code under a real workload identity, often inside CI where that identity can see cloud metadata, registries, and secrets. That collapses the usual boundary between software consumption and privileged execution. For identity teams, the lesson is that package managers are access-bearing runtimes and should be governed accordingly.

Metadata access is the hinge point between supply-chain compromise and NHI abuse. Once a malicious install script can reach ECS metadata or other instance identity services, it can pivot from code execution to temporary credential exposure. That is a direct NHI governance issue because workload identities are supposed to be short-lived and task-scoped, not observable by arbitrary dependency code. The control gap is uncontrolled adjacency between untrusted code and machine identity endpoints.

README disclaimers are not compensating controls. The article shows a benign, authorized-research narrative that is contradicted by the shipped code. That should sharpen a named concept: disclaimer camouflage, where prose is used to lower reviewer suspicion while the payload performs malicious actions. Security programmes need evidence-based triage that privileges behaviour over self-description. In practice, policy should assume the install script is the source of truth.

Windows package execution can chain directly into privileged persistence. The use of DelegateExecute, PowerShell bypass, and SYSTEM execution shows how a dependency can cross from initial access into host control without separate payload delivery. For endpoint and IAM practitioners, this reinforces that privileged execution paths in developer and build environments deserve the same scrutiny as production admin pathways. The practical conclusion is to harden the install surface, not just the network edge.

Software supply chain defence now overlaps with NHI governance. CI runners are increasingly identity-rich environments, and attackers are designing package payloads to reach cloud metadata, tokens, and other machine credentials. That means NHI inventory, secrets governance, and dependency security must be assessed together rather than as separate programmes. Organisations that treat package risk as purely AppSec will miss the identity exposure it creates.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases.
• A second lens on this topic is Top 10 NHI Issues, which helps teams connect dependency risk to machine identity governance.

What this signals

Disclaimer camouflage is becoming a repeatable pattern in dependency abuse, where self-described research artefacts are used to suppress suspicion while the payload behaves maliciously. That should change how teams triage package claims and why behavioural validation must sit ahead of prose-based trust. When install scripts can see machine credentials, identity governance has to treat package execution as a privileged boundary.

The programme implication is straightforward: dependency risk, workload identity, and secrets exposure now need a shared control view. If a build runner can reach metadata and execute package scripts, then the same runner is both an application delivery system and an identity exposure surface. That is the governance gap to close, not just the malicious package family that exposed it.

For practitioners

• Block install scripts in CI by default Use npm install --ignore-scripts or an equivalent control in build pipelines that do not explicitly require lifecycle hooks. Allow exceptions only for tightly reviewed packages and record the justification in change control.
• Isolate build runners from metadata services Prevent dependency-install processes from reaching cloud instance-metadata endpoints such as 169.254.170.2 and 169.254.169.254. Segment runners so package management cannot inherit the same network path as workload identities.
• Rotate any reachable workload credentials If a runner installed one of the affected packages, treat its cloud role tokens, API keys, and other secrets as exposed. Rotate credentials that were reachable from that environment and invalidate any sessions that could reuse them.
• Hunt for lifecycle-hook and UAC bypass indicators Search package logs for preinstall and postinstall execution, outbound traffic to 173.255.233.239 and *.trycloudflare.com, and Windows registry changes under ms-settings with DelegateExecute. Use those signals to scope the incident beyond the package name.

Key takeaways

• This campaign shows that npm install can function as a privileged execution path, not just a software delivery step.
• The highest-value target is the build runner’s machine identity, because metadata access can expose short-lived cloud credentials.
• Teams need to govern lifecycle hooks, runner isolation, and secret rotation together, or dependency abuse will keep becoming identity abuse.

Key terms

• Lifecycle Hook: A lifecycle hook is an automatic script that runs at a defined point in software installation or execution. In package ecosystems, hooks such as preinstall and postinstall can execute code before the dependency is fully trusted, which makes them a high-risk boundary for supply-chain abuse and credential exposure.
• Instance Metadata Service: Instance Metadata Service, or IMDS, is a local endpoint that exposes instance information and, in Azure, can mint tokens for attached managed identities. It is designed for trusted workloads on the host, so compromise of the machine can become compromise of the identity if access is not tightly controlled.
• Semantic Camouflage: Semantic camouflage is the use of ordinary-looking language to conceal malicious intent inside a prompt or instruction chain. It matters because models may treat the request as benign content generation while the attacker is actually steering toward disclosure or policy evasion.
• Build Runner Identity: A build runner identity is the account, role, or token used by CI or developer automation while packages are installed and software is assembled. It often has broader reach than a normal user session, which makes it a valuable target when malicious code executes during dependency installation.

What's in the full analysis

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

• Exact package names, version ranges, and the observed install-time behaviour across Linux and Windows hosts
• Indicator list for the collector host, Cloudflare tunnel, and registry artefacts that defenders can use for hunting
• Code-level breakdown of the preinstall and postinstall scripts, including the platform dispatcher and beacon logic
• Timeline and publication pattern for the six-package cluster, including the repeated republishes used to keep fresh versions available

👉 The full Xygeni post covers the attack chain, indicators of compromise, and host-specific behaviour in detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It is designed for practitioners who need to connect access governance to modern software delivery and cloud execution paths.