Unit 42 : hijacking silencieux des buckets cloud AWS et GCP

Un bucket supprimé devient une porte dérobée permanente vers vos données cloud

Des chercheurs de Unit 42, le département de threat intelligence de Palo Alto Networks, ont publié les détails complets d'une technique d'attaque cloud qu'ils nomment bucket namespace hijacking. La technique exploite une propriété fondamentale de l'architecture de stockage des trois principaux hyperscalers — Amazon Web Services, Google Cloud Platform et Microsoft Azure — pour détourner silencieusement des flux de données entiers vers un compte contrôlé par l'attaquant, sans qu'aucun événement IAM anormal soit généré et sans qu'aucune alerte soit déclenchée du côté de la victime.

Le principe de l'attaque repose sur une caractéristique inhérente à la conception des services de stockage objet cloud : les noms de buckets sont globalement uniques à l'intérieur d'un même service. Dans AWS S3, dans Google Cloud Storage et dans Azure Blob Storage, deux comptes ne peuvent pas détenir simultanément un bucket portant le même nom. Cette unicité globale, initialement conçue pour simplifier l'adressage des objets via des URLs canoniques et éviter les conflits de nommage, crée une surface d'attaque insoupçonnée lorsqu'un bucket existant est supprimé.

Le déroulé de l'attaque suit une séquence précise. Dans un premier temps, l'attaquant doit compromettre un compte cloud cible et obtenir les droits suffisants pour supprimer un bucket de stockage — des permissions relativement communes dans les environnements cloud mal configurés où les comptes de service applicatifs se voient souvent accorder des droits larges par souci de simplicité opérationnelle. Une fois le bucket d'origine supprimé, son nom redevient immédiatement disponible à l'enregistrement pour n'importe quel compte dans le monde. L'attaquant crée aussitôt un bucket portant exactement le même nom, mais sous son propre compte cloud externe. À partir de ce moment, tous les flux de données qui pointaient vers le bucket d'origine — logs Cloud Logging, abonnements Pub/Sub, tâches Storage Transfer Service, réplications S3, pipelines Data Firehose — continuent à fonctionner normalement et livrent leurs données directement dans le compte de l'attaquant.

L'aspect le plus inquiétant de cette technique est son caractère intrinsèquement silencieux. Parce que les configurations de flux de données restent intactes et continuent à router leurs données vers le nom de bucket configuré, aucune anomalie n'est détectée du côté victime. Les tableaux de bord de monitoring cloud affichent des métriques normales. Les vérifications de santé réussissent. Les logs de sécurité ne montrent aucun accès non autorisé côté victime — puisque techniquement, la livraison des données se produit dans le compte de l'attaquant qui les reçoit passivement. La livraison de logs d'audit, d'événements de sécurité et de données applicatives vers un compte externe peut se poursuivre pendant des semaines ou des mois sans être détectée par les outils de monitoring traditionnels.

Unit 42 a validé cette technique sur les trois principaux cloud providers. Sur Google Cloud Platform, les chercheurs ont simulé le hijacking en ciblant des Cloud Logging sinks, des abonnements Pub/Sub et des tâches Storage Transfer Service. Les permissions requises pour l'attaque initiale se limitaient à storage.buckets.delete et storage.objects.delete — des droits fréquemment accordés à des comptes de service applicatifs dans des environnements cloud mal structurés selon le principe du moindre privilège. Sur AWS, la technique a été répliquée en ciblant des configurations Amazon Data Firehose et des règles de réplication de bucket S3. Sur Azure Blob Storage, une variante adaptée exploitant les mécanismes de redirection de données liés aux Storage Accounts a également été démontrée avec succès par les chercheurs.

Les catégories de données potentiellement exposées par cette technique sont particulièrement sensibles : journaux d'audit de sécurité (Cloud Audit Logs, AWS CloudTrail), événements de sécurité destinés aux SIEM, sauvegardes de bases de données, artifacts de build CI/CD, données applicatives de production, et tokens ou secrets transitant dans des pipelines de données. Dans un scénario d'intrusion sophistiqué, un attaquant qui parviendrait à rediriger les logs de sécurité vers son propre bucket obtiendrait non seulement des données sensibles mais aussi une visibilité complète sur les activités de détection et de réponse de l'équipe de sécurité de la victime — une forme de contre-intelligence opérationnelle qui rendrait la détection et la neutralisation de l'intrusion considérablement plus difficiles.

