Crimson Collective
Crimson Collective est un nouveau groupe de cyber-extorsion spécialisé dans les intrusions cloud, ciblant principalement les environnements AWS pour voler des données sensibles et faire pression sur les victimes en les exposant publiquement et en exigeant des rançons.

L'origine du Crimson Collective
Le Crimson Collective est un groupe de menace émergent qui mène des attaques ciblées contre les environnements de cloud AWS dans le but d'exfiltrer des données et de les extorquer. Le groupe a attiré l'attention pour la première fois après avoir revendiqué une attaque contre Red Hat, où il aurait volé des référentiels GitLab privés. Leurs opérations témoignent d'une connaissance approfondie de l'architecture AWS, des configurations IAM et des services cloud, ce qui leur permet de tirer parti de ces composants légitimes pour passer inaperçus jusqu'à ce que l'exfiltration se produise.
Crimson Collective est un acteur nouvellement apparu, motivé par l'extorsion et ciblant les domaines du cloud AWS, avec un fort accent sur le vol de données plutôt que sur le chiffrement. Le groupe a publiquement revendiqué la violation d'une instance GitLab de Red Hat Consulting et l'exfiltration d'un grand nombre de référentiels internes ; Red Hat a confirmé l'accès non autorisé à ce GitLab de consulting, mais n'a pas validé les allégations de vol les plus sensationnelles. Les rapports de sources ouvertes associent l'activité de Crimson Collective à la reconnaissance systématique d'AWS et à l'exportation de données cloud , ce qui correspond aux observations de Rapid7 sur les récentes intrusions axées sur AWS.
Il existe des indices de collaboration ou d'alignement avec des écosystèmes plus larges de cyber-extorsion (par exemple, ShinyHunters/"Scattered Lapsus$ Hunters"), bien que les relations opérationnelles exactes soient fluides et ne soient pas définies de manière concluante.
Pays ciblés par Crimson Collective
L'impact semble mondial, avec une couverture et des notifications couvrant des organisations américaines et européennes (y compris un avis de risque de l'autorité nationale belge de cybersécurité lié à l'incident).
Industries ciblées par Crimson Collective
Jusqu'à présent, les entités ayant une empreinte importante sur cloud et un code source précieux ou des artefacts de clients ont été citées dans les rapports - les fournisseurs de logiciels et leurs services de conseil sont les plus importants ; les mentions dans les médias font également référence à de grandes entreprises et à des CER du secteur public en tant qu'exposition présumée, mais ces affirmations spécifiques n'ont pas été vérifiées par Red Hat.
Les victimes du Crimson Collective
L'instance privée GitLab de Red Hat Consulting a fait l'objet d'un accès non autorisé et d'une copie de données. Non vérifié mais revendiqué par l'acteur : vol massif de référentiel/CER et compromissions en aval de clients de la société de conseil.
Stades d'attaque et activités

Les acteurs récoltent et valident les clés d'accès AWS à long terme ayant fait l'objet d'une fuite à l'aide de TruffleHog (visible via l'option GetCallerIdentity
et l'agent utilisateur "TruffleHog" dans CloudTrail). Ils créent ensuite des utilisateurs IAM (Créer un utilisateur
, Créer un profil de connexion
, Créer une clé d'accès
) pour la persistance. En cas d'échec de la création, ils sondent les droits à l'aide de Simuler la politique principale
.

Ils attachent Accès administrateur
aux nouveaux utilisateurs (AttachUserPolicy
) et de faire un inventaire complet de l'environnement : IAM, EC2/EBS/S3, VPC/Route53/ELB, RDS, CloudWatch/Costs, SES/SNS quotas, et inventaires d'applications (une longue liste d'applications et d'outils). Décrire*
, Liste*
et Obtenir*
les appels entre services).




Ils créent des instances EC2 permissives (RunInstances
, Créer un groupe de sécurité
) et attacher des volumes (AttachVolume
) pour monter les données copiées en vue de leur traitement ou de leur transfert ultérieur.

Ils réinitialisent les mots de passe maîtres RDS (Modifier l'instance de la base de données
), prendre des instantanés RDS (CreateDBSnapshot
) et les exporter vers S3 (Démarrer la tâche d'exportation
). Ils créent des instantanés EBS (Créer un instantané
) pour la mise à disposition des données.


L'exfiltration se produit via l'accès aux objets S3 (GetObject
) et potentiellement des instances EC2 contrôlées par l'attaquant.

L'impact est extorqué : les victimes reçoivent des courriels (y compris par l'intermédiaire du SES de la victime) détaillant les données volées et exigeant un paiement ; la pression publique est amplifiée par les médias et les publications sur les sites de fuites par des groupes alliés.

Les acteurs récoltent et valident les clés d'accès AWS à long terme ayant fait l'objet d'une fuite à l'aide de TruffleHog (visible via l'option GetCallerIdentity
et l'agent utilisateur "TruffleHog" dans CloudTrail). Ils créent ensuite des utilisateurs IAM (Créer un utilisateur
, Créer un profil de connexion
, Créer une clé d'accès
) pour la persistance. En cas d'échec de la création, ils sondent les droits à l'aide de Simuler la politique principale
.

