Des identifiants IAM volés chez Qubole ouvrent les environnements AWS de clients qui avaient oublié de révoquer la confiance

9 novembre 2026. Les chercheurs de Wiz publient une enquête qui devrait faire frémir toute équipe cloud : un acteur a utilisé des identifiants IAM compromis du compte AWS de Qubole, une plateforme de traitement de données, pour endosser les rôles inter-comptes que des clients avaient accordés au prestataire. Du 14 au 26 octobre 2026, l’attaquant a énuméré des ressources, récolté des secrets dans Secrets Manager, SSM Parameter Store et Lambda, puis siphonné des données S3. Le plus gênant : la plupart des rôles endossés n’étaient plus utilisés, mais leurs politiques de confiance étaient toujours actives.

Ce qui s’est passé : un fournisseur, des rôles croisés, une confiance dormante

Qubole fonctionne sur un modèle devenu banal dans l’écosystème AWS : plutôt que de demander des clés d’accès de longue durée, le client crée dans son propre compte un rôle IAM dont la trust policy autorise le compte du prestataire à l’endosser, généralement conditionné à un External ID. Quand la plateforme doit agir, une identité du compte Qubole appelle sts:AssumeRole et reçoit des identifiants temporaires limités au rôle.

Ce modèle déplace le risque. La sécurité ne dépend plus d’une clé que l’on fait tourner, mais d’une relation de confiance qui, une fois posée, tend à rester en place — même quand le client cesse d’utiliser le service. C’est exactement la faille exploitée ici. Selon Wiz, « de nombreuses organisations ont laissé les politiques de confiance actives même après avoir déprécié la plateforme ». L’attaquant n’a donc pas eu à casser quoi que ce soit : les portes étaient restées ouvertes.

Wiz, alerté par la société Sentra puis appuyé par Mandiant, a remonté l’activité au 14 octobre 2026. Ce jour-là, une adresse IP du VPN Mullvad (45.83.220.211) appelle AssumeRole sur des rôles d’intégration, depuis le compte AWS 805246085872 et avec l’utilisateur IAM AIDA3W7DIFLYOLTK63SFS. Les chercheurs n’ont observé cet utilisateur dans aucune autre activité que celle de l’attaquant. À partir du 15 octobre, le trafic passe majoritairement par un VPS OVH (57.129.54.120) ; le 18 octobre, un second utilisateur IAM du même compte (AIDAJYRRH5Y3A7AAJM2HW) entre en scène. Chaque AssumeRole attribué à l’attaquant contenait un External ID, et tous ont réussi.

Ce que l’attaquant a fait, étape par étape

Une fois à l’intérieur, l’intrus a procédé de façon méthodique et opportuniste. Les noms de session suivaient un préfixe constant, quiam- — quiam-enum, quiam-scope-full — ce qui a d’ailleurs facilité la détection rétrospective.

D’abord l’énumération, large et sans cible précise : ListBuckets, ListObjects, GetDatabases, ListTables, DescribeClusters, DescribeInstances, DescribeSecurityGroups, DescribeVpcs, DescribeDBInstances, ListRoles, ListKeys, GetKeyPolicy. L’attaquant dressait la carte de ce que chaque rôle lui permettait d’atteindre.

Ensuite la récolte de secrets, concentrée sur les trois endroits où AWS stocke des identifiants par défaut : les variables d’environnement des fonctions Lambda (via GetFunctionConfiguration), les secrets de Secrets Manager (ListSecrets puis GetSecretValue) et les paramètres du SSM Parameter Store (DescribeParameters puis GetParameter).

Puis la validation des secrets découverts à l’aide de TruffleHog. L’outil testait les clés AWS trouvées (appel GetCallerIdentity, qui ne demande aucune permission), se connectait en tant que service principals Microsoft Entra ID avec des client secrets volés, et demandait des jetons OAuth auprès d’Okta avec des identifiants clients récupérés au passage. C’est le détail qui transforme une intrusion AWS en compromission identitaire multi-cloud : l’attaquant ne s’arrête pas à la frontière du compte compromis.

Enfin l’exfiltration, séquence identique partout : endosser un rôle, lister les buckets accessibles, énumérer les objets, puis les télécharger. Les chercheurs décrivent un acteur opportuniste qui « lisait ce que chaque rôle pouvait atteindre », allant jusqu’à télécharger des buckets entiers en une session — sans intérêt apparent pour un type de donnée précis.

Le détail qui aggrave tout : une image bootable de destruction de preuves