La réaction des cloud providers a été inégale face à cette divulgation. AWS a déployé en mars 2026 un mécanisme de account regional namespace pour les buckets S3 de type general purpose, qui rend structurellement impossible la réenregistration d'un nom de bucket supprimé par un autre compte dans la même région. Cette protection s'applique aux buckets créés après le déploiement de la fonctionnalité, mais ne couvre pas rétroactivement les buckets existants et leurs configurations de réplication déjà en place. Google Cloud et Azure n'avaient pas, au moment de la publication des recherches de Unit 42, déployé de mécanisme équivalent, bien que des discussions soient en cours selon les informations relayées par des sources proches des équipes de sécurité de ces plateformes.

Unit 42 a précisé dans ses conclusions qu'aucun acteur malveillant réel n'a été formellement identifié comme utilisant cette technique dans le cadre d'attaques opérationnelles connues. La publication du rapport constitue une divulgation responsable après notification préalable des trois cloud providers concernés. Néanmoins, la technique est suffisamment documentée et accessible pour que des groupes APT disposant de ressources techniques significatives puissent l'adapter et la déployer dans des campagnes ciblées contre des organisations dont les environnements cloud présentent les conditions propices à ce type d'attaque.

Un risque architectural systémique pour les stratégies multicloud

La technique de bucket namespace hijacking révèle une catégorie de risques cloud plus profonde que les vulnérabilités techniques classiques : les risques architecturaux systémiques. Contrairement à un CVE qui peut être corrigé via un patch applicatif, cette attaque exploite un comportement qui est, par conception, une fonctionnalité documentée et délibérée des plateformes cloud. L'unicité globale des noms de buckets a été choisie explicitement pour simplifier l'adressage et éviter les conflits de nommage lors de l'accès aux objets. Ce choix de design, parfaitement raisonnable dans un contexte de stockage simple, crée des effets de bord imprévus dans les architectures de données complexes modernes où les flux sont configurés de manière statique et peuvent survivre à la suppression de leurs destinations d'origine.

Pour les architectes cloud et les RSSI, cette recherche met en lumière plusieurs lacunes communes dans les pratiques de gouvernance cloud. Premièrement, la gestion du cycle de vie des ressources cloud — et notamment la procédure de suppression des buckets — est rarement traitée comme un événement de sécurité à part entière. Les workflows de décommissionnement ne prévoient pas systématiquement la revue et la mise à jour de toutes les configurations de flux de données pointant vers la ressource supprimée. Deuxièmement, le monitoring des configurations de flux de données (logging sinks, réplication, abonnements Pub/Sub) est souvent absent ou insuffisant : les équipes surveillent les accès aux données mais pas la validité des destinations vers lesquelles ces données sont routées en continu.

Dans le contexte des exigences réglementaires croissantes — NIS2, DORA, RGPD — la question de la traçabilité et de l'intégrité des flux de logs de sécurité prend une dimension critique. Sous DORA, les entités financières sont tenues de garantir la disponibilité et l'intégrité de leurs logs de monitoring pour des durées de conservation étendues. Un détournement silencieux de logs via un bucket hijacking pourrait constituer une violation de ces exigences sans que l'entité concernée en soit informée pendant une période prolongée, créant un risque de non-conformité rétroactive difficile à corriger après coup. La Cloud Security Alliance a publié une analyse du risque de namespace hijacking qui classe ce scénario comme un risque systémique nécessitant une approche défense en profondeur plutôt qu'une correction ponctuelle.

La montée en puissance des architectures multicloud complexifie encore ce tableau. Dans un environnement où une organisation utilise simultanément AWS pour son infrastructure principale, GCP pour ses pipelines de données et Azure pour ses environnements M365 et identité, les flux de données traversent plusieurs namespaces de buckets différents. La surface d'attaque potentielle se multiplie, et la visibilité centralisée sur l'intégrité de ces flux devient un prérequis de sécurité non négociable que peu d'organisations ont aujourd'hui formellement implémenté dans leurs programmes de sécurité cloud.

Ce qu'il faut retenir

• Le bucket namespace hijacking exploite un comportement architectural fondamental des cloud providers, non patchable directement : la défense passe par le durcissement des droits de suppression et le monitoring proactif des configurations de flux.
• Les logs de sécurité, les données de backup et les pipelines CI/CD sont les cibles les plus critiques — leur détournement silencieux peut durer des semaines sans être détecté par les outils de monitoring traditionnels.
• AWS a partiellement adressé le problème pour les nouveaux buckets S3 avec les account regional namespaces (mars 2026) ; les environnements GCP et Azure, ainsi que toutes les configurations existantes sur AWS, nécessitent une revue manuelle des destinations de flux.