Unit 42 expose le detournement silencieux de vos logs cloud

L'unicité mondiale des noms de buckets, angle mort de sécurité du cloud public

Les buckets de stockage des grands hyperscalers partagent une contrainte architecturale commune héritée des premières années du cloud public : leurs noms doivent être uniques à l'échelle mondiale. Dans AWS S3, deux comptes distincts ne peuvent pas détenir simultanément un bucket portant le même nom. Cette règle s'applique identiquement dans Google Cloud Storage et, avec certaines variantes, dans Azure Blob Storage. Cette décision de conception, adoptée il y a près de vingt ans pour simplifier le routage des requêtes et l'accès via URL, ouvre un vecteur d'attaque dont Unit 42, la division de recherche en menaces de Palo Alto Networks, vient de démontrer l'exploitation possible dans un rapport publié début juillet 2026.

La technique, nommée bucket hijacking par collision d'espace de noms, repose sur un encînement d'actions précises. L'attaquant obtient d'abord la permission de supprimer un bucket de stockage cible — par compromission d'un compte cloud, vol d'identifiants, escalade de privilèges ou exploitation d'une politique IAM trop permissive. Immédiatement après la suppression, l'attaquant recrée un bucket portant un nom identique dans son propre compte cloud, profitant du fait que le nom vient d'être libéré dans l'espace de noms global. Tout flux de données préalablement configuré pour écrire vers ce bucket — pipeline de logs, règle de réplication S3, sink Cloud Logging, export Azure Monitor — continue de fonctionner de manière autonome. Ces flux délivrent désormais leurs données directement dans l'environnement de l'attaquant.

Ce qui rend l'attaque particulièrement sournoise est son invisibilité totale côté victime. Le flux d'origine reste configuré dans la console cloud de l'organisation victime et apparaît valide lors d'une inspection manuelle : le nom du bucket de destination est correct, la règle de réplication ou le sink est actif, aucune erreur n'est générée. Aucun événement IAM n'est créé côté victime pour signaler que les données sont désormais écrites dans un bucket appartenant à un autre compte. Aucune alerte cloud-native n'est déclenchée. Les logs, métriques et télémétries sensibles s'écoulent indéfiniment vers l'environnement de l'attaquant sans que la victime reçoive le moindre signal.

Unit 42 a validé la technique sur plusieurs services cloud majeurs. Sur Google Cloud Platform, la confirmation a été obtenue sur les Cloud Logging sinks, les abonnements Pub/Sub avec destination Cloud Storage, et les Storage Transfer Service jobs. Sur AWS, la technique fonctionne sur les règles de réplication de buckets S3 et les pipelines Amazon Data Firehose ciblant des destinations S3. Sur Microsoft Azure, la démonstration a été réalisée via les paramètres de diagnostic Azure Monitor avec une contrainte propre à cette plateforme : le périmètre d'exploitation se limite aux scénarios intra-tenant, car Azure applique des délais de réutilisation de noms dans les configurations cross-tenant. Cette contrainte réduit le risque Azure sans l'éliminer — un attaquant disposant d'un accès légitime au tenant cible peut toujours exploiter la technique.

Les données susceptibles d'être détournées via cette technique couvrent un spectre très large. Les logs d'audit de sécurité — AWS CloudTrail, Google Cloud Audit Logs, Azure Activity Log — constituent les cibles les plus critiques : ils enregistrent l'ensemble des actions effectuées dans l'environnement cloud, y compris les accès à des données sensibles, les modifications de configuration et les tentatives d'intrusion. Des pipelines de réplication S3 peuvent également transporter des backups de bases de données, des archives de données clients ou des exports réglementaires. L'attaquant qui contrôle le bucket de destination dispose non seulement d'une copie continue des données depuis le moment du détournement, mais aussi d'une fenêtre en temps réel sur l'activité opérationnelle de l'organisation victime.

Il est important de souligner qu'aucune exploitation de cette technique dans des attaques réelles n'avait été observée au moment de la publication du rapport Unit 42. La recherche est de nature offensive proactive : elle vise à alerter la communauté de sécurité et les fournisseurs cloud avant que des acteurs malveillants ne découvrent et exploitent le vecteur de manière autonome. Unit 42 a conduit une divulgation coordonnée auprès des équipes de sécurité d'AWS, Google Cloud et Microsoft Azure avant publication. La réponse la plus concrète à ce stade est venue d'AWS, qui avait annoncé en mars 2026 les Account-Regional Namespaces pour S3 — une fonctionnalité qui résout structurellement le problème pour les organisations qui l'activent.