Ils attachent Accès administrateur
aux nouveaux utilisateurs (AttachUserPolicy
) et de faire un inventaire complet de l'environnement : IAM, EC2/EBS/S3, VPC/Route53/ELB, RDS, CloudWatch/Costs, SES/SNS quotas, et inventaires d'applications (une longue liste d'applications et d'outils). Décrire*
, Liste*
et Obtenir*
les appels entre services).




Ils créent des instances EC2 permissives (RunInstances
, Créer un groupe de sécurité
) et attacher des volumes (AttachVolume
) pour monter les données copiées en vue de leur traitement ou de leur transfert ultérieur.

Ils réinitialisent les mots de passe maîtres RDS (Modifier l'instance de la base de données
), prendre des instantanés RDS (CreateDBSnapshot
) et les exporter vers S3 (Démarrer la tâche d'exportation
). Ils créent des instantanés EBS (Créer un instantané
) pour la mise à disposition des données.


L'exfiltration se produit via l'accès aux objets S3 (GetObject
) et potentiellement des instances EC2 contrôlées par l'attaquant.

L'impact est extorqué : les victimes reçoivent des courriels (y compris par l'intermédiaire du SES de la victime) détaillant les données volées et exigeant un paiement ; la pression publique est amplifiée par les médias et les publications sur les sites de fuites par des groupes alliés.
Les TTP du Crimson Collective
Comment détecter les Crimson Collective avec Vectra AI
Foire aux questions
Le Crimson Collective est-il un groupe de ransomware ?
Crimson Collective est un groupe d'extorsion qui n'utilise pas de ransomware pour crypter les données. Leur jeu principal est le vol de données + l'extorsion ("double extorsion" sans casier).
Quelle est leur première action au sein d'AWS ?
Ils valident les clés à long terme ayant fait l'objet d'une fuite avec TruffleHog ; CloudTrail montre GetCallerIdentity
avec un agent utilisateur TruffleHog, suivi de tentatives de création d'utilisateurs IAM et de clés d'accès.
Comment procèdent-ils à l'escalade des privilèges ?
En joignant les services gérés par AWS Accès administrateur aux utilisateurs nouvellement créés (AttachUserPolicy
). S'ils sont bloqués, ils sondent les autorisations effectives avec Simuler la politique principale
.
Quelles sont les données auxquelles ils accordent le plus d'importance ?
Bases de données en direct (RDS), contenus de volumes EBS, buckets S3, et code source / artefacts d'engagement de type CER qui révèlent les détails de l'environnement et les jetons d'accès (Red Hat confirme l'accès au GitLab de consultation ; l'étendue de l'exposition CER reste revendiquée par les acteurs).
Comment les données sont-elles stockées et exfiltrées ?
RDS → CreateDBSnapshot
+ Démarrer la tâche d'exportation
à S3 ; EBS → Créer un instantané
puis s'attacher à EC2 contrôlé par l'attaquant ; S3 → GetObject
pour des prises directes.
Ont-ils un impact sur le courrier électronique/SMS ?
Ils énumèrent les quotas SES/SNS et peuvent les utiliser à des fins d'extorsion ou de spam à partir de l'environnement de la victime.
Quelles mesures de confinement immédiates devons-nous appliquer en cas de suspicion ?
Révoquer toutes les clés AWS à long terme ; désactiver/rotation des mandants compromis ; bloquer les CIO que vous avez partagés ; mettre en quarantaine les utilisateurs IAM et les clés d'accès créés par l'attaquant ; arrêter les vols en cours. Démarrer la tâche d'exportation
verrouiller les politiques relatives aux seaux S3 ; réaliser des instantanés médico-légaux, puis procéder à une rotation des droits du maître de la base de données. (Meilleures pratiques générales alignées sur les rapports d'incidents).
Comment se prémunir contre les tentatives répétées ?
Supprimez les clés d'utilisateur à long terme en faveur d'accréditations de rôle à court terme; appliquez le principe du moindre privilège ; limitez l'accès à la console/API par IP source / points d'extrémité VPC; activez GuardDuty, les requêtes CloudTrail lake, et les alertes d'anomalie budget/CUR ; scannez les dépôts et les magasins d'objets pour les secrets (TruffleHog/GGShield et al.) et les portes avec pre-commit/CI.
Sont-ils liés à "Scattered Lapsus$ Hunters" ?
Les rapports suggèrent une coordination/association (par exemple, amplification de l'extorsion et fuites), mais la profondeur opérationnelle n'est pas fermement établie ; à considérer comme une contiguïté de l'écosystème plutôt que comme un commandement et un contrôle avérés.
Crimson Collective est-il lié à The Com ?
Puisque Crimson Collective s'associe à Scattered Lapsus$ Hunters, on peut penser qu'ils font partie de leur communauté plus large appelée The Com.