Qubole : un rôle AWS inutilisé a suffi aux voleurs

Ce qui se passe

Wiz, avec Sentra et Mandiant, décrit une intrusion dans plusieurs comptes AWS de clients de Qubole, une plateforme de data lake qui travaille à l'intérieur du compte de ses clients. Du 14 au 26 octobre 2026, un attaquant s'est servi d'identifiants IAM d'un compte AWS associé à Qubole pour endosser les rôles que les clients lui avaient ouverts, puis a énuméré les ressources, collecté configurations et secrets, lu des données S3 et testé les identifiants trouvés en chemin. Sentra a vu l'activité chez plusieurs de ses clients et a alerté Wiz. La manière dont l'attaquant a obtenu ces identifiants n'est pas connue, et ni Qubole ni sa maison mère Idera n'avaient publié de communiqué à la date de l'article.

Pourquoi ça passe

Pour intervenir chez un client, Qubole appelle sts:AssumeRole. Le client a créé au préalable un rôle dont la politique de confiance autorise le compte de Qubole à l'endosser, à condition de fournir un External ID.

L'External ID n'est pas un secret : n'importe qui ayant accès au rôle le voit, il apparaît en clair dans CloudTrail, et les éditeurs comme les fichiers d'infrastructure-as-code le conservent. Chaque requête de l'attaquant en portait un, et toutes ont réussi. Dans la majorité des environnements observés, ses requêtes étaient même la seule activité AssumeRole du compte Qubole en octobre : les rôles n'étaient plus utilisés, mais la confiance, elle, n'avait jamais été retirée.

Ce que l'attaquant a fait

• Secrets : variables d'environnement des fonctions Lambda (GetFunctionConfiguration), Secrets Manager (ListSecrets puis GetSecretValue), SSM Parameter Store (DescribeParameters puis GetParameter).
• Validation : TruffleHog sur les identifiants trouvés — clés AWS (GetCallerIdentity), secrets de clients Entra ID, identifiants OAuth Okta. Elles appartenaient aux victimes, pas à Qubole.
• Données : ListBuckets, ListObjects, HeadObject, puis GetObject, sans cible précise : tout ce que le rôle atteint, parfois un bucket entier en une session. Les événements de gestion de CloudTrail n'enregistrent pas ces lectures d'objets ; plusieurs victimes n'avaient pas les journaux voulus et ne peuvent pas dire ce qui a été lu.
• À part : du 8 au 11 octobre, un acteur a utilisé des clés d'accès AWS créées pour Qubole, sans lien établi avec le reste, et a compromis quelques environnements. Wiz a aussi trouvé sur l'une des adresses de l'attaquant une image sso_agent.iso (SHA-256 65f061281c9a712e9502793dc4c5035cae490b84da05f7d4223cefa65ad396e4), sans pouvoir confirmer qu'elle ait servi.

Comment s'y prendre

Dans CloudTrail, dans chaque compte qui porte un rôle Qubole, à partir du 1er octobre 2026 :

• AssumeRole avec userIdentity.accountId = 805246085872 et sourceIPAddress hors d'AWS ; le trafic légitime observé venait uniquement d'AWS.
• userIdentity.principalId = AIDA3W7DIFLYOLTK63SFS : dans les environnements examinés, seul l'attaquant l'a utilisé.
• principalId = AIDAJYRRH5Y3A7AAJM2HW avec une adresse source hors d'AWS (cet utilisateur porte aussi du trafic normal, d'où le filtre).
• Noms de session commençant par quiam-, comme quiam-enum ou quiam-scope-full.
• GetCallerIdentity avec l'agent utilisateur TruffleHog, et le même agent dans les journaux de connexion de votre fournisseur d'identité.
• Adresses : 57.129.54.120 et 2001:41d0:70d:7800:: (OVH), 45.83.220.211, 185.209.199.73 et 89.37.63.175 (sorties Mullvad, partagées : une correspondance seule ne prouve rien).

Puis, selon le résultat :

1. Si un de vos rôles Qubole a été endossé : changez tous les secrets, paramètres et variables Lambda qu'il pouvait lire, et révoquez ses sessions actives — changer un identifiant n'arrête pas une session déjà émise.
2. Supprimez les rôles que vous n'utilisez plus, ou retirez le compte de Qubole de leur politique de confiance.
3. Si l'éditeur le permet, remplacez le principal :root du compte par le principal IAM précis qu'il utilise, et ajoutez une condition aws:SourceIp ou aws:SourceVpce. Selon Wiz, la seule condition d'adresse source aurait bloqué toutes les prises de rôle observées.
4. Activez les événements de données S3 ou les journaux d'accès pour les buckets sensibles, avec un trail d'organisation sur tous les comptes et régions, et alertez sur tout AssumeRole d'un compte éditeur venu d'un VPN ou d'un hébergeur inhabituel.

Le guide de configuration de Qubole propose une politique S3 d'exemple qui permet de lire tous les buckets du compte : relisez ce que chaque rôle d'éditeur peut atteindre.

Source : Wiz, en anglais, avec l'analyse de Sentra et le compte rendu de The Hacker News.