Qubole : des rôles AWS de clients assumés du 14 au 26 octobre 2026

Le 9 novembre 2026, Wiz a décrit une intrusion dans plusieurs environnements Amazon Web Services (AWS) de clients de Qubole, plateforme de data lake du groupe Idera : du 14 au 26 octobre 2026, un attaquant a utilisé des identifiants du compte AWS 805246085872, celui que la plateforme emploie pour agir chez ses clients, et a assumé des rôles que ces clients avaient créés pour lui.

Le billet est signé Zack Morrow, Sean Johnstone et Benjamin Read. Wiz dit avoir travaillé avec Sentra et Mandiant. Sentra a repéré l’activité chez plusieurs de ses clients, l’a lue comme une attaque via un fournisseur, et a transmis le dossier. Wiz ne donne pas le nombre d’organisations touchées. Le texte dit « plusieurs » environnements, et « la majorité » de ceux observés.

Des rôles encore de confiance, souvent inutilisés

Pour laisser Qubole travailler dans son compte, le client crée un rôle dont la politique de confiance autorise le compte du fournisseur à l’assumer, en général contre un identifiant externe convenu. Assumer le rôle donne des identifiants temporaires, limités à ce que le client a permis.

Wiz écrit que chaque requête AssumeRole qu’elle attribue à l’attaquant portait cet identifiant externe, et que chacune a été acceptée. Dans la majorité des environnements observés, ces requêtes étaient la seule activité AssumeRole venue du compte du fournisseur pendant le mois d’octobre. Les rôles n’étaient plus utilisés au quotidien. La relation de confiance, elle, était toujours en place.

La première activité vue par Wiz date du 14 octobre, depuis le VPN Mullvad. À partir du 15 octobre, l’essentiel vient d’un serveur OVH. Le 18 octobre, un second utilisateur IAM du même compte apparaît : il sert aussi au trafic légitime, quand la source est AWS. Wiz sépare les deux par l’adresse. Le trafic légitime observé venait d’AWS. Celui de l’attaquant, non.

Secrets lus, données copiées, sans cible précise

Une fois dans le compte, l’attaquant a lu des endroits où les identifiants sont souvent rangés : variables d’environnement Lambda, Secrets Manager et Parameter Store. Il a testé des clés AWS, des secrets Microsoft Entra ID et des identifiants Okta trouvés là. Wiz nomme TruffleHog pour ces vérifications. Ces identifiants appartenaient aux organisations visées, pas au fournisseur.

Il a aussi copié des données dans S3. Wiz le décrit comme opportuniste : il lisait ce que le rôle pouvait atteindre, et a dans certains cas téléchargé un compartiment entier au cours d’une même session. Les événements de gestion CloudTrail enregistrent l’assumption du rôle et le listage des compartiments, pas la lecture de chaque objet. Sans événements de données S3, ou sans journaux d’accès du service, plusieurs victimes n’ont pas pu savoir quels fichiers étaient partis.

Wiz ne relie pas cette campagne à une autre affaire publique. Le ciblage et le vol de données lui paraissent opportunistes, et ne correspondent pas, écrit-elle, aux priorités habituelles d’un groupe étatique. Elle dit ne pas savoir comment les données seront utilisées, ni comment l’attaquant a obtenu les identifiants du compte Qubole.

Un second fil, que Wiz ne relie pas au premier, va du 8 au 11 octobre : des clés d’accès AWS appartenant aux clients, que Wiz croit créées pour Qubole, ont été testées le 8 octobre en une heure. Dans un petit nombre de cas, l’acteur est allé plus loin.

Ce que les clients peuvent chercher

Si ce rôle a été assumé, Wiz recommande de faire tourner tous les secrets, paramètres et variables d’environnement Lambda que le rôle pouvait lire, et de révoquer les sessions actives du rôle. Changer un secret ne coupe pas une session temporaire déjà délivrée. Les rôles dont on n’a plus l’usage peuvent être supprimés, ou le compte du fournisseur retiré de leur politique de confiance.

L’identifiant externe n’est pas un secret : il est journalisé en clair dans CloudTrail, et souvent recopié par le fournisseur ou dans le code d’infrastructure. Wiz écrit, à propos d’une condition sur l’adresse source :

a source IP condition alone would have blocked every role assumption we observed.

Le 9 novembre au soir, la page d’accueil de qubole.com et la liste de son blog ne mentionnent pas l’incident. Le logo du site porte la mention d’une société du groupe Idera. Ni le billet de Wiz ni cette lecture du site ne remplacent un avis du fournisseur, qui n’était pas en ligne à ce moment-là.

KLYNLABS a déjà décrit des secrets AWS sortis via un outil de fournisseur, dans JetBrains Cadence, et des données d’autres clients exposées chez Cloudflare Containers. Ici, ce n’est pas une faille du logiciel du client : c’est la confiance déjà accordée au compte du fournisseur.

Sources

Wiz, Trusted by Default: Qubole Cross-Account Access Abused in the Wild, Zack Morrow, Sean Johnstone et Benjamin Read, 9 novembre 2026.

The Hacker News, 9 novembre 2026, 17 h 51 UTC. Page d’accueil et blog de Qubole consultés le 9 novembre au soir : pas d’avis sur cette intrusion.