AWS : comment un bucket S3 ouvert a cree un admin en 8 minutes
Un attaquant a pris le controle d un compte AWS en 8 minutes via un bucket S3 ouvert et une fonction Lambda avec droits admin. L IA a accelere l attaque.
6 min de lecture
Le 28 novembre 2025, un attaquant a pris le contrôle d’un compte AWS complet en huit minutes. Depuis la première clé d’accès volée jusqu’aux droits d’administrateur complets. L’équipe de sécurité de Sysdig a documenté ce cas. Ce qui est frappant, c’est la rapidité : une IA a effectué l’analyse et la création de scripts en temps réel. La faille ayant permis l’intrusion était une erreur de configuration connue.
L’essentiel en bref
- Huit minutes pour devenir administrateur : Selon Sysdig, un attaquant a compromis un compte AWS en moins de dix minutes. En partant de clés volées dans un bucket S3 ouvert jusqu’à la création d’un utilisateur administrateur.
- L’erreur venait de la configuration : Une fonction Lambda disposait d’un rôle d’exécution doté de droits administrateur. Quiconque pouvait modifier cette fonction héritait automatiquement de ces droits. Aucun nouvel exploit n’était nécessaire.
- L’IA a servi de turbo : Elle a généré du code malveillant et exploré le compte en temps réel. Pourtant, selon Mandiant, le délai médian pour ce type d’attaques s’élève à 14 jours. Le cas des huit minutes reste une exception, rendu possible par des conditions particulières.
En lien avec :Comment une faille dans Argo CD permet de prendre le contrôle d’un cluster Kubernetes / AWS et Azure sous surveillance de l’UE : la dépendance aux géants du cloud vacille
Huit minutes pour passer d’un bucket S3 à une clé d’administration
L’entrée était grande ouverte sur le réseau. Dans un bucket S3 accessible publiquement se trouvaient des données d’entraînement pour un système d’IA, incluant notamment des clés d’accès valides d’un utilisateur IAM. Cet utilisateur disposait de peu de droits, mais une seule autorisation suffisait : il pouvait modifier le code d’une fonction Lambda spécifique. Cette fonction s’appelait EC2-init. Elle était associée à un rôle d’exécution doté de droits d’administration.
À partir de là, tout s’est enchaîné rapidement. L’attaquant a réécrit la fonction pour qu’elle génère de nouvelles clés d’accès pour un utilisateur administrateur nommé frick, puis a lu directement le résultat dans la réponse de la fonction. Aucun détour par un serveur externe, aucune coquille réseau (reverse shell). Il a ensuite accédé à 19 identités AWS différentes, créé un second administrateur avec une porte dérobée et sécurisé ainsi son accès à plusieurs reprises.
Puis les coûts ont explosé. Via le service d’IA Amazon Bedrock, l’attaquant a exploité des modèles de langage tiers aux frais de la victime. En parallèle, il a lancé une instance GPU facturée environ 30 euros de l’heure pour exécuter ses propres modèles. AWS a interrompu l’instance après cinq minutes en raison de limites de capacité. Le code lui-même était révélateur : des commentaires en serbe et des numéros de comptes AWS inventés trahissaient la participation d’un modèle de langage dans sa rédaction.
Aucun zero-day, mais une chaîne d’erreurs connues
Le chiffre de huit minutes semble remettre en cause tout ce que l’on sait de la sécurité cloud. L’analyse de la trajectoire de l’attaque montre l’inverse. Aucune faille inconnue, aucun exploit spécifique à l’IA. Chaque étape a exploité une mauvaise configuration documentée.
Des clés d’accès persistantes étaient stockées dans un compartiment public. Un rôle d’exécution Lambda disposait de droits administrateur alors qu’il n’en avait nul besoin. Un utilisateur faiblement autorisé pouvait écraser le code de fonctions tierces. Ces trois erreurs, combinées, ont formé la chaîne. Chacune d’elles est connue depuis des années et mentionnée dans chaque guide de durcissement AWS.
L’IA a accéléré et automatisé l’attaque. Elle ne l’a pas rendue possible. Ceux qui interprètent ce cas comme une preuve que l’IA rend le cloud moins sûr passent à côté de la cause réelle. Et donc du point où la défense peut agir. La cause est réparable, sans même avoir à recourir à des mesures anti-IA.
Pourquoi le nombre de minutes induit en erreur
Un second indicateur remet les choses en perspective. L’unité de sécurité Mandiant de Google analyse chaque année des centaines de milliers d’heures de réponse aux incidents. Le rapport M-Trends 2026, publié le 23 mars, contient une phrase qui contredit la panique ambiante : on ne peut pas considérer 2025 comme l’année où les attaques ont été directement générées par l’IA.
Les chiffres confirment cette analyse. En 2025, la durée médiane de présence d’un attaquant dans le réseau est passée à 14 jours, contre 11 jours l’année précédente. Dans 52 % des cas, les entreprises ont détecté elles-mêmes l’intrusion. L’exploitation de vulnérabilités reste, pour la sixième année consécutive, le vecteur d’attaque le plus fréquent, avec 32 % des cas. La majorité des attaques s’inscrivent toujours dans une échelle de temps allant de quelques jours à plusieurs semaines.
L’incident des huit minutes est bien réel, mais il s’agit d’une exception, et non d’une nouvelle norme. Sa rapidité s’explique par des conditions idéales. Pour les défenseurs, c’est une bonne nouvelle : en éliminant ces conditions favorables, on prive l’attaque rapide de son fondement.
Cinq étapes pour renforcer la sécurité des comptes AWS dès maintenant
Aucun correctif éditeur ne résoudra ce problème, car la source du risque réside dans la configuration. C’est précisément là qu’il faut agir. Les étapes sont classées par ordre d’impact.
- Éliminer les clés permanentes. Plutôt que des clés IAM durables, privilégiez les rôles temporaires et les identifiants éphémères en production. Une clé divulguée, inutilisable après une heure, ne représente plus une menace.
- Séparer les rôles d’exécution des droits d’administration. Aucune fonction Lambda n’a besoin de droits administrateur pour accomplir sa tâche. Chaque rôle d’exécution se voit attribuer uniquement les permissions strictement nécessaires à sa fonction.
- Identifier les compartiments publics. Les compartiments S3 contenant des données d’entraînement sont souvent exposés par erreur. Un scan régulier des compartiments ouverts et des identifiants qui y sont stockés permet de bloquer l’une des principales portes d’entrée des attaques.
- Sécuriser Bedrock avec des garde-fous. Les Service Control Policies (SCP) limitent les utilisateurs autorisés à lancer des services IA coûteux ou des instances GPU. Cela réduit l’impact financier si un compte est compromis.
- Surveiller l’activité en temps réel. La création de nouveaux utilisateurs administrateurs, l’utilisation inattendue de Bedrock ou le lancement soudain d’instances GPU sont des signaux d’alerte. Les détecter en temps réel permet d’interrompre une attaque en cours.
Mauvaise configuration vs. configuration renforcée
La différence entre un compte compromis en huit minutes et un environnement sécurisé ne réside pas dans un nouvel outil. Elle tient aux paramètres par défaut qu’il faut connaître et configurer.
| Aspect | Cas vulnérable | Configuration renforcée |
|---|---|---|
| Clés d’accès | longue durée, dans un bucket public | rôles éphémères |
| Rôle d’exécution Lambda | droits d’administrateur | seulement droits fonctionnels |
| Buckets S3 | publics avec identifiants d’accès | privés, scannés régulièrement |
| Impact d’une clé divulguée | accès à l’administration du compte | inutilisable après une heure |
Ce que les équipes doivent retenir de ce cas
L’agitation autour des huit minutes détourne l’attention du diagnostic réel. L’attaque a été rapide parce que les bases de l’hygiène informatique faisaient défaut. Des identifiants temporaires, des rôles attribués avec parcimonie et un regard sur les compartiments de stockage ouverts auraient pu briser la chaîne à chaque étape. Ces mesures sont anciennes, peu spectaculaires et efficaces.
Un détail devrait en outre alerter les défenseurs. Sysdig met en garde : les traces d’IA trahisseuses dans le code pourraient bientôt disparaître. Les agents plus performants n’écrivent plus de commentaires en serbe ni n’inventent de numéros de compte. La fenêtre permettant de détecter une attaque assistée par IA dans le code se referme. Reste le durcissement des systèmes, qui freine déjà chacune de ces étapes aujourd’hui.
Questions fréquentes
Qu’est-ce que le LLMjacking ?
Le LLMjacking consiste, pour des attaquants, à s’emparer de comptes cloud volés afin d’exécuter des modèles de langage coûteux via des services comme Amazon Bedrock. C’est la victime qui paie la facture. Dans l’affaire Sysdig, l’attaquant a détourné des modèles étrangers et lancé en plus une instance GPU à ses frais.
L’affaire des huit minutes provient-elle de Google ou de GTIG ?
Non. L’affaire précise des huit minutes provient de l’équipe de sécurité de Sysdig. Le rapport Mandiant de Google, M-Trends 2026, fournit une analyse complémentaire et évoque une durée médiane de détection de 14 jours. L’association des deux sources permet d’obtenir une vision complète de la situation.
Une faille inconnue a-t-elle été exploitée ?
Non. L’attaque a uniquement profité de mauvaises configurations : des clés IAM (Identity and Access Management) à longue durée de vie dans un bucket S3 accessible, ainsi qu’un rôle Lambda doté de droits administrateur. Aucun zero-day n’a été utilisé, et aucun correctif n’est nécessaire.
Quelle est la mesure de protection la plus rapide à mettre en œuvre ?
Remplacer les clés IAM à longue durée de vie par des rôles éphémères et éviter d’attribuer des droits administrateur aux rôles d’exécution Lambda. Ainsi, l’attaque observée ne dispose ni de point d’entrée ni de moyen d’escalade vers un compte administrateur.
Nos suggestions de lecture
Source de l’image : générée par IA (juillet 2026)
