Qubole : rôles AWS de fournisseur abusés, ce que NIS 2 exige

En bref. Entre le 14 et le 26 octobre 2026, un attaquant a utilisé des identifiants d'un compte AWS lié à Qubole, une plateforme de lac de données, pour endosser les rôles que les clients avaient créés pour ce fournisseur. Il a ensuite énuméré leurs ressources, récupéré des secrets et téléchargé des données S3. Wiz, qui a publié l'analyse le 9 novembre avec Sentra et Mandiant, observe que la plupart des rôles visés n'étaient plus utilisés. Pour une entité soumise à NIS 2, l'incident touche directement la sécurité de la chaîne d'approvisionnement (article 21) et, en cas d'incident important, la notification en 24 heures (article 23).

Ce qui s'est passé

Sentra a repéré une activité suspecte dans plusieurs environnements de ses clients, l'a reconnue comme une attaque de la chaîne d'approvisionnement et a partagé l'information avec Wiz. L'équipe de réponse à incident de Wiz (Wiz CIRT) a ensuite reconstitué la campagne.

Le point d'entrée. Le 14 octobre, une adresse IP du service VPN Mullvad appelle AssumeRole sur des rôles d'intégration dans des environnements clients. Les appels viennent du compte AWS 805246085872, que la plateforme Qubole utilise pour accéder aux comptes de ses clients, via un utilisateur IAM que Wiz n'a vu dans aucune autre activité que celle de l'attaquant. À partir du 18 octobre, l'attaquant utilise un second utilisateur IAM du même compte, qui porte aussi du trafic légitime de Qubole. Toutes les demandes attribuées à l'attaquant comportaient l'External ID attendu, et toutes ont réussi. Wiz n'indique pas comment l'attaquant a obtenu ces identifiants.

Des rôles oubliés. Dans la majorité des environnements observés, les demandes de l'attaquant étaient les seules venues du compte du fournisseur en octobre. Les rôles n'étaient plus utilisés, mais leurs politiques de confiance étaient toujours en place.

L'exploitation. Une fois dans un compte, l'attaquant énumère largement : stockage, calcul, bases de données, identités et clés. Il vise les endroits où se trouvent les identifiants : variables d'environnement des fonctions Lambda, AWS Secrets Manager, SSM Parameter Store. Il teste les identifiants trouvés avec l'outil TruffleHog, contre AWS, Entra ID et Okta. Il télécharge des données S3 de façon opportuniste, parfois des compartiments entiers en une session.

Attribution. Wiz signale, dans une mise à jour du 11 novembre, qu'un acteur se faisant appeler « n0n » a revendiqué l'intrusion selon la newsletter Risky Business. Wiz n'a relié la campagne à aucune autre activité publique et juge le ciblage opportuniste.

Une activité distincte. Du 8 au 11 octobre, un acteur a utilisé des clés d'accès AWS appartenant à des clients et probablement créées pour les intégrations Qubole. Wiz n'a pas pu relier cette activité à la première.

Comment fonctionne l'accès d'un fournisseur à votre compte AWS

De nombreux services SaaS qui opèrent dans le compte AWS de leurs clients utilisent un rôle IAM inter-comptes. À l'intégration, le client crée dans son compte un rôle dont la politique de confiance autorise le compte AWS du fournisseur à l'endosser, en général sous condition d'un External ID. Quand le fournisseur doit agir, une identité de son compte appelle sts:AssumeRole avec l'identifiant du rôle et l'External ID, et reçoit des identifiants temporaires limités aux droits du rôle.

Ce modèle a une conséquence que Wiz formule directement : les identités du compte du fournisseur sont, de fait, des identifiants vers tous les environnements clients à la fois. Si elles sont compromises, la seule barrière restante est ce que chaque client a mis dans sa politique de confiance.

Wiz ajoute que l'External ID n'est pas un secret : il apparaît en clair dans CloudTrail, le journal d'activité d'AWS, et il est souvent stocké par le fournisseur et dans le code d'infrastructure.

Qui est concerné

• Les clients de Qubole : Wiz leur demande de revoir CloudTrail depuis le 1er octobre 2026 dans chaque compte qui contient un rôle d'intégration.
• Toute organisation qui a donné à un fournisseur SaaS un rôle dans son compte AWS. Le mécanisme n'a rien de propre à Qubole.
• Les éditeurs SaaS qui endossent des rôles chez leurs clients : leurs propres identités sont la cible.

Détecter : ce que Wiz recommande de chercher

Pour les clients de Qubole, depuis le 1er octobre 2026 :

