Crimson Collective does not need an exploit: it finds long-term cloud access keys that have leaked into code and documents, uses them to make itself an administrator, and copies databases and repositories before sending an extortion note from the victim's own email service. The group came to wide attention in early October 2025, when it claimed the theft of Red Hat Consulting repositories and Rapid7 published its analysis of the group operating inside AWS accounts. This profile draws on Rapid7 and Intel 471 research, Red Hat's own statement, BleepingComputer reporting and AWS documentation. It covers what is known about the group, its techniques mapped to MITRE ATT&CK v20, how it abuses non-human identities, and the detections and controls that break its chain. It is written for cloud security, identity and detection teams; attribution follows each source's wording, and the page names no individuals.
Key takeaways
- Leaked long-term keys are the entry point. Rapid7 found that the group used leaked AWS access keys, located with the open-source secret scanner TruffleHog, and that TruffleHog's user agent was the first activity in CloudTrail in every account it compromised.
- Persistence follows within minutes. In every compromised account the group attempted CreateUser; where that succeeded it added CreateLoginProfile and CreateAccessKey and attached the AWS managed AdministratorAccess policy to the new user.
- Data theft uses the victim's own cloud. RDS master passwords were reset, databases snapshotted and exported to S3, and EBS snapshots attached to attacker-launched instances, so most of the chain appears as normal control plane activity.
- Stolen repositories feed the next intrusion. The group claimed that Red Hat consulting reports held tokens and database connection strings for customer environments, which makes any credential shared with a supplier a potential target.
- The defences are identity hygiene. Replacing long-term keys with roles and temporary credentials, scanning repositories for secrets, and alerting on IAM user creation and AdministratorAccess attachments address most of the documented chain.
Who they are
Crimson Collective is an extortion group focused on cloud environments and code repositories. As of November 2026 it has no MITRE ATT&CK group entry, so the names and claims below come from vendor research and the group's own statements. Rapid7 notes that the group's extortion note uses "we", suggesting more than one person, but says its composition remains unclear.
| Item | What sources say | Source |
|---|---|---|
| First documented activity | Two AWS cases in September 2025, with increased activity in the weeks before Rapid7's 7 October 2025 publication | Rapid7 |
| Public channel | Telegram, where the group published a directory listing of allegedly stolen Red Hat repositories and a list of consulting reports from 2020 to 2025 | BleepingComputer |
| Earlier claim | A brief defacement of a Nintendo topic page, adding contact details and Telegram links, the week before the Red Hat claim | BleepingComputer; Intel 471 lists Nintendo as an alleged victim |
| Targets | AWS environments and cloud-hosted GitLab deployments; technology and software development organisations in North America, Europe and Asia | Intel 471 |
| Motivation | Financial extortion and theft of intellectual property | Intel 471; Rapid7 |
| Associations | On or around 4 to 6 October 2025, announced a partnership with Scattered LAPSUS$ Hunters to use the ShinyHunters data leak site for extortion | BleepingComputer |
The association matters for defenders because it joins a group skilled at finding cloud keys with an extortion operation that already runs a leak site. See the Scattered LAPSUS$ Hunters Profile and the ShinyHunters Threat Actor Profile for those groups, and the Threat Actor Groups Guide for how naming works across vendors.
The Red Hat Consulting incident
On 2 October 2025 Red Hat said it had detected unauthorised access to a GitLab instance used for internal Red Hat Consulting collaboration on select engagements, and that an unauthorised third party had accessed and copied some data. Red Hat described the data as possibly including project specifications, example code snippets, internal communications about consulting services and limited business contact information. It removed the access, isolated the instance, contacted the authorities, added hardening measures and said it had no reason to believe its other services, products or software supply chain were affected. Red Hat's statement does not name the attacker.
Crimson Collective claimed the intrusion publicly. BleepingComputer reported claims of nearly 570 GB of compressed data from about 28,000 repositories, including roughly 800 Customer Engagement Reports, and the group's statement that it had found authentication tokens and full database URIs it could use against customer infrastructure. These remain the group's claims. GitLab said the incident affected a self-managed GitLab Community Edition instance and that its own platform was not compromised. After the partnership announcement, a Red Hat entry appeared on the ShinyHunters leak site with samples of consulting reports and a 10 October deadline. See the Red Hat Consulting GitLab Breach 2025 analysis for the timeline and the credential lessons for customers.
The lesson for every organisation that uses consultants or managed service providers is the same: assume that any token, key or connection string you have shared with a supplier is sitting in that supplier's documents and repositories, and plan to rotate it the day the supplier reports an incident.
Tactics and techniques (MITRE ATT&CK)
The techniques below are those Rapid7 mapped from its AWS cases, verified against ATT&CK v20. In v20, the Modify Cloud Compute Infrastructure sub-techniques sit under tactic TA0112 Defense Impairment.
| Tactic | Technique | What Rapid7 describes | Primary defence |
|---|---|---|---|
| Initial access | T1078.004 Valid Accounts: Cloud Accounts | Leaked long-term AWS access keys, found with TruffleHog | Roles and temporary credentials; secret scanning; GuardDuty CompromisedCredentials findings |
| Persistence | T1136.003 Create Account: Cloud Account | CreateUser attempted in every account; CreateLoginProfile and CreateAccessKey where it succeeded | SCP denying IAM user and key creation outside a break-glass path |
| Privilege escalation | AttachUserPolicy with AdministratorAccess (Rapid7 does not assign an ID) | AWS managed AdministratorAccess attached to the new user | Permissions boundaries; alert on any AdministratorAccess attachment |
| Discovery | T1087.004 Cloud Account; T1069.003 Cloud Groups; T1580 Cloud Infrastructure Discovery; T1526 Cloud Service Discovery; T1619 Cloud Storage Object Discovery | Broad read-only calls across IAM, EC2, EBS, S3, RDS, networking, billing, SES and SMS quotas; SimulatePrincipalPolicy to map permissions of weaker keys | Baseline per-principal API use; GuardDuty Discovery anomalies |
| Lateral movement | T1021.007 Remote Services: Cloud Services | Operation across several compromised accounts in the same environment from reused IP sets | Separate accounts with SCP guardrails; restrict key use by source network |
| Defence impairment | T1578.001 Create Snapshot; T1578.002 Create Cloud Instance; T1578.005 Modify Cloud Compute Configurations | RDS and EBS snapshots; new instances with permissive security groups; RDS master password changed with ModifyDBInstance | Alert on snapshot creation and export outside change windows; restrict ModifyDBInstance |
| Collection | T1530 Data from Cloud Storage; T1213.003 Code Repositories; T1074.002 Remote Data Staging | StartExportTask of RDS snapshots to S3; GetObject on buckets; focus on databases and project repositories | S3 data events in CloudTrail; restrict export permissions |
| Exfiltration | T1567 Exfiltration Over Web Service | Data taken out through AWS services | Egress review; VPC endpoint and bucket policies limiting access |
After exfiltration, Rapid7 reports that the group sent an extortion note through Amazon Simple Email Service inside the victim's account, as well as from an external address. Checking SES and SMS sending quotas during discovery is therefore an early warning, not just noise.
How they abuse non-human identities
- Static access keys as the front door: every documented AWS intrusion began with an IAM user's long-term access key. Keys of this kind do not expire on their own, carry no device or session context, and work from anywhere unless a policy condition says otherwise. See the AWS Access Keys Security Guide.
- Secret scanning turned around: the group used the same class of tool that defenders use to find secrets. If your scanners run less often or cover fewer locations than an attacker's, you will learn about a leak from your CloudTrail logs. See the Git Secret Scanning Guide.
- Weak keys triaged, not discarded: Rapid7 says keys without permission to create users were either abandoned or tested with SimulatePrincipalPolicy to map what they could do. A low-privilege key is still a reconnaissance tool.
- New identities over stolen ones: creating a fresh IAM user with a console password and a new key gives the group access that survives rotation of the original leaked key. Rotation alone is not containment.
- Database credentials reset, not stolen: changing the RDS master password with ModifyDBInstance gives the group database access without ever reading a secret, and breaks the application that relied on the old one.
- Supplier-held credentials: the Red Hat claim centres on tokens and connection strings for customer environments stored in consulting reports. Record every credential issued to a supplier in a register with an owner and expiry, as in the Third-Party Credential Register Template.
Detection opportunities
Most of the chain is visible in CloudTrail management events, and several steps have native Amazon GuardDuty finding types. See the AWS CloudTrail Guide and the Amazon GuardDuty Guide for setup.
| Behaviour | Signal | GuardDuty finding type that may fire |
|---|---|---|
| Key validated by a scanner | CloudTrail userAgent containing the TruffleHog string from a source IP with no history for that key | CredentialAccess:IAMUser/CompromisedCredentials where AWS threat intelligence has flagged the key |
| Persistence | CreateUser, CreateLoginProfile or CreateAccessKey by a principal that never does this | Persistence:IAMUser/AnomalousBehavior |
| Privilege escalation | AttachUserPolicy with policyArn arn:aws:iam::aws:policy/AdministratorAccess | PrivilegeEscalation:IAMUser/AnomalousBehavior |
| Permission mapping | SimulatePrincipalPolicy from an access key principal | Discovery:IAMUser/AnomalousBehavior |
| Broad discovery | Bursts of Describe and List calls across many services, plus GetSendQuota and GetSMSAttributes | Discovery:IAMUser/AnomalousBehavior |
| Database theft | ModifyDBInstance changing the master password, then CreateDBSnapshot and StartExportTask | Exfiltration:IAMUser/AnomalousBehavior |
| Volume theft | CreateSnapshot, RunInstances, CreateSecurityGroup and AttachVolume in quick succession | Exfiltration:IAMUser/AnomalousBehavior |
| Extortion delivery | SES SendEmail or SendRawEmail from a principal or region with no history of sending | None specific; build a custom rule |
Measure the programme with a small set of numbers: count of IAM users with active long-term access keys (trend to zero for workloads), age of the oldest active key, median time from a secret-scanning hit to key deactivation, percentage of accounts covered by an SCP that restricts IAM user creation, and time to triage a high-severity GuardDuty IAM finding.
Prevention and hardening
- Find exposed keys first: list IAM users with active access keys and their last-used data, run secret scanning across all repositories (including self-managed GitLab and wikis), and deactivate any key found in code. See How to find unused AWS IAM roles and access keys.
- Replace long-term keys: AWS's IAM best practices call for workloads to use IAM roles with temporary credentials, with IAM Roles Anywhere or federation for workloads outside AWS, and for humans to use federation through an identity provider. Pilot one workload at a time, keep the old key inactive (not deleted) for a short rollback window, then delete it.
- Set guardrails: use service control policies to deny iam:CreateUser, iam:CreateAccessKey and iam:CreateLoginProfile except for a named administrative role, and permissions boundaries so that no delegated role can grant AdministratorAccess. Test in a sandbox organisational unit before applying to production.
- Restrict where keys work: where a long-term key must remain, add policy conditions limiting it to known source networks or VPC endpoints, as Rapid7 recommends.
- Protect data paths: limit rds:ModifyDBInstance, rds:StartExportTask and ec2:CreateSnapshot to the roles that need them, and enable S3 data events for buckets holding exports.
- Treat supplier credentials as part of your estate: issue time-bound, scoped credentials to consultants, record them, and rotate everything a supplier could hold when it reports an incident. See the NHI Offboarding and Decommissioning Guide.
Smaller organisations with one or two AWS accounts should start with steps 1 and 2 and enable GuardDuty; the rest is incremental. Larger estates with AWS Organizations get the most from step 3, because a single SCP removes the persistence path across every account at once.
Responding to a suspected intrusion
- Contain identities, not just the key: deactivate the leaked key, then find and disable every IAM user, login profile and access key created since the first suspicious call. Remove any AdministratorAccess attachments made in that window.
- Check data paths: list RDS snapshots, export tasks, EBS snapshots, new instances and security groups created since first access, and preserve the CloudTrail records before cleaning up.
- Restore service credentials: reset RDS master passwords through your secrets store and redeploy dependent applications, since the attacker's reset will have broken them.
- Look for the source of the leak: the key came from somewhere: a repository, a document, a supplier. Find it, or the next key will leak the same way. See the Cloud Access Key Leak Playbook and, for stolen code, the Source Code Leak Response Playbook.
- Do not engage through the attacker's channels: route any extortion contact to legal, incident response and law enforcement; preserve the SES sending records as evidence.
Common failure patterns
- Rotating the leaked key and stopping there: the group creates its own users and keys straight away, so rotation without a hunt for new identities leaves it inside.
- Scanning only active repositories: keys in archived projects, wikis, issue attachments and consulting reports are as usable as keys in main branches.
- Allowing IAM user creation everywhere: with no SCP, any key with IAM write permissions can mint new administrators.
- Ignoring read-only bursts: discovery calls are dismissed as noise, although they precede every data theft step Rapid7 describes.
- Forgetting credentials held by suppliers: the Red Hat Consulting GitLab Breach 2025 shows how credentials shared for a project can outlive it in a supplier's records.
Practitioner checklist
- Inventory every IAM user with an active access key and the workload that uses it.
- Run secret scanning across all code hosts, wikis and document stores, including self-managed instances.
- Move workloads to IAM roles and temporary credentials; delete keys once migrated.
- Apply an SCP that blocks IAM user, login profile and access key creation outside an approved role.
- Alert on AttachUserPolicy with AdministratorAccess and on TruffleHog user agents in CloudTrail.
- Enable GuardDuty in every account and region and triage IAM findings within a defined time.
- Restrict RDS export, snapshot and master password changes to named roles.
- Keep a register of credentials shared with suppliers and a plan to rotate them on notice of a supplier incident.
Standards and references
- Rapid7: Crimson Collective, a new threat group observed operating in the cloud
- Red Hat: Security update, incident related to Red Hat Consulting GitLab instance
- Intel 471: Crimson Collective
- AWS: Security best practices in IAM
- AWS: GuardDuty IAM finding types
- MITRE ATT&CK: Valid Accounts: Cloud Accounts
- BleepingComputer: Red Hat confirms security incident after hackers claim GitLab breach
- BleepingComputer: Red Hat data breach escalates as ShinyHunters joins extortion
Related NHI Mgmt Group resources: Scattered LAPSUS$ Hunters Profile · AWS Access Keys Security Guide · Cloud Access Key Leak Playbook · Red Hat Consulting GitLab Breach 2025