Qubole : des accès cloud oubliés exposent les entreprises au vol de données

Des attaquants ont détourné les accès AWS de Qubole pour voler des secrets et des données chez plusieurs entreprises clientes. Certaines avaient abandonné la plateforme sans révoquer ses autorisations. Rendue publique le 9 novembre 2026, la campagne a été observée du 14 au 26 octobre.

Des attaquants non identifiés ont utilisé des identifiants compromis associés au compte AWS de Qubole pour s’introduire dans les environnements cloud de plusieurs clients. Ils y ont dérobé des secrets et des données sensibles, dont le contenu de compartiments S3. Wiz décrit une vaste campagne opportuniste visant la chaîne d’approvisionnement, sans préciser le nombre d’organisations touchées.

L’opération repose sur le détournement d’une relation de confiance entre comptes AWS. Qubole, plateforme de traitement de données dans le cloud, utilise des rôles de gestion des identités et des accès, ou IAM, pour administrer les ressources de calcul et accéder au stockage de ses clients. Ce fonctionnement évite à ces derniers de transmettre des clés d’accès AWS de longue durée.

Des relations de confiance restées ouvertes

Selon Wiz, de nombreuses organisations avaient maintenu leurs politiques de confiance après avoir cessé d’utiliser la plateforme. Les attaquants ont ainsi pu endosser les rôles d’intégration, inventorier les ressources cloud, collecter des secrets et extraire des données. Des autorisations toujours actives ont donc permis l’accès à des environnements où Qubole n’était plus utilisé.

L’enquête a mobilisé Wiz et les équipes de réponse aux incidents de Mandiant, après le signalement d’activités suspectes par Sentra, entreprise spécialisée dans la sécurité des données. Les premières opérations malveillantes retracées remontent au 14 octobre. Des identifiants associés au compte AWS de Qubole ont alors servi à appeler l’API sts afin d’obtenir des identifiants temporaires correspondant aux rôles d’intégration gérés par les clients.

Les appels provenaient du compte AWS 805246085872 et utilisaient l’identifiant IAM AIDA3W7DIFLYOLTK63SFS. Dans les environnements touchés, Wiz n’a observé cet utilisateur que lors d’activités associées à l’attaquant. Les opérations se sont poursuivies le 15 octobre. Le 18 octobre, les intrus ont commencé à employer un second utilisateur IAM du même compte. L’activité a duré jusqu’au 26 octobre 2026.

Des secrets AWS, Microsoft et Okta recherchés

Une fois dans les environnements clients, les attaquants ont exploré plusieurs services AWS. Ils ont récupéré des identifiants, des clés et d’autres secrets conservés dans Lambda, Secrets Manager et SSM Parameter Store. Les rôles détournés leur ont également permis de voler des données dans S3, avec, dans certains cas, le téléchargement de compartiments entiers.

Les intrus ont aussi utilisé TruffleHog pour tester des identifiants AWS appartenant aux victimes. Ils ont découvert des secrets Microsoft Entra ID et demandé des jetons OAuth au moyen d’identifiants clients Okta trouvés pendant leurs recherches dans les environnements AWS.

Wiz n’attribue la campagne à aucun groupe particulier et ignore l’usage fait des données volées. Les chercheurs ont également repéré une autre campagne, entre le 8 et le 11 octobre, exploitant des clés AWS appartenant aux clients pour des intégrations Qubole. Quelques environnements ont été compromis, mais aucun lien définitif entre les deux opérations n’est établi. 

Examiner les journaux et révoquer les sessions

Les organisations ayant intégré Qubole sont invitées à renouveler leurs identifiants. Cette mesure ne met toutefois pas fin aux sessions temporaires déjà délivrées. Wiz recommande également d’examiner les journaux CloudTrail depuis le 1er octobre, en recherchant les événements AssumeRole dont le champ userIdentity.accountId correspond au compte Qubole, particulièrement lorsqu’ils proviennent d’adresses IP extérieures à AWS.

Chaque session repérée doit faire l’objet d’un examen des opérations effectuées ensuite, notamment dans Secrets Manager, SSM Parameter Store, Lambda et S3. Si un rôle d’intégration a été utilisé par l’attaquant, les chercheurs recommandent de renouveler tous les secrets, paramètres et variables d’environnement Lambda qu’il pouvait lire, puis de révoquer ses sessions actives.