TL;DR: Five npm packages published across two account handles use postinstall hooks to read AWS instance metadata, enumerate Secrets Manager, and exfiltrate environment and file data only when they detect containerised build or runtime workers, according to Xygeni. The pattern shows that install-time malware now targets live IAM roles and managed secrets, so least privilege, IMDS hardening, and scriptless installs need to be part of CI security.
NHIMG editorial — based on content published by Xygeni: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Separate build identities from runtime identities Ensure the identity used to install dependencies cannot enumerate Secrets Manager or read sensitive application secrets.
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
👉 Read Xygeni's analysis of npm packages stealing AWS credentials from containers →
npm install hooks and AWS secret theft: what should defenders change?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Container-only npm payloads are stealing AWS secrets at install time