Huit minutes jusqu’à l’administration d’AWS : comment un bucket S3 ouvert et une Lambda admin ont

6 min de lecture

Le 28 novembre 2025, un attaquant a pris le contrôle total d’un compte AWS en huit minutes. Du premier accès volé jusqu’aux droits d’administrateur complets. C’est l’équipe de sécurité de Sysdig qui a documenté l’incident. Le point critique ? La rapidité : une IA a mené la reconnaissance et généré des scripts en temps réel. La faille initiale était une erreur de configuration bien connue.

Les points clés en bref

• Huit minutes jusqu’à l’admin : Selon Sysdig, un attaquant a compromis un compte AWS en moins de dix minutes. Des clés volées dans un bucket S3 public jusqu’à la création d’un utilisateur admin.
• L’erreur se nichait dans la config : Une fonction Lambda disposait d’un rôle d’exécution avec des droits d’administrateur. Quiconque pouvait modifier la fonction héritait de ces droits. Aucune nouvelle faille n’a été nécessaire.
• L’IA comme accélérateur : Elle a généré le code d’attaque et exploré le compte en temps réel. Pourtant, selon Mandiant, la médiane du secteur pour les attaques reste de 14 jours. Ce cas de huit minutes est une exception, avec des conditions particulières.

Lié :Comment une faille Argo CD ouvre tout un cluster Kubernetes  /  AWS et Azure sous surveillance de l’UE

Huit minutes du bucket S3 à la clé admin

Le point d’entrée était accessible en ligne. Dans un bucket S3 public se trouvaient des données d’entraînement pour un système d’IA, incluant des clés d’accès valides pour un utilisateur IAM. Cet utilisateur avait peu de droits, mais une seule permission suffisait : il pouvait modifier le code d’une fonction Lambda spécifique. Cette fonction, nommée EC2-init, était associée à un rôle d’exécution doté de droits d’administrateur.

À partir de là, tout est allé très vite. L’attaquant a modifié la fonction pour qu’elle génère de nouvelles clés d’accès pour un utilisateur admin nommé *frick*, puis a récupéré le résultat directement dans la réponse de la fonction. Pas de détour par un serveur externe, pas de reverse shell. Ensuite, il a accédé à 19 identités AWS différentes, créé un second admin de secours et sécurisé ainsi son accès de multiples façons.

Puis les coûts ont explosé. Via le service 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 à environ 30 euros par heure pour entraîner ses propres modèles. AWS a arrêté 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 compte AWS inventés trahissaient l’intervention d’un modèle de langage.

Pas une faille zero-day, mais une chaîne de vulnérabilités connues

Le chiffre des huit minutes semble défier tout ce que l’on sait sur la sécurité cloud. Pourtant, l’analyse du chemin d’attaque révèle l’inverse. Aucune vulnérabilité inconnue, aucun exploit spécifique à l’IA. Chaque étape a exploité une mauvaise configuration documentée.

Des clés d’accès à longue durée de vie traînaient dans un bucket public. Un rôle d’exécution Lambda disposait de droits administrateur, alors qu’il n’en avait jamais besoin. Un utilisateur faiblement autorisé pouvait écraser du code fonctionnel tiers. Ces trois erreurs combinées ont formé la chaîne. Chacune est connue depuis des années et mentionnée dans tous les guides de durcissement AWS.

L’IA a accéléré et automatisé l’attaque. Mais elle ne l’a pas rendue possible. Ceux qui interprètent ce cas comme la preuve que l’IA rend le cloud moins sûr passent à côté de la véritable cause. Et donc du point où la défense est efficace. La cause est réparable, sans avoir besoin d’une contre-mesure IA.

Pourquoi le chiffre des minutes induit en erreur

Un deuxième élément remet les choses en perspective. L’équipe de sécurité de Google, Mandiant, analyse chaque année des centaines de milliers d’heures d’intervention sur incident. Dans le rapport M-Trends 2026 daté du 23 mars, une phrase contredit la panique : 2025 ne doit pas être considéré comme l’année où les attaques ont été directement générées par l’IA.

Les chiffres le confirment. La durée médiane de présence d’un attaquant dans un réseau est passée à 14 jours en 2025, contre 11 l’année précédente. Dans 52 % des cas, les entreprises ont détecté elles-mêmes l’intrusion en premier. Les vulnérabilités exploitées restent, avec 32 %, le vecteur d’entrée le plus fréquent, pour la sixième année consécutive. La majorité des attaques se déroulent toujours à l’échelle de jours, voire de semaines.

Le cas des huit minutes est réel, mais il s’agit d’une exception, pas d’une nouvelle norme. Il n’a été aussi rapide que parce que les conditions étaient idéales. Pour les défenseurs, c’est une bonne nouvelle : en éliminant ces conditions, on prive l’attaque rapide de son fondement.

Cinq étapes pour durcir dès maintenant vos comptes AWS

Aucun correctif constructeur ne résoudra le problème, car il réside dans la configuration. C’est précisément là qu’il peut être corrigé. Les étapes sont classées par ordre d’efficacité.

1. Supprimer les clés à longue durée de vie. Au lieu de clés IAM permanentes, intégrez des rôles à durée limitée et des identifiants temporaires dans le fonctionnement standard. Une clé divulguée, devenue inutile après une heure, n’ouvre plus aucune porte.
2. Séparer les rôles admin des rôles d’exécution. Aucune fonction Lambda n’a besoin de droits administrateur pour accomplir sa tâche. Chaque rôle d’exécution obtient exactement les droits nécessaires à sa fonction, pas plus.
3. Repérer les buckets publics. Les buckets S3 contenant des données d’entraînement finissent facilement exposés par inadvertance. Un scan régulier des buckets ouverts et des clés d’accès qu’ils contiennent ferme la porte d’entrée la plus courante.
4. Sécuriser Bedrock avec des garde-fous. Les Service Control Policies limitent qui peut lancer des services d’IA coûteux et des instances GPU. Cela plafonne les dégâts si un compte est compromis.
5. Surveiller l’exécution en temps réel. Les nouveaux utilisateurs admin, les appels Bedrock suspects et les instances GPU soudainement lancées sont des signaux clairs. Les détecter en temps réel permet d’arrêter l’attaque en plein vol.

Mauvaise configuration contre environnement sécurisé

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 appliquer.

Ce que les équipes doivent retenir de ce cas

L’émoi suscité par ces huit minutes détourne l’attention du véritable constat. L’attaque a été rapide parce que les bonnes pratiques de base faisaient défaut. Des identifiants éphémères, des rôles attribués avec parcimonie et un contrôle des buckets ouverts auraient brisé 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 révélatrices d’IA dans le code vont bientôt disparaître. Les agents malveillants plus performants n’écriront plus de commentaires en serbe et n’inventeront plus de numéros de compte. La fenêtre permettant de détecter une attaque assistée par IA via le code se referme. Il reste le durcissement, qui freine déjà aujourd’hui chacune de ces étapes.

Foire aux questions

Source de l’image : générée par IA (juillet 2026)