L’enquête de Wiz révèle aussi un artefact inhabituel. Sur le serveur OVH contrôlé par l’attaquant était hébergée une image ISO nommée sso_agent.iso (SHA-256 65f061281c9a712e9502793dc4c5035cae490b84da05f7d4223cefa65ad396e4). Il s’agit d’une image Linux amorçable conçue pour être démarrée à distance sur une machine victime : elle lance un compte à rebours de 90 minutes, collecte des informations système, remonte les interfaces et les partitions, puis interroge une adresse sur le port TCP 23458 et exécute tout script reçu. Le chargement du pilote ntfs3 suggère une cible Windows. Au bout du délai, un redémarrage brutal efface toute trace. Wiz n’a identifié aucun déploiement de cette image — mais son existence indique un acteur qui prépare la phase suivante.

Un second front, non relié

Les chercheurs ont aussi repéré une campagne distincte, du 8 au 11 octobre 2026, qui utilisait cette fois des clés d’accès AWS appartenant aux clients et créées pour les intégrations Qubole. Le 8 octobre, l’acteur a testé toutes ces clés en une heure ; dans un petit nombre de cas, il est allé jusqu’à compromettre l’environnement cloud. Wiz précise ne pas pouvoir relier ces deux activités avec certitude — ce qui suggère que la compromission du compte Qubole n’est qu’une brique d’un tableau plus large.

Que faire : la chasse et le nettoyage

Wiz fournit un plan de détection concret, transposable à n’importe quel fournisseur. Toute organisation ayant intégré Qubole doit relire CloudTrail depuis le 1ᵉʳ octobre 2026 dans chaque compte porteur d’un rôle d’intégration, en cherchant trois signaux : les événements AssumeRole dont userIdentity.accountId vaut 805246085872 avec une IP source non-AWS (tout trafic légitime observé provenait d’infrastructures AWS) ; ceux dont principalId vaut AIDA3W7DIFLYOLTK63SFS ; et ceux de AIDAJYRRH5Y3A7AAJM2HW filtrés sur la source non-AWS. Un GetCallerIdentity avec un user-agent TruffleHog associé à une IP connue trahit la phase de validation d’identifiants.

Pour chaque session de rôle trouvée, il faut faire tourner chaque secret, paramètre et variable d’environnement que le rôle pouvait lire, et révoquer les sessions actives. La subtilité qui piège tout le monde : faire tourner un identifiant ne met pas fin aux sessions temporaires déjà émises.

Deux mesures préventives ressortent du rapport. La première est d’inventorier les relations de confiance tierces — lister chaque rôle dont la trust policy autorise un compte externe, avec les permissions et les données accessibles. La seconde est d’activer les événements de données S3 (data events) ou les journaux d’accès serveur sur les buckets sensibles : les événements de gestion CloudTrail enregistrent l’endossement du rôle et le listage, pas la lecture des objets qui constitue l’exfiltration elle-même.

Verdict

Cette campagne n’exploite aucune faille logicielle. Elle exploite une dette de configuration : des relations de confiance inter-comptes qu’on pose à l’onboarding et qu’on oublie de révoquer au départ du prestataire. Le compte AWS du fournisseur est devenu un pont d’accès vers des dizaines d’environnements clients, et personne ne surveillait ce pont.

Si vous avez intégré Qubole, appliquez la chasse CloudTrail ci-dessus aujourd’hui, puis faites tourner tous les secrets exposés — c’est non négociable. Si vous consommez un quelconque prestataire SaaS qui opère par rôle croisé, faites l’exercice d’inventaire même sans indice de compromission : pour chaque rôle de confiance externe, demandez-vous s’il est encore nécessaire, ce qu’il peut lire, et qui surveille ses AssumeRole. Si vous fournissez ce type d’intégration, l’External ID ne suffit pas : il faut surveiller les endossements depuis des sources inattendues. La règle à retenir : une relation de confiance cloud est un droit d’accès permanent, pas une configuration ponctuelle — elle doit être inventoriée, surveillée et révoquée comme n’importe quel compte à privilèges.

Références

• Wiz — « Trusted by Default: Qubole Cross-Account Access Abused in the Wild » (9 novembre 2026)
• The Register — « Attackers backdoor trusted AWS integrations to steal secrets » (9 novembre 2026)
• The Hacker News — « Hackers Exploit Qubole’s Trusted AWS Access to Breach Customer Accounts and Steal Data » (9 novembre 2026)