Your AI Assistant Just Handed Over the AWS Keys
You likely trust your build tools, rely on your npm packages, and definitely trust that new AI coding assistant you just installed. However, a threat actor known as UNC6426 just proved that a single stolen developer token can lead to full AWS administrator access in exactly seventy-two hours.
We are not talking about a theoretical risk; this is a devastating software supply chain attack actively weaponizing the very tools we use to write code faster. The attackers utilized the compromised Nx npm package to escalate privileges from a local environment to full cloud dominance. Consequently, they granted themselves the power to delete databases, shut down servers, and wipe a company off the digital map. If you are not conducting regular security evaluations, you are a sitting duck in this evolving threat landscape.
Technical Threat Analysis: Weaponizing AI and Abusing Trust
This campaign, often referred to as s1ngularity, represents a dangerous evolution in supply chain attacks by targeting novel vectors like local AI agents and cloud trust relationships.
The AI Traitor in Your Terminal
The attackers are no longer just looking for your password; instead, they are hunting for your AI assistants.
- Weaponizing the AI: According to the technical analysis by Wiz, this malware specifically targets AI CLI tools already installed on developer machines, such as Claude Code, Gemini CLI, and Amazon Q.
- Forcing Secrets Spills: The malware uses dangerous flags like
--yoloor--trust-all-toolsto force these AI assistants to bypass security boundaries. Specifically, it tricks the AI agents into scanning local files for secrets and then immediately ships that data off to the attacker. - Massive Impact: This was not a narrow targeted strike; rather, the “s1ngularity” malware impacted over 2,000 GitHub accounts and 7,200 repositories. The attackers exfiltrated stolen data by creating public repositories named
s1ngularity-repositorydirectly under the victims’ own accounts.
The “Pwn Request” Vector
The entire infection chain started with a clever exploit of the foundational CI/CD infrastructure.
- The Compromise: As detailed by StepSecurity, the attackers exploited a vulnerable
pull_request_targetworkflow in the Nx GitHub repository. - Token Theft: This “Pwn Request” allowed them to steal a
GITHUB_TOKENpossessing write permissions. Subsequently, they used this token to compromise the npm publishing credentials, thereby poisoning the legitimate Nx package. - Petty Persistence: Highlighting the attacker’s audacity, the malware appended
sudo shutdown -h 0to the user’s~/.bashrcfile. Because of this, the developer’s computer would shut down every single time they opened a new terminal session, which severely disrupted remediation efforts.
From GitHub to Total Cloud Demolition
Once the attackers secured a foothold in the developer’s environment, they bypassed the local machine and targeted the “Crown Jewels” in the cloud.
- Abusing OIDC Trust: The Google Cloud Threat Horizons Report explains that the attackers exploited the OpenID Connect (OIDC) trust relationship between GitHub and AWS.
- Privilege Escalation: By leveraging “overly permissive” GitHub Actions roles, the attacker deployed a new CloudFormation stack. This stack attached the
AdministratorAccesspolicy to the attacker’s IAM principal, which granted them total control over the environment. - Data Destruction: This was not merely a data heist; rather, it was a demolition. The Hacker News reports that the actor actually started destroying production infrastructure, terminating running EC2 instances and RDS databases once they held the keys.
Mitigation and Urgent Action Required
The lightning-fast escalation observed in this attack mandates that organizations immediately review their supply chain and cloud security postures.
Immediate Action: Audit Your Cloud Trust Roles
As a Fractional CTO, I see these patterns constantly: organizations grant excessive permissions to automation roles “just to make it work.” You must correct this immediately to prevent lateral movement.
- Audit OIDC Roles: Review every IAM role trusted by GitHub (or any CI/CD provider via OIDC). Ensure these roles follow the principle of least privilege. For instance, a role used to deploy a specific lambda function should never possess
AdministratorAccess. - Use IAM Conditions: Utilize IAM conditions in your trust policies to restrict role assumption only to specific GitHub repositories, branches, or environments. Furthermore, do not allow any repository in your organization to assume a high-privilege role by default.
Broader Defensive Strategies
- Pin Dependencies: Where possible, pin npm dependencies to specific versions or use lockfiles strictly. Moreover, treat any unexpected update to critical build tools with extreme suspicion.
- Monitor AI Tool Usage: Be aware of which AI CLI tools your developers are using and audit their configuration. For security reasons, disable dangerous flags like
--yoloor--trust-all-toolsvia organizational policy if the tools support it. - Threat Hunting: CISA issued an alert regarding this broader campaign, which they call Shai-Hulud. Hunt for the “petty persistence” indicators in
.bashrcand review GitHub audit logs for unexpected repository creation or configuration changes. Be particularly wary of new campaigns like Sandworm_Mode, which include “dead man’s switches” that wipe home directories upon C2 loss.
Final Thoughts
The vulnerability exposed by the UNC6426 attack proves we can no longer trust our development tools blindly, especially when they are “popular” or “AI-powered.” Security is a distributed problem, and the integrity of your network relies on every device and every dependency. If you are building software, you must build security into the core, rather than bolting it on later.
Is your organization prepared for a lightning-fast cloud takeover, or do you need expert guidance on hardening your supply chain and CI/CD pipelines?
We can help! Schedule a security consultation with us today at https://StartupHakkSecurity.com.
