Container-only npm payloads are stealing AWS secrets at install time

At a glance

What this is: Xygeni documents a five-package npm malware cluster that uses install hooks to harvest AWS credentials and managed secrets from containerised environments.

Why it matters: This matters because the payload targets IAM role credentials, environment variables, and Secrets Manager data inside build and runtime containers, which are all identity-governed assets.

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.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.

👉 Read Xygeni's analysis of npm packages stealing AWS credentials from containers

Context

npm package install hooks are increasingly being used as an execution path for credential theft, especially when the target is a containerised build worker or runtime image. In this case, the payload does not need to be imported or called because the install lifecycle itself is enough to trigger data collection.

The identity angle is direct: the malware goes after AWS instance metadata, temporary role credentials, environment variables, and managed secrets. That means the real security boundary is not the package registry alone, but the lifecycle controls around how code is installed, where it runs, and what identities are available at that moment.

The operator's decision to gate execution to a 12-character hex hostname under /app/node_modules is typical of malware designed to stay silent on developer laptops and analysis sandboxes while activating in environments likely to carry live cloud credentials.

Key questions

Q: How should security teams prevent npm install hooks from accessing cloud secrets in CI?

A: Treat package installation as code execution, not a passive download. Disable lifecycle scripts where possible, run builds with minimal identities, and deny container access to instance metadata and secret stores unless a specific job requires it. The goal is to make install-time malware inherit no useful cloud privileges.

Q: Why do containerised build workers attract NHI-targeting malware?

A: They often hold exactly the identities attackers want: instance roles, temporary credentials, registry tokens, and environment variables. A malicious package can run in the same context as the build job and immediately pivot into secret stores or cloud APIs. That makes the container boundary a high-value trust boundary, not just an execution environment.

Q: What breaks when AWS role credentials are available during package installation?

A: A malicious install script can move from local code execution to cloud API use in one step. Once it can read IMDS credentials, it can query services such as Secrets Manager, enumerate environment variables, and exfiltrate data before most controls detect the activity. The failure is over-broad runtime trust.

Q: What should teams do after a malicious npm package has run in CI/CD?

A: Contain the build environment, assume secrets on that system are exposed, and rebuild from a known-good baseline before restoring access. Then rotate npm tokens, cloud keys, SSH keys, and pipeline secrets that were reachable from the compromised host. The goal is to remove attacker persistence before any cleanup can be trusted.

Technical breakdown

Install-time execution in npm supply-chain attacks

A postinstall hook runs automatically when a package is installed, which makes it a powerful execution primitive for supply-chain malware. The attacker does not need a developer to run the code explicitly. In this cluster, the package contents are almost empty until installation, at which point the hook can inspect the host, pull environment data, and reach outward to cloud services. The real risk is not the package name or its version string, but the fact that lifecycle scripts can execute with the same context as the build or runtime process.

Practical implication: block or tightly review install scripts in CI and treat any package that shells out during install as suspicious.

Why IMDSv2 and Secrets Manager are attractive targets

The malware queries AWS instance metadata service v2 to obtain a session token, then uses that token to retrieve the role name and temporary credentials for the host. Those credentials inherit the role's permissions for their lifetime, which is why managed secrets become reachable once the role is exposed. The subsequent Secrets Manager calls turn a single credential theft event into inventory discovery and, in later variants, secret-value extraction. This is a classic privilege pivot: metadata access becomes cloud API access, and cloud API access becomes application secret exposure.

Practical implication: constrain IMDS access from containers, minimize role permissions, and separate build identities from runtime identities.

Container-only gating and exfiltration through benign-looking manifests

The payload checks for a Docker-shaped hostname and an in-container path before doing anything, which helps it avoid sandboxes and developer machines. Once active, it exfiltrates through a webhook collector and a PUT request disguised as a YAML module manifest, making the traffic look less like theft and more like package-registry activity. That combination matters because defenders often key off obvious malware patterns, while this design blends credential theft with normal software supply-chain motion. The technique depends on the target identity context being present at install time.

Practical implication: inspect outbound traffic from build containers during installs and alert on registry-like requests that carry non-registry data.

Threat narrative

Attacker objective: The attacker aims to steal live cloud credentials and application secrets from containerised build or runtime environments without triggering obvious local execution.

1. Entry occurs through a malicious npm package that executes automatically via a postinstall hook during dependency installation.
2. Credential harvesting begins when the payload reads AWS IMDSv2, environment variables, application files, and Secrets Manager listings from the host.
3. Impact follows when the harvested data is exfiltrated to external collectors, exposing cloud credentials, managed secrets, and other sensitive runtime material.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.

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 supply-chain malware is now targeting identity assets, not just source code: this cluster shows that package hooks increasingly go after IAM role credentials, environment variables, and managed secrets. That shifts the defensive problem from code review alone to runtime identity control, especially in CI and container workers where secrets are already present. The practitioner conclusion is simple: install-time execution is an identity event as much as a software event.

