Crimson Collective shows why standing cloud privilege still fails

At a glance

What this is: This analysis breaks down the Crimson Collective AWS attack chain and shows how exposed credentials became persistent, high-privilege cloud access.

Why it matters: It matters because IAM, PAM, NHI, and cloud governance teams need to reduce what compromised credentials can do, not just how they are obtained.

By the numbers:

• The Crimson Collective claims to have exfiltrated ~570 GB across ~28,000 internal GitLab projects.
• In many organizations, NHIs now outnumber human users by roughly 200 to 1.

👉 Read Apono's analysis of the Crimson Collective AWS attack chain

Context

Crimson Collective’s campaign shows a straightforward cloud identity problem: once exposed credentials are valid, attackers can operate as trusted actors inside AWS instead of forcing their way in. In practice, that means secret sprawl, standing privilege, and weak lifecycle governance create the conditions for rapid compromise across NHI and cloud control planes.

The article is about cloud identity abuse, not a novel exploit chain. It is a familiar sequence built on leaked keys, privilege expansion, recon, data movement, and extortion, which makes it especially relevant to teams responsible for NHI governance, IAM policy design, and privileged access containment.

Key questions

Q: What breaks when a stolen cloud key can create new IAM users?

A: A stolen cloud key becomes far more dangerous when it can create new IAM users, login profiles, and additional access keys. At that point the attacker is no longer relying on one compromised secret. They have built persistence inside the account, which means revoking the original key may not remove the real foothold.

Q: Why do standing privileges make cloud breaches harder to contain?

A: Standing privileges let attackers move from initial login to policy changes, data access, and exfiltration without waiting for a human workflow. In AWS, that means the control plane itself can be repurposed by the attacker. The longer access persists, the more time they have to turn normal permissions into breach impact.

Q: How do security teams know if exposed secrets are becoming a real risk?

A: The clearest signal is whether the secret can still authenticate and whether it can reach high-value actions after login. If a leaked key can enumerate resources, create identities, or modify policy, it is already a breach-enabling identity. Inventory alone is not enough unless revocation and scope reduction follow quickly.

Q: Who is accountable when compromised credentials are used for data exfiltration?

A: Accountability sits with the teams that own secret issuance, IAM policy, and privileged access governance, not just incident response. If a credential can outlive its intended use, the issue is lifecycle control. Frameworks such as OWASP NHI and NIST CSF both point practitioners toward access scope, revocation, and monitoring.

Technical breakdown

Exposed keys as the initial cloud identity foothold

The first technical step is credential discovery. Attackers use secret-scanning tools such as TruffleHog to search repositories, configs, and other leak points for usable keys. In AWS, a valid key is often enough to authenticate through normal API paths, which means the attacker does not need to break the platform. The issue is not only exposure, but the fact that exposed secrets frequently remain active long enough to be reused. That is why secret hygiene and secret lifecycle control matter more than simple detection after the fact.

Practical implication: remove exposed keys fast, then verify whether the same identity has been reused elsewhere through API activity and access logs.

Why standing IAM users turn compromise into persistence

Once attackers have a working key, they can create IAM users, login profiles, and new access keys, then attach high-privilege policies such as AdministratorAccess. This is where standing privilege becomes a persistence mechanism. Instead of one stolen credential, the attacker manufactures durable access inside the account. In cloud environments, that persistence is especially dangerous because IAM is itself the control plane. If governance allows long-lived, reusable privileges, compromise becomes self-sustaining until the account is cleaned up.

Practical implication: reduce or eliminate permanent IAM users for machine access and continuously review who can create or expand privileged identities.

Recon, data collection, and exfiltration inside the control plane

After privilege escalation, the attacker uses cloud-native enumeration to map EC2, S3, RDS, EBS, regions, and applications. This is not noisy malware behaviour, but legitimate API use at scale. From there, the attacker can reset database passwords, create snapshots, move objects to controlled storage, and use permissive security groups to accelerate transfers. The key architectural failure is that access that looks normal at the API layer can still be catastrophic when the identity has broad authority. Detection must therefore focus on privilege scope and unusual action sequences, not just login success.

Practical implication: monitor for privilege chaining, snapshot creation, cross-account transfer, and policy changes as abuse signals, not routine admin activity.

Threat narrative

Attacker objective: The attacker’s objective was to convert leaked cloud credentials into persistent administrative access, exfiltrate data, and increase extortion pressure from inside the target environment.

1. Entry occurred when attackers found exposed AWS credentials in repositories, configs, or other leak surfaces and used them to authenticate as valid cloud identities.
2. Escalation followed when the attackers created new IAM users, login profiles, and access keys, then attached AdministratorAccess to turn a stolen key into durable control.
3. Impact came through reconnaissance, database password changes, snapshot theft, object movement, and ransom notes sent from inside the AWS account.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud 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