• les événements AssumeRole dont le compte appelant est 805246085872 et dont l'adresse source n'est pas une adresse AWS (tout le trafic légitime observé venait de l'infrastructure AWS) ;
• les événements liés aux deux utilisateurs IAM et aux adresses IP publiés par Wiz dans ses indicateurs de compromission ;
• les sessions dont le nom commence par quiam- ;
• les appels GetCallerIdentity avec l'agent utilisateur TruffleHog associés à une adresse listée, et le même agent dans les journaux de connexion de votre fournisseur d'identité.

Pour chaque session trouvée, examinez toute l'activité qui suit, surtout Secrets Manager, SSM, Lambda et S3. Si un rôle a été endossé, Wiz recommande de faire tourner tous les secrets, paramètres et variables Lambda que le rôle pouvait lire, et de révoquer les sessions actives du rôle : faire tourner un identifiant ne met pas fin aux sessions temporaires déjà émises.

Un point de vigilance : les événements de gestion de CloudTrail enregistrent l'endossement du rôle et la liste des compartiments, pas la lecture des objets. Sans les événements de données S3 ou les journaux d'accès S3, vous ne saurez pas quels fichiers ont été lus. Wiz note que dans plusieurs environnements touchés, ces journaux manquaient.

Se protéger : les contrôles des rôles de fournisseur

Les recommandations de Wiz, applicables à tout fournisseur :

1. Inventorier les relations de confiance avec des tiers : chaque rôle IAM dont la politique de confiance autorise un compte externe.
2. Supprimer les rôles des intégrations abandonnées, ou retirer le compte du fournisseur de leur politique de confiance. Dans la majorité des environnements observés par Wiz, le rôle visé ne servait plus.
3. Restreindre le principal de confiance : remplacer le compte entier (:root) par l'identité précise du fournisseur, et ajouter une condition aws:SourceIp ou aws:SourceVpce qui limite l'endossement aux plages réseau documentées par le fournisseur. Selon Wiz, une condition sur l'adresse source aurait suffi à bloquer toutes les tentatives observées.
4. **Ne pas compter sur l'External ID comme seul contrôle**, et le renouveler avec le fournisseur après un incident, avec une valeur distincte par rôle quand c'est possible.
5. Limiter les droits des rôles d'intégration : l'accès à la configuration Lambda, à Secrets Manager, à SSM et la lecture large de S3 sont souvent accordés par commodité.
6. Alerter sur un endossement depuis un nouveau réseau : un VPN ou un hébergeur que le fournisseur n'a jamais utilisé est un signal fort.
7. Couvrir tous les comptes par la journalisation, avec un journal d'organisation sur toutes les régions et les événements de données S3 pour les compartiments sensibles.

Pour les éditeurs SaaS, Wiz recommande d'endosser les rôles clients depuis des rôles de charge de travail à identifiants courts plutôt que depuis des utilisateurs IAM à clés longues, de restreindre l'usage de ces identités par réseau, de publier les plages de sortie pour que les clients puissent les épingler, et de surveiller ses propres appels AssumeRole vers les comptes clients.

Ce que NIS 2 exige

La directive (UE) 2022/2555, dite NIS 2, s'applique aux entités essentielles et importantes à travers la loi de transposition de chaque État membre. Deux articles du texte officiel sont directement concernés par ce type d'incident.

Article 21 : la chaîne d'approvisionnement fait partie des mesures minimales. Le paragraphe 2 liste les mesures que les entités doivent au moins mettre en place, dont, au point d), « la sécurité de la chaîne d'approvisionnement, y compris les aspects liés à la sécurité concernant les relations entre chaque entité et ses fournisseurs ou prestataires de services directs ». Le point i) vise les politiques de contrôle d'accès et la gestion des actifs. Le paragraphe 3 demande de tenir compte des vulnérabilités propres à chaque fournisseur direct et de la qualité de ses pratiques de cybersécurité.

Traduit en contrôles : un rôle de fournisseur dans votre compte cloud est un accès de fournisseur. Il entre dans l'inventaire des actifs, dans la revue des accès et dans l'évaluation du fournisseur. Un rôle d'intégration abandonné mais toujours actif peut constituer un écart à ces mesures. Le paragraphe 4 de l'article 21 prévoit qu'une entité qui constate un tel écart prend les mesures correctives sans retard injustifié.

Article 23 : notification d'un incident important. Si l'endossement d'un rôle de fournisseur a mené à un vol de données ou de secrets, il faut qualifier l'incident. Il est important s'il a causé ou peut causer une perturbation opérationnelle grave ou des pertes financières pour l'entité, ou des dommages considérables à d'autres personnes (paragraphe 3). Dans ce cas, le paragraphe 4 impose :

• une alerte précoce dans les 24 heures après en avoir eu connaissance ;
• une notification d'incident dans les 72 heures, avec une évaluation initiale et les indicateurs de compromission disponibles ;
• un rapport final au plus tard un mois après la notification.

Le point de départ est le moment où l'entité a connaissance de l'incident important. L'absence de journaux de données S3 rend cette qualification plus difficile : sans savoir quels objets ont été lus, l'évaluation de l'impact reste incomplète.

FAQ

Je n'utilise plus Qubole, suis-je concerné ?

Oui si le rôle d'intégration existe encore dans votre compte. Wiz observe que la plupart des rôles visés n'étaient plus utilisés et que leurs politiques de confiance acceptaient encore les demandes.

L'External ID ne protégeait-il pas l'accès ?

Non dans ce cas : toutes les demandes de l'attaquant comportaient l'External ID attendu. Wiz rappelle qu'il apparaît en clair dans CloudTrail et ne doit pas être traité comme un secret.

Faut-il notifier au titre de NIS 2 ?

Si votre entité est essentielle ou importante et que l'incident répond aux critères d'incident important de l'article 23, paragraphe 3, oui : alerte précoce dans les 24 heures, notification dans les 72 heures, rapport final dans le mois.

Quel contrôle mettre en place en premier ?

L'inventaire des rôles qui font confiance à un compte externe, et la suppression de ceux qui ne servent plus. Puis la condition d'adresse source sur les rôles restants.

Sources

• Wiz, Trusted by Default: Qubole Cross-Account Access Abused in the Wild, 9 novembre 2026, mis à jour le 11 novembre : https://www.wiz.io/blog/qubole-cross-account-access-abused-in-the-wild
• The Hacker News, Hackers Exploit Qubole's Trusted AWS Access to Breach Customer Accounts and Steal Data, 9 novembre 2026 : https://thehackernews.com/2026/11/hackers-exploit-quboles-trusted-aws.html
• Directive (UE) 2022/2555 (NIS 2), texte officiel en français : https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32022L2555

---

Pour intégrer les accès de vos fournisseurs cloud à vos mesures de l'article 21, WeeSec accompagne les entités concernées sur NIS 2.