Des identifiants volés à Qubole ont ouvert les comptes AWS de dizaines d’entreprises

Des chercheurs en sécurité disent qu’un attaquant a utilisé des identifiants volés à Qubole, une plateforme d’analyse de mégadonnées, pour entrer dans les comptes Amazon Web Services (AWS) de dizaines de ses clients et copier leurs données. La firme de sécurité infonuagique Wiz a publié son enquête (en anglais) le 9 novembre, menée avec la firme de sécurité des données Sentra (en anglais), qui a repéré l’activité en premier, et Mandiant.

C’est une fuite chez des entreprises, pas dans une application grand public. Mais les entreprises touchées détiennent des données sur leurs propres clients et employés, et cela peut donc rejoindre des particuliers plus tard par leurs avis de fuite.

Comment ça a fonctionné

Les entreprises qui utilisaient Qubole lui permettaient de travailler dans leurs comptes AWS en créant un rôle spécial qui fait confiance au compte AWS de Qubole. C’est la façon standard et recommandée de brancher un fournisseur. Wiz dit qu’entre le 14 et le 26 octobre 2026, un attaquant a utilisé deux utilisateurs IAM (des identités de connexion) d’un compte AWS qu’utilise la plateforme de Qubole, et a endossé ces rôles de confiance dans les comptes de clients.

Chaque demande comprenait le bon « External ID », un code supplémentaire qu’AWS recommande pour que seul le vrai fournisseur puisse utiliser le rôle, et chacune a réussi. Comme le dit Sentra, pour AWS, « l’attaquant était Qubole ». Wiz dit que l’activité venait d’adresses du RPV Mullvad et d’un serveur loué chez OVH, pas des systèmes de Qubole.

Beaucoup de ces rôles ne servaient plus. Sentra dit que les rôles de Qubole étaient inactifs depuis le printemps, toujours en place longtemps après que les entreprises avaient cessé d’utiliser le service. Dans la plupart des environnements examinés par Wiz, les demandes de l’attaquant étaient les seules utilisations de ces rôles en octobre.

Ce qui a été pris

Une fois à l’intérieur, Wiz et Sentra disent que l’attaquant a :

• listé ce que le rôle permettait d’atteindre, puis téléchargé les fichiers de tous les compartiments de stockage S3 accessibles, plutôt que de chercher des données précises
• lu des secrets stockés dans AWS Secrets Manager, SSM Parameter Store, les réglages Lambda et les scripts de démarrage EC2, dont des identifiants de gestion de code source, de fournisseurs d’identité, de bases de données et d’intégration continue
• testé les clés trouvées avec un outil appelé TruffleHog, dont des clés AWS et des identifiants Microsoft Entra ID et Okta

Sentra compte plus d’une douzaine d’organisations touchées, dit avoir vu environ 100 mots de passe et clés lus en sept minutes, et dit que dans les comptes d’une seule entreprise, l’attaquant a téléchargé des millions de fichiers. Elle décrit des milliers de fichiers de profils de clients pris lors d’un premier passage et des sauvegardes de bases de données de production prises lors d’un dernier. BleepingComputer rapporte que Sentra a confirmé des dizaines de victimes. L’attaquant n’a rien modifié ni supprimé, ce qui, selon Sentra, l’a rendu plus difficile à repérer.

Wiz a aussi vu une vague distincte du 8 au 11 octobre, quand un acteur a testé des clés AWS appartenant à des clients, qu’il croit créées pour des intégrations Qubole, et s’en est servi dans quelques cas pour s’introduire.

Ce qu’on ne sait pas encore

Ni Wiz ni Sentra ne disent comment les identifiants de Qubole ont été volés, et aucune ne nomme les victimes. BleepingComputer (en anglais) dit ne pas avoir trouvé de déclaration publique de Qubole et lui avoir demandé des commentaires. AWS a dit à BleepingComputer que ses services « n’ont pas été compromis et ont fonctionné comme prévu ».

Ce que vous pouvez faire

Si votre organisation a déjà branché Qubole à AWS, Wiz recommande de :

1. Examiner les journaux CloudTrail depuis le 1er octobre 2026 dans chaque compte qui a un rôle Qubole, à la recherche d’utilisations du rôle depuis le compte de Qubole, puis de tout accès aux secrets ou à S3 qui a suivi.
2. Changer chaque secret qui a été lu et révoquer les sessions de rôle actives.
3. Supprimer les rôles d’intégration inutilisés et limiter ce que les autres peuvent atteindre. Ajouter des conditions de réseau source aux politiques de confiance aide aussi.

Pour tous les autres, un fournisseur dont vous n’avez jamais entendu parler peut quand même être la voie par laquelle vos données fuient. Si vous recevez un avis de fuite qui mentionne un « fournisseur tiers » ou un fournisseur infonuagique, prenez-le au sérieux et suivez ses étapes.

Comment Frame peut aider

Les victimes n’ont pas été nommées, donc il n’y a pas encore de fuite précise à ajouter. Si l’une d’elles avise ses clients et que la fuite est ajoutée à un catalogue de fuites, ajoutez-la à une adresse courriel vérifiée dans Frame : Frame montre ce qu’elle a exposé et vous donne une courte liste de vérification. Frame peut aussi chercher vos adresses courriel vérifiées dans la base de données de fuites de Have I Been Pwned. Frame ne recueille ni ne conserve jamais les données divulguées elles-mêmes.

À lire aussi

• Rapport final de Railway : des clés d’IA volées ont généré environ 740 000 $ de frais : une autre intrusion infonuagique où un réglage de confiance a servi de porte d’entrée.
• Northflank demande à tous ses clients de considérer leurs secrets comme déchiffrés : un autre cas de secrets infonuagiques pris en masse cet automne.

Sources

• Wiz, Trusted by Default: Qubole Cross-Account Access Abused in the Wild (en anglais), 9 novembre 2026
• Sentra, One Stolen Vendor Key, Every Customer’s Data Exposed: Inside the Qubole Supply Chain Attack (en anglais), novembre 2026
• BleepingComputer, Hackers exploit trusted AWS access to breach multiple cloud environments (en anglais), 10 novembre 2026