Standing privilege is the real failure mode in this campaign. The Crimson Collective did not need a novel exploit chain once valid credentials existed. The breach worked because always-on access was still enough to create new identities, attach admin rights, and move data at cloud speed. The implication is that cloud security programmes must treat persistent privilege as the asset attackers are most likely to turn into control.

Secret exposure becomes account takeover when lifecycle governance is missing. Keys left in repos or configs are not just leaked secrets, they are unmanaged identities waiting to be reused. This is a classic OWASP-NHI and NIST-CSF access governance problem, where discovery without rapid deactivation leaves the identity alive long after its intended use. Practitioners should read this as a lifecycle failure, not a detection failure.

Zero standing privilege is a governance model, not just a control. The campaign illustrates that short-lived access reduces the space in which an attacker can escalate, enumerate, and exfiltrate. But the deeper point is that standing admin paths create a false assumption that trust can be inherited across time. The practical conclusion is that identity architecture must be built around ephemeral access by default.

Cloud IAM has become the attack surface for NHI abuse. The attacker sequence moved directly through AWS-native objects, which means the control plane itself became the path to persistence and theft. That is why machine identity, secrets, and privileged access can no longer be managed as separate problems. Practitioners need a single view of entitlement, usage, and revocation across the account lifecycle.

Crimson Collective shows how fast compromise scales when identity is reusable. Once a stolen key can spawn more keys, more users, and more privilege, the environment starts to amplify the intrusion for the attacker. The field implication is clear: identity systems that let compromised access self-replicate are structurally unsafe.

From our research:

• In many organizations, NHIs now outnumber human users by roughly 200 to 1, according to The 2024 Non-Human Identity Security Report.
• Another finding from the same report shows that 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with human IAM efforts.
• For broader breach pattern context, see 52 NHI Breaches Analysis for the recurring controls that fail when credentials are exposed and reused.

What this signals

Secret sprawl is now an operational attack surface, not just a hygiene issue. Once credential discovery and IAM abuse are combined, the defence problem shifts from perimeter blocking to identity containment. Teams that still treat exposed keys as isolated incidents will keep missing the persistence layer that follows initial access.

Identity blast radius is the concept most teams need to operationalise now. The question is no longer whether a secret exists, but how much control that secret can unlock before it is removed. That means entitlement design, role scoping, and revocation timing need to be reviewed together, not as separate workstreams.

With 88.5% of organisations saying their non-human IAM practices lag human IAM, according to The 2024 Non-Human Identity Security Report, the gap is not awareness. It is the failure to redesign governance for machine identities that can be copied, expanded, and abused at cloud speed.

For practitioners

• Eliminate durable machine access paths Remove long-lived IAM users and static keys where workloads can use short-term credentials, role assumption, or federated access instead. Prioritise identities that can create more identities, because those are the fastest route from compromise to persistence.
• Restrict privilege escalation inside AWS Separate the ability to create identities from the ability to attach administrative policy, and alert on any attempt to combine those powers. Review IAM permissions boundaries, SCPs, and break-glass paths to make sure one stolen key cannot manufacture admin control.
• Hunt for secret exposure in code and configs Scan repositories, build artefacts, and configuration stores for keys that can still authenticate, then revoke and rotate them as a set. Treat exposed secrets as active identities until proven otherwise, because attackers use them that way.
• Control snapshot and transfer abuse Watch for unexpected RDS snapshot creation, EBS volume attachment, cross-account object movement, and permissive security group changes. These actions often mark the point where credential theft turns into bulk exfiltration.

Key takeaways

• Crimson Collective’s attack path shows that exposed cloud credentials are dangerous because they can be turned into persistent administrative access.
• The scale of the reported activity, including ~570 GB across ~28,000 GitLab projects, shows why standing privilege creates outsized breach impact.
• Reducing durable access paths, not just rotating secrets, is the control that most directly limits this attack pattern.

Key terms

• Standing Privilege: Persistent access that remains available without needing a fresh approval or time-bound grant. In cloud environments, standing privilege is risky because a stolen credential can be reused immediately and can often perform many actions before anyone notices. The control objective is to make high-risk access temporary, scoped, and revocable.
• Non-Human Identity: A non-human identity is any machine- or software-based identity used to authenticate and act in a system, including service accounts, API keys, tokens, certificates, and AI agents. These identities can outnumber humans by a large margin, which makes their lifecycle, privilege scope, and revocation discipline central to security.
• Zero Standing Privileges: Zero Standing Privileges is an operating model where access is not left permanently available. Permissions are granted only when needed and removed immediately after use, reducing the damage a stolen credential or overprivileged account can cause. It is both a control pattern and a governance stance.
• Secret Sprawl: Secret sprawl is the accumulation of credentials, keys, and tokens across repositories, configs, pipelines, and shared tools without strong ownership or lifecycle control. The security problem is not only exposure, but also persistence, because secrets that remain valid become reusable identities for attackers.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Apono: Inside the Crimson Collective Attack Chain and How to Break It with Zero Standing Privileges. Read the original.