Crimson Collective and standing privilege in cloud identity governance

TL;DR: Crimson Collective’s AWS campaign reportedly began with exposed keys and then moved through highly privileged IAM user creation, AdministratorAccess attachment, reconnaissance, exfiltration, and extortion, with Red Hat confirming access to a Consulting GitLab instance and claims of ~570 GB taken across ~28,000 projects according to Apono. Standing privilege remains the decisive failure mode: once valid credentials exist, the environment can be turned against itself.

NHIMG editorial — based on content published by Apono: Inside the Crimson Collective Attack Chain and How to Break It with Zero Standing Privileges

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.

Questions worth separating out

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.

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.

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.

Practitioner guidance

• 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.
• 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.
• 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.

What's in the full article

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

• A step-by-step breakdown of the AWS identity abuse sequence, including key discovery, IAM user creation, and policy attachment.
• The ZSP implementation angle for cloud teams that need to reduce standing privilege without breaking workflows.
• Apono's remediation framing for short-term credentials, JIT access, and reversible rightsizing in cloud environments.
• The article's own checklist for finding privilege gaps across human and non-human identities.

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

Crimson Collective and standing privilege in cloud identity governance?

Explore further

View Full Forum →  |  NHI Foundation Course →