Les recommandations d'Unit 42 combinent contrôles d'accès et surveillance active. La restriction des permissions de suppression de buckets au minimum requis constitue la première ligne de défense : storage.buckets.delete sur GCP, DeleteBucket sur AWS, et Microsoft.Storage/storageAccounts/delete sur Azure doivent être réservées aux rôles administratifs les plus privilégiés avec authentification forte. Le déploiement de politiques de périmètre de données — AWS Service Control Policies (SCPs) ou Google Cloud VPC Service Controls — ajoute une couche de défense indépendante des politiques IAM. Sur AWS spécifiquement, l'activation des Account-Regional Namespaces S3 élimine structurellement le vecteur pour les nouveaux buckets.

Du côté de la détection, Unit 42 recommande des alertes haute priorité sur les appels API de suppression de buckets de stockage, particulièrement sur les buckets hébergeant des logs d'audit ou des données réglementées. La suppression d'un bucket de logs ou d'audit devrait systématiquement déclencher une enquête immédiate, indépendamment des permissions formelles de l'auteur de l'action. Un attaquant disposant légitimement du droit de suppression constitue précisément le scénario que les contrôles IAM seuls ne peuvent pas contenir — seule la surveillance comportementale permet de détecter l'étape clé de l'attaque avant que le détournement ne soit en place.

Une vulnérabilité architecturale qui questionne les fondements du modèle de responsabilité partagée

La recherche d'Unit 42 met en lumière une classe de vulnérabilité qui transcende les failles de code ou les erreurs de configuration individuelles. La contrainte de l'unicité mondiale des noms de buckets est une décision d'architecture fondamentale des hyperscalers, incorporée dans des millions de configurations cloud en production depuis près de vingt ans. Sa remise en question révèle que des décisions d'architecture cloud apparemment anodines, adoptées pour des raisons de simplicité opérationnelle, peuvent générer des risques de sécurité non anticipés à grande échelle — risques qui ne deviennent visibles qu'avec le recul que permettent des années d'adoption massive.

Pour les équipes de sécurité cloud, cette recherche impose une réévaluation du modèle de responsabilité partagée. Les organisations considèrent généralement que leurs flux de logs internes restent dans leur périmètre cloud, protégés par les contrôles IAM déployés. Le bucket hijacking démontre qu'une action aussi ordinaire que la suppression d'un bucket — normalement surveillée mais rarement perçue comme catastrophique en elle-même — peut suffire à compromettre durablement la confidentialité de l'ensemble des données d'audit d'une organisation. Dans des environnements réglementés comme le secteur financier sous DORA, ou la santé sous les réglementations HDS, un tel détournement pourrait constituer une violation réglementaire majeure.

L'impact potentiel sur les programmes de conformité et les capacités de réponse à incident mérite une attention particulière. Les exigences de traçabilité imposées par le RGPD, NIS2, SOC 2 et PCI-DSS présupposent que les logs d'audit arrivent effectivement dans l'environnement du contrôleur et sont intègres. Si ces logs ont été silencieusement redirigés, la chaîne de preuves d'audit est compromise — potentiellement sans que l'organisation le sache pendant une période prolongée. Par ailleurs, un attaquant ayant accès aux logs d'audit dispose d'une visibilité précieuse sur les comportements internes : accès privilégiés, modifications de configuration, alertes de sécurité générées. Ces informations constituent une base de renseignement idéale pour préparer une attaque ultérieure plus ciblée.

Ce qu'il faut retenir

• Activer immédiatement les Account-Regional Namespaces AWS S3 pour chaque compte de production — cette fonctionnalité élimine structurellement le vecteur de bucket hijacking sur S3 pour les nouveaux buckets.
• Créer des alertes SIEM de priorité critique sur tous les appels API de suppression de buckets cloud (AWS CloudTrail, GCP Cloud Audit Logs, Azure Activity Log), particulièrement sur les buckets contenant des logs d'audit ou des données réglementées.
• Restreindre les permissions de suppression de buckets via des politiques organisationnelles (SCPs AWS, Org Policies GCP) plutôt que de s'appuyer uniquement sur les contrôles IAM au niveau des ressources individuelles.