Qubole : des accès AWS non révoqués ont servi à voler secrets et données

Wiz a rendu publique le 9 novembre 2026 une campagne qui a touché plusieurs entreprises clientes de Qubole, une plateforme de traitement de données dans le cloud. Le Monde Informatique en détaille le déroulé ce 10 novembre. Des attaquants non identifiés se sont servis d’identifiants compromis associés au compte AWS de Qubole pour entrer dans les environnements cloud de ces clients et y voler des secrets et des données. Wiz parle d’une vaste campagne opportuniste visant la chaîne d’approvisionnement, mais ne précise pas combien d’organisations sont touchées. Les faits rapportés ici viennent de l’enquête menée par Wiz et par les équipes de réponse aux incidents de Mandiant. Elle a été lancée après le signalement d’activités suspectes par Sentra, une entreprise spécialisée dans la sécurité des données.

Une autorisation qui survit au départ du client

Le mécanisme détourné n’a rien d’exotique. Pour administrer les ressources de calcul et accéder au stockage de ses clients, Qubole s’appuie sur des rôles IAM : chaque client autorise, par une politique de confiance, le compte AWS de Qubole à endosser un rôle d’intégration dans son propre environnement. Ce modèle a un avantage réel, puisqu’il évite de transmettre à un prestataire des clés d’accès AWS de longue durée.

Cette politique de confiance ne disparaît pas quand on cesse d’utiliser le service. Selon Wiz, de nombreuses organisations l’avaient laissée en place après avoir quitté la plateforme. Les attaquants ont donc pu atteindre des environnements où Qubole ne servait plus. Ce cas dépasse un seul fournisseur : chaque rôle ouvert à un tiers donne un accès qui dure tant que la relation de confiance existe, que le contrat coure encore ou non.

Du 14 au 26 octobre

Les premières opérations malveillantes retracées datent du 14 octobre. Des identifiants liés au compte Qubole ont alors appelé l’API sts pour obtenir des identifiants temporaires correspondant aux rôles d’intégration gérés par les clients. Les appels venaient du compte AWS 805246085872, avec l’identifiant IAM AIDA3W7DIFLYOLTK63SFS. L’activité s’est poursuivie le 15 octobre. À partir du 18, un second utilisateur IAM du même compte a été employé, et l’activité a duré jusqu’au 26 octobre.

Une fois dans les environnements, les attaquants ont inventorié les ressources, puis récupéré des identifiants, des clés et d’autres secrets conservés dans Lambda, Secrets Manager et SSM Parameter Store. Ils ont extrait des données de S3, en téléchargeant parfois des compartiments entiers. Ils ont aussi utilisé TruffleHog pour tester des identifiants AWS des victimes. Ils ont trouvé des secrets Microsoft Entra ID et demandé des jetons OAuth avec des identifiants clients Okta découverts dans les environnements AWS. Un accès cloud mal fermé a donc pu servir de point de départ vers d’autres services.

Wiz n’attribue la campagne à aucun groupe et ne sait pas ce qu’il est advenu des données volées. Les chercheurs ont aussi repéré, entre le 8 et le 11 octobre, une autre campagne qui exploitait des clés AWS appartenant aux clients pour des intégrations Qubole. Elle a compromis quelques environnements, mais aucun lien définitif avec la première n’est établi.

Ce que les organisations concernées doivent vérifier

Toute organisation qui a intégré Qubole, qu’elle l’utilise encore ou non, est invitée à renouveler ses identifiants. Cette mesure ne met pas fin aux sessions temporaires déjà délivrées. Wiz recommande donc d’examiner les journaux CloudTrail depuis le 1er octobre et d’y chercher les événements AssumeRole dont le champ userIdentity.accountId correspond au compte de Qubole, en particulier lorsqu’ils viennent d’adresses IP extérieures à AWS.

Pour chaque session repérée, il faut examiner les opérations effectuées ensuite, notamment dans Secrets Manager, SSM Parameter Store, Lambda et S3. Si l’attaquant a utilisé un rôle d’intégration, les chercheurs recommandent de renouveler tous les secrets, paramètres et variables d’environnement Lambda que ce rôle pouvait lire, puis de révoquer ses sessions actives. Pour une organisation qui a quitté le service, le rôle d’intégration n’a plus de raison d’exister.

Le rôle d’intégration devait éviter qu’une clé durable reste chez un prestataire. Laissé en place après le départ du client, il a fini par jouer ce rôle de clé oubliée.