Les cyberattaques visant le stockage Cloud
Protégez-vous des menaces pesant sur le stockage Cloud
Pourquoi lire cet article ? Les hackers ne s’attaquent plus à vos serveurs, ils ciblent vos Buckets : découvrez comment les ransomwares modernes et les attaques par rebond retournent vos propres configurations Cloud contre vous, et comment vous en protéger.
Historiquement, les cyberattaques se concentraient sur la compromission des réseaux d’entreprise, des postes de travail et de l’Active Directory. Toutefois, avec l’accélération de la migration vers le Cloud, les espaces de stockage S3 (Simple Storage Service) sont devenus le nouveau coffre-fort à braquer. En 2025 et 2026, la surface d’attaque a muté : les attaquants ne cherchent plus forcément à pirater des serveurs, mais ciblent directement les identifiants Cloud et les mauvaises configurations de Buckets. Retour détaillé sur deux typologies d’attaques qui ont récemment secoué l’industrie : le ransomware « Codefinger » mis en lumière par Halcyon, et les supply-chain attacks via les « Buckets abandonnés » (ou Bucketsquatting) révélées par watchTowr Labs.
Codefinger : Quand AWS chiffre vos données pour le compte des hackers
En janvier 2025, les chercheurs en sécurité d’Halcyon ont documenté une nouvelle campagne de ransomware terrifiante nommée Codefinger. Sa particularité ? Elle n’exploite aucune vulnérabilité technique (Zero-Day) chez Amazon Web Services, mais retourne les propres mécanismes de sécurité d’AWS contre ses clients.
Le mécanisme de l’attaque SSE-C Tout débute par la compromission de clés d’API AWS, souvent dérobées via des fuites sur GitHub, des campagnes de phishing, ou achetées sur des marchés parallèles. Une fois dotés d’autorisations s3:GetObject et s3:PutObject, les assaillants appliquent une technique redoutable.
Au lieu de télécharger les fichiers, de les chiffrer en local, puis de les réuploader (ce qui génère énormément de trafic et déclenche les alarmes), les attaquants utilisent l’API légitime d’AWS pour exécuter l’action via le chiffrement côté serveur avec des clés fournies par le client (SSE-C pour Server-Side Encryption with Customer-Provided Keys). Le groupe Codefinger génère sa propre clé AES-256 et demande à l’infrastructure S3 d’AWS de chiffrer les Objets de la victime en utilisant cette clé de chiffrement malveillante.
Dès cet instant, AWS lui-même « oublie » la clé et exige cette dernière pour toute lecture future. Sans payer la rançon aux hackers, les données sont mathématiquement irrécupérables.
L’urgence artificielle de l’API Lifecycle Pour mettre encore plus la pression sur la victime, les assaillants exploitent une autre fonctionnalité légitime : le S3 Object Lifecycle Management. Ils injectent une règle de cycle de vie qui ordonne à AWS de supprimer définitivement tous les fichiers altérés sous 7 jours. La victime fait alors face à une montre tournant inexorablement, orchestrée directement par le Cloud Provider.
Les Buckets Abandonnés (Bucketsquatting) : Menace fantôme sur la Supply Chain
La seconde grande menace ne s’attaque pas à vos données présentes, mais à la trace que vous laissez derrière vous. Documentée en détail par watchTowr Labs et abordée plus récemment sous d’autres formes de Cloud public (comme Azure par Eye Security), l’attaque des Buckets abandonnés illustre la dangérosité de la dette technique Cloud.
Qu’est-ce que le Bucketsquatting ? Imaginons qu’une entreprise configure un Bucket S3 nommé images-corp-app et associe un nom de domaine personnalisé (assets.mon-entreprise.com) via un enregistrement DNS CNAME pointant vers le domaine S3 d’Amazon. Quelques mois plus tard, le projet s’arrête.
L’administrateur Cloud détruit le Bucket S3 pour faire des économies FinOps, mais oublie de supprimer l’enregistrement DNS CNAME. Le nom images-corp-app redevient alors disponible globalement pour n’importe quel compte AWS dans le monde. Un attaquant scrute internet, détecte cette faille, et crée un Bucket S3 portant exactement ce nom sur son propre compte AWS malveillant.
Un vecteur massif de compromission La conséquence est désastreuse. L’attaquant contrôle désormais ce qui s’affiche sur assets.mon-entreprise.com. Si ce domaine était utilisé pour héberger une bibliothèque JavaScript tierce (script.js) appelée par des milliers de sites clients, l’attaquant peut y injecter un code malveillant (Magecart, vol de cartes bancaires, minage de cryptomonnaies).
C’est une attaque par rebond (Supply Chain Attack) d’une furtivité redoutable, car le trafic provient d’un sous-domaine de confiance.
Comment se protéger face à l’ingéniosité des attaquants ?
Ces deux exemples montrent que les outils traditionnels (antivirus, pare-feu) sont totalement aveugles face aux menaces « Cloud Native » qui se contentent d’utiliser les API S3 de manière détournée. Pour se prémunir, la mise en place d’une gouvernance stricte (DSPM) et d’un suivi d’intégrité (FIM) est obligatoire.
Voici les réflexes critiques :
• Activer le Versioning et l’Object Lock : Pour contrer des attaques comme Codefinger, l’Object Lock en mode Compliance empêche même un attaquant disposant de clés administrateurs d’altérer ou de chiffrer vos anciennes versions de fichiers pendant une durée déterminée.
• Surveillance comportementale en temps réel : Surveiller les appels API massifs (mass deletion, modifications frénétiques de metadata).
• Audit d’infrastructure et nettoyage DNS : Cartographier continuellement les dépendances entre les zones DNS (Route53 ou autres) et l’existence réelle des ressources de stockage sous-jacentes.
Conclusion
La surface d’attaque du Cloud nécessite un changement de paradigme complet. Les équipes de cybersécurité doivent impérativement intégrer des processus de remédiation automatisés et utiliser des outils de monitoring dédiés aux stockages S3.
Ne sous-estimez jamais le danger d’une clé API en fuite ou d’un domaine DNS orphelin : dans le Cloud public, vos erreurs de configuration sont les vecteurs d’attaque de demain.