A single stolen token. Seventy-two hours. Complete cloud destruction. That is the timeline threat actor UNC6426 achieved after exploiting the 2025 compromise of the nx npm package — one of the most widely used build system tools in the JavaScript ecosystem. This attack didn't rely on zero-days or sophisticated malware. It exploited the implicit trust relationships that most development teams build into their CI/CD pipelines and never think to audit.
The nx incident is far from an isolated event. Supply chain attacks targeting the npm ecosystem have increased dramatically, with researchers documenting over 700 malicious packages in the first half of 2024 alone (Sonatype, 2024). But what separates the UNC6426 campaign is how efficiently the attackers converted a single compromised open-source package into a full AWS account takeover — exfiltrating data and destroying production systems before most organizations had finished reading the incident disclosure.
This post breaks down exactly how the attack unfolded, why CI/CD-to-cloud trust relationships are a critical blind spot, and what your team needs to do right now.
How the nx Supply Chain Compromise Became an Entry Point
The attack began before UNC6426 ever touched the victim's infrastructure. The threat actor first targeted the nx package itself — inserting malicious code designed to harvest credentials and tokens from developer environments during the build process.
Credential Harvesting at the Source
The nx package compromise introduced the QUIETVAULT credential stealer, a tool designed to silently extract tokens, API keys, and authentication credentials from the build environment. When developers and CI/CD systems ran builds that included the compromised package, QUIETVAULT captured any credentials present in environment variables, configuration files, or memory during execution.
The tokens harvested included:
- GitHub Personal Access Tokens (PATs) with broad repository permissions
- CI/CD service account credentials with elevated access
- Cloud provider API keys embedded in build environments
- NPM publish tokens for downstream package manipulation
From npm to GitHub: The Token That Opened Everything
The specific credential that enabled the AWS compromise was a GitHub token captured during the supply chain stage. This wasn't a low-privilege read-only token — it had sufficient permissions to interact with GitHub Actions workflows and, critically, with the organization's configured cloud integrations.
Pro Tip: Audit every GitHub token in your organization right now. Identify which tokens have workflow, repo, and admin:org scopes, and determine whether any of those are stored in CI/CD environment variables tied to cloud provider authentication.
The attacker used AI-assisted analysis techniques during this phase to accelerate reconnaissance — parsing captured credentials at machine speed to identify which tokens had viable cloud access paths, dramatically compressing the time between initial access and cloud exploitation.
Abusing GitHub-to-AWS Trust: The CI/CD Pivot That Caused Full Compromise
This is the phase of the attack that deserves the most attention, because it exploits an architectural pattern that millions of organizations use every day without understanding its security implications.
How GitHub-to-AWS Trust Relationships Work — and Fail
Modern DevOps pipelines commonly use OpenID Connect (OIDC) federation to allow GitHub Actions workflows to authenticate directly to AWS without storing long-lived access keys. This is widely recommended as a security improvement over static credentials — and it is, when properly scoped.
The problem is how teams configure the trust policy on the AWS IAM (Identity and Access Management) role that accepts GitHub's OIDC tokens. A correctly configured trust policy specifies the exact repository and branch that can assume the role. A misconfigured policy — one that trusts the entire GitHub organization or uses wildcard conditions — allows any workflow in the org to assume that role, including workflows triggered by an attacker with repository access.
UNC6426 used the stolen GitHub token to interact with repositories covered by an overly permissive trust policy, then assumed a highly privileged IAM role in the victim's AWS account.
Table: GitHub OIDC Trust Policy — Secure vs. Vulnerable Configuration
| Configuration Element | Secure Setting | Vulnerable Setting | Risk Level |
|---|---|---|---|
sub claim condition | Specific repo + branch (e.g., repo:org/app:ref:refs/heads/main) | Wildcard or org-level (repo:org/*) | Critical |
aud claim | Specific audience value | Default or missing | High |
| IAM role permissions | Least-privilege, scoped to required actions | AdministratorAccess or PowerUserAccess | Critical |
| Role session duration | 1 hour maximum | 12 hours (default maximum) | Medium |
| CloudTrail logging | Enabled on all regions | Partial or disabled | High |
IAM Role Creation: Escalating From Token to Takeover
With a foothold in the AWS account via the assumed IAM role, UNC6426 immediately moved to entrench their access. They created new, highly privileged IAM roles — establishing persistence that would survive even if the original compromised GitHub token was revoked.
This technique maps to MITRE ATT&CK T1098 (Account Manipulation) and represents a critical juncture in cloud intrusions. Once an attacker creates their own IAM roles or users with administrative permissions, revoking the initial access vector no longer removes their access.
The sequence escalated rapidly:
- Assume initial IAM role via stolen OIDC token
- Call
iam:CreateRoleandiam:AttachRolePolicyto create backdoor admin roles - Use new roles to enumerate S3 buckets across all regions
- Exfiltrate sensitive data from accessible buckets
- Execute destructive actions against production infrastructure
Important: AWS CloudTrail logs every IAM API call, including CreateRole and AttachRolePolicy. If you are not alerting on new IAM role creation outside your approved Infrastructure-as-Code (IaC) pipeline, you are missing one of the most reliable indicators of cloud account compromise.
The Destruction Phase: From Data Theft to Production Wipeout
What distinguishes the UNC6426 campaign from typical cloud credential misuse is the escalation to active destruction. After exfiltrating data, the attackers destroyed production systems — a tactic that maximizes damage, complicates forensic investigation, and in some cases supports ransomware leverage.
S3 Enumeration and Data Exfiltration
Using their newly created privileged roles, the threat actors enumerated every S3 bucket in the account. This is a trivial operation for any principal with s3:ListAllMyBuckets permission, which is frequently granted to developer roles that "need S3 access" without further scoping.
Organizations subject to GDPR, HIPAA, or PCI DSS face compounding consequences when S3 data exfiltration occurs — the breach triggers mandatory notification obligations even if the underlying cause was a misconfigured CI/CD pipeline rather than a traditional network intrusion.
Destruction of Production Infrastructure
The final phase of the attack involved deliberate destruction of production systems. Specific techniques included terminating EC2 instances, deleting RDS snapshots, and removing S3 bucket versioning before deleting bucket contents — actions designed to prevent recovery from backups.
Table: Cloud Destruction Techniques and Detection Opportunities
| Destructive Action | AWS API Call | MITRE ATT&CK | Detection Signal |
|---|---|---|---|
| Delete S3 objects | s3:DeleteObject, s3:DeleteBucket | T1485 | Bulk delete operations in CloudTrail |
| Remove bucket versioning | s3:PutBucketVersioning | T1490 | Versioning disabled outside IaC pipeline |
| Terminate EC2 instances | ec2:TerminateInstances | T1485 | Mass termination events |
| Delete RDS snapshots | rds:DeleteDBSnapshot | T1490 | Snapshot deletion outside backup schedule |
| Remove IAM policies | iam:DetachRolePolicy | T1531 | Policy modifications on production roles |
Defending Your Pipeline: From npm to AWS
Stopping this attack pattern requires hardening at every layer — the software supply chain, the CI/CD platform, and the cloud environment. No single control is sufficient because the attack crosses three distinct trust boundaries.
Supply Chain Security Controls
Your dependency pipeline is an attack surface. Treat it accordingly:
- Implement a software bill of materials (SBOM) and audit all third-party packages, including transitive dependencies
- Use dependency pinning with integrity hashes (
npm ciwith lockfiles, Sigstore/cosign for artifact signing) - Deploy a private package registry with upstream mirroring and malware scanning rather than pulling directly from public npm
- Enable alerts for unexpected new package versions or publisher account changes for critical dependencies
- Review GitHub Actions workflow permissions: set
permissions: read-allas the default and grant write access explicitly only where required
CI/CD and IAM Hardening
Fix your GitHub-to-AWS trust relationships before an attacker exploits them:
- Scope every OIDC trust policy to the specific repository and branch — never use wildcards
- Apply least-privilege to all IAM roles assumed by CI/CD workflows; use IAM Access Analyzer to identify overly permissive policies
- Implement AWS Service Control Policies (SCPs) at the organization level to prevent
iam:CreateRoleoutside your IaC pipeline - Enable AWS GuardDuty and Security Hub with alerting on anomalous IAM activity
- Set up immutable S3 Object Lock on critical data buckets to prevent deletion even by privileged principals
Table: Defense Controls Mapped to Attack Stages
| Attack Stage | Primary Control | Secondary Control | Framework Reference |
|---|---|---|---|
| Supply chain compromise | SBOM + dependency pinning | Private registry with scanning | CIS Control 2, NIST SSDF |
| Token harvesting | Secrets scanning in CI/CD | Short-lived tokens only | CIS Control 3 |
| GitHub-to-AWS pivot | Scoped OIDC trust policies | IAM role permission boundaries | CIS Control 6 |
| IAM escalation | SCP blocking CreateRole | CloudTrail alerting on IAM changes | NIST 800-53 AC-6 |
| Data exfiltration | S3 bucket policies + VPC endpoints | Macie for data classification | CIS Control 3 |
| Destruction | S3 Object Lock, deletion MFA | Cross-account backup isolation | NIST 800-53 CP-9 |
Key Takeaways
- Audit all GitHub-to-AWS OIDC trust policies immediately — any wildcard in the
subclaim condition is a critical misconfiguration that an attacker with any repository access can exploit - Apply least-privilege to every IAM role in your CI/CD pipeline — developer convenience does not justify AdministratorAccess on roles assumed by automated workflows
- Alert on all IAM role creation and policy attachment events — new IAM principals created outside your approved IaC pipeline are a high-confidence indicator of compromise
- Pin dependencies with cryptographic integrity verification — lockfiles alone are insufficient; sign and verify artifacts throughout your build process
- Implement S3 Object Lock on all production data buckets — this single control can prevent ransomware-style destruction even after a full account compromise
- Never store long-lived cloud credentials in CI/CD environment variables — replace all static access keys with short-lived OIDC-federated credentials, scoped tightly
Conclusion
The UNC6426 campaign is a roadmap for how modern infrastructure attacks unfold. A compromised open-source package feeds a token harvester. A stolen token exploits an implicitly trusted CI/CD pipeline. An overly permissive IAM role turns that trusted pipeline into a master key for the entire cloud environment. The attack didn't require advanced techniques — it required only that organizations had never examined the trust relationships connecting their software supply chain to their production cloud infrastructure. If your organization runs npm packages, GitHub Actions, and AWS together, this attack targets your stack directly. The controls exist. The frameworks — CIS Controls, NIST SP 800-218 (SSDF), and AWS Security Hub — all address the vectors UNC6426 exploited. The question is whether you implement them before the next campaign begins.
Frequently Asked Questions
Q: What is the nx npm package and why was it a high-value supply chain target? A: nx is a widely used monorepo build system and development toolkit with tens of millions of weekly downloads, making it present in a large number of enterprise CI/CD pipelines. Compromising a package at this scale of adoption means malicious code executes in developer environments and automated build systems across thousands of organizations simultaneously, providing attackers with broad credential harvesting opportunities.
Q: How do I check if my GitHub-to-AWS OIDC trust policy is misconfigured?
A: Navigate to your IAM roles in the AWS console and review the trust policies on any role with a token.actions.githubusercontent.com principal. Look at the StringLike or StringEquals condition on the sub claim — if it contains a wildcard (*) at the organization level or is missing entirely, the role can be assumed by any GitHub Actions workflow in your organization. Replace wildcards with exact repository and branch specifications.
Q: What does QUIETVAULT target and how does it avoid detection? A: QUIETVAULT is a credential stealer designed to harvest tokens, API keys, and secrets from CI/CD build environments, targeting environment variables and configuration files present during package installation and build execution. Its effectiveness in evading detection stems partly from executing within a trusted build process — security tools that monitor for malicious processes may not flag activity occurring inside a legitimate npm install or build command. AI-assisted obfuscation techniques reported in this campaign further complicate static and behavioral detection.
Q: If an attacker creates new IAM roles in my account, does revoking the original token stop them? A: No. Once an attacker creates their own IAM roles or users with attached policies, they have established persistence independent of the initial access vector. Revoking the compromised GitHub token prevents the original entry path but does not remove the backdoor IAM roles. A full incident response must include auditing all IAM principals created during the compromise window and revoking any that were not created through your approved provisioning process.
Q: What compliance frameworks specifically address CI/CD and supply chain security? A: NIST SP 800-218 (Secure Software Development Framework, SSDF) provides the most comprehensive guidance on supply chain and CI/CD security controls, covering dependency management, build environment hardening, and artifact integrity. CIS Software Supply Chain Security Guide addresses GitHub and CI/CD-specific controls. For cloud IAM, NIST SP 800-53 AC-6 (Least Privilege) and AWS's own CIS Foundations Benchmark provide actionable implementation guidance applicable to HIPAA, PCI DSS, and SOC 2 compliance programs.
Enjoyed this article?
Subscribe for more cybersecurity insights.