Container context is the new trust boundary for NHI theft: the payload only activates when it sees the shape of a real containerised worker, which means attackers are explicitly hunting the environments where non-human identities are most likely to be live. This is a governance problem because the same package can look harmless on a laptop and malicious in production. The practitioner conclusion is that validation must happen in the same execution context that the attacker targets.

Ephemeral credential exposure does not eliminate blast radius when the identity is already in place: once IMDS credentials are available, the attacker can pivot immediately into Secrets Manager and other cloud APIs before detection catches up. This is exactly where NHI governance intersects with broader cloud security, because machine identities often carry permissions that exceed the package or job that invokes them. The practitioner conclusion is to treat every runtime identity as a bounded but valuable security principal.

Secret sprawl plus lifecycle-script execution creates a hidden exposure window: we see a specific failure mode here, which is the assumption that secrets are safe because they live inside managed services or ephemeral containers. The malware proves that the relevant control gap is lifecycle timing, not storage location. The practitioner conclusion is to narrow the window in which install scripts can ever see usable credentials.

Cloud identity governance now needs package-level observability: this is not just an AppSec issue, because the payload bridges software supply chain, IAM, and secrets governance in one chain. OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 both point toward tighter authenticator management and access control, but the operational lesson is broader. The practitioner conclusion is to correlate package installation, metadata access, and secrets API use in a single detection model.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• Our research on The State of Secrets in AppSec found that the average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing confidence in their secrets management.
• Forward pivot: The Guide to the Secret Sprawl Challenge shows why fragmented secret stores make install-time credential theft harder to contain.

What this signals

Install-time attacks are collapsing the gap between software delivery and identity abuse: when package scripts can reach cloud metadata and secret stores, the deployment pipeline becomes part of the identity attack surface. That means CI governance, secrets governance, and NHI governance now need shared telemetry, not separate reviews. For practitioners, the next control gain comes from correlating install events with credential use.

Secret sprawl is turning into response sprawl: the more places credentials live, the more likely a malicious lifecycle script can find one with useful scope. Our research at The State of Secrets in AppSec shows how fragmented secret management slows remediation and weakens accountability. The named concept here is install-time identity exposure, which describes runtime code execution that has direct access to live credentials.

For identity teams, the practical signal is not just leakage but reachability: if a containerised job can touch IMDS, Secrets Manager, and environment variables in the same session, the identity boundary is already too wide. The right next step is to make build identities smaller, shorter-lived, and easier to observe across the delivery pipeline.

For practitioners

• Disable install scripts by default in CI Use --ignore-scripts for package installation in build pipelines unless a package has an explicit, reviewed need for lifecycle execution. Pair that with allowlisting for rare exceptions and log every override so the review trail is clear.
• Block container access to instance metadata Prevent workloads from reaching IMDS except where strictly required, and apply the strongest metadata hardening available so containerised jobs cannot pull host credentials. This reduces the value of any malicious lifecycle hook that runs inside the container.
• Separate build identities from runtime identities Ensure the identity used to install dependencies cannot enumerate Secrets Manager or read sensitive application secrets. Short-lived, task-scoped access limits how far a malicious package can pivot after credential theft.
• Monitor for lifecycle-script access to cloud APIs Alert when npm or other package managers trigger calls to metadata services, Secrets Manager, or similar secret stores during installation. Correlating install-time process trees with cloud API activity gives high-fidelity detection.
• Rotate exposed IAM credentials and managed secrets immediately If a package with this pattern has run in your environment, assume any reachable IAM role credentials, registry tokens, and managed secrets may be compromised and rotate them before further investigation continues.

Key takeaways

• Install-time npm malware is now a cloud identity problem because it targets live AWS credentials, not just source code.
• The cluster's impact is amplified by the speed of credential abuse and the long delay before leaked secrets are usually remediated.
• Reducing blast radius requires script control, IMDS hardening, and tighter separation between build identities and secret-bearing runtime identities.

Key terms

• Install hook: An install hook is code that runs automatically when a package is installed. It is powerful because it executes before many users or pipeline controls inspect the package contents, which makes it a common abuse path for malware hiding inside otherwise ordinary software dependencies.
• 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.
• Secret Manager: A secret manager is a control that stores and sometimes rotates credentials such as tokens, keys, and certificates. It reduces exposure of sensitive material, but it does not by itself establish ownership, entitlement context, or revocation accountability, which means governance can still fail even when storage is secure.
• Containerised Build Worker: A short-lived execution environment used to build, test, or install software inside a container. It often has access to package registries, cloud credentials, and application files, which makes it a high-value target for malware that activates only when it detects production-like container conditions.

What's in the full analysis

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

• The complete package-by-package behaviour table, including version drift across the coral-wraith and ecto-family releases
• The exact command sequence used to query IMDSv2, Secrets Manager, and file content from the host
• The raw indicator list for the webhook collector, raw-IP endpoints, and sink markers
• The authors' full timeline of how the payload evolved from simple enumeration to credential pivoting

👉 The full Xygeni article covers the payload timeline, sink markers, and defensive observations in more detail

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity for practitioners building defensible identity controls. It is suited to teams that need to connect identity governance to CI, cloud, and runtime risk.