6 min de lecture<\/p>\n
Le 28 novembre 2025, un attaquant a pris le contr\u00f4le d\u2019un compte AWS complet en huit minutes. Depuis la premi\u00e8re cl\u00e9 d\u2019acc\u00e8s vol\u00e9e jusqu\u2019aux droits d\u2019administrateur complets. L\u2019\u00e9quipe de s\u00e9curit\u00e9 de Sysdig a document\u00e9 ce cas. Ce qui est frappant, c\u2019est la rapidit\u00e9 : une IA a effectu\u00e9 l\u2019analyse et la cr\u00e9ation de scripts en temps r\u00e9el. La faille ayant permis l\u2019intrusion \u00e9tait une erreur de configuration connue.<\/strong><\/p>\n En lien avec :<\/span>Comment une faille dans Argo CD permet de prendre le contr\u00f4le d\u2019un cluster Kubernetes<\/a> \/<\/span> AWS et Azure sous surveillance de l\u2019UE : la d\u00e9pendance aux g\u00e9ants du cloud vacille<\/a><\/p>\n L’entr\u00e9e \u00e9tait grande ouverte sur le r\u00e9seau. Dans un bucket S3 accessible publiquement se trouvaient des donn\u00e9es d’entra\u00eenement pour un syst\u00e8me d’IA, incluant notamment des cl\u00e9s d’acc\u00e8s 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\u00e9cifique. Cette fonction s’appelait EC2-init. Elle \u00e9tait associ\u00e9e \u00e0 un r\u00f4le d’ex\u00e9cution dot\u00e9 de droits d’administration.<\/p>\n \u00c0 partir de l\u00e0, tout s’est encha\u00een\u00e9 rapidement. L’attaquant a r\u00e9\u00e9crit la fonction pour qu’elle g\u00e9n\u00e8re de nouvelles cl\u00e9s d’acc\u00e8s pour un utilisateur administrateur nomm\u00e9 frick, puis a lu directement le r\u00e9sultat dans la r\u00e9ponse de la fonction. Aucun d\u00e9tour par un serveur externe, aucune coquille r\u00e9seau (reverse shell). Il a ensuite acc\u00e9d\u00e9 \u00e0 19 identit\u00e9s AWS diff\u00e9rentes, cr\u00e9\u00e9 un second administrateur avec une porte d\u00e9rob\u00e9e et s\u00e9curis\u00e9 ainsi son acc\u00e8s \u00e0 plusieurs reprises.<\/p>\n Puis les co\u00fbts ont explos\u00e9. Via le service d’IA Amazon Bedrock, l’attaquant a exploit\u00e9 des mod\u00e8les de langage tiers aux frais de la victime. En parall\u00e8le, il a lanc\u00e9 une instance GPU factur\u00e9e environ 30 euros de l’heure pour ex\u00e9cuter ses propres mod\u00e8les. AWS a interrompu l’instance apr\u00e8s cinq minutes en raison de limites de capacit\u00e9. Le code lui-m\u00eame \u00e9tait r\u00e9v\u00e9lateur : des commentaires en serbe et des num\u00e9ros de comptes AWS invent\u00e9s trahissaient la participation d’un mod\u00e8le de langage dans sa r\u00e9daction.<\/p>\n Le chiffre de huit minutes semble remettre en cause tout ce que l\u2019on sait de la s\u00e9curit\u00e9 cloud. L\u2019analyse de la trajectoire de l\u2019attaque montre l\u2019inverse. Aucune faille inconnue, aucun exploit sp\u00e9cifique \u00e0 l\u2019IA. Chaque \u00e9tape a exploit\u00e9 une mauvaise configuration document\u00e9e.<\/p>\n Des cl\u00e9s d\u2019acc\u00e8s persistantes \u00e9taient stock\u00e9es dans un compartiment public. Un r\u00f4le d\u2019ex\u00e9cution Lambda disposait de droits administrateur alors qu\u2019il n\u2019en avait nul besoin. Un utilisateur faiblement autoris\u00e9 pouvait \u00e9craser le code de fonctions tierces. Ces trois erreurs, combin\u00e9es, ont form\u00e9 la cha\u00eene. Chacune d\u2019elles est connue depuis des ann\u00e9es et mentionn\u00e9e dans chaque guide de durcissement AWS.<\/p>\n L\u2019IA a acc\u00e9l\u00e9r\u00e9 et automatis\u00e9 l\u2019attaque. Elle ne l\u2019a pas rendue possible. Ceux qui interpr\u00e8tent ce cas comme une preuve que l\u2019IA rend le cloud moins s\u00fbr passent \u00e0 c\u00f4t\u00e9 de la cause r\u00e9elle. Et donc du point o\u00f9 la d\u00e9fense peut agir. La cause est r\u00e9parable, sans m\u00eame avoir \u00e0 recourir \u00e0 des mesures anti-IA.<\/p>\n Un second indicateur remet les choses en perspective. L’unit\u00e9 de s\u00e9curit\u00e9 Mandiant de Google analyse chaque ann\u00e9e des centaines de milliers d’heures de r\u00e9ponse aux incidents. Le rapport M-Trends 2026, publi\u00e9 le 23 mars, contient une phrase qui contredit la panique ambiante : on ne peut pas consid\u00e9rer 2025 comme l’ann\u00e9e o\u00f9 les attaques ont \u00e9t\u00e9 directement g\u00e9n\u00e9r\u00e9es par l’IA.<\/p>\n Les chiffres confirment cette analyse. En 2025, la dur\u00e9e m\u00e9diane de pr\u00e9sence d’un attaquant dans le r\u00e9seau est pass\u00e9e \u00e0 14 jours, contre 11 jours l’ann\u00e9e pr\u00e9c\u00e9dente. Dans 52 % des cas, les entreprises ont d\u00e9tect\u00e9 elles-m\u00eames l’intrusion. L’exploitation de vuln\u00e9rabilit\u00e9s reste, pour la sixi\u00e8me ann\u00e9e cons\u00e9cutive, le vecteur d’attaque le plus fr\u00e9quent, avec 32 % des cas. La majorit\u00e9 des attaques s’inscrivent toujours dans une \u00e9chelle de temps allant de quelques jours \u00e0 plusieurs semaines.<\/p>\n L’incident des huit minutes est bien r\u00e9el, mais il s’agit d’une exception, et non d’une nouvelle norme. Sa rapidit\u00e9 s’explique par des conditions id\u00e9ales. Pour les d\u00e9fenseurs, c’est une bonne nouvelle : en \u00e9liminant ces conditions favorables, on prive l’attaque rapide de son fondement.<\/p>\n Aucun correctif \u00e9diteur ne r\u00e9soudra ce probl\u00e8me, car la source du risque r\u00e9side dans la configuration. C\u2019est pr\u00e9cis\u00e9ment l\u00e0 qu\u2019il faut agir. Les \u00e9tapes sont class\u00e9es par ordre d\u2019impact.<\/p>\n La diff\u00e9rence entre un compte compromis en huit minutes et un environnement s\u00e9curis\u00e9 ne r\u00e9side pas dans un nouvel outil. Elle tient aux param\u00e8tres par d\u00e9faut qu\u2019il faut conna\u00eetre et configurer.<\/p>\n L\u2019agitation autour des huit minutes d\u00e9tourne l\u2019attention du diagnostic r\u00e9el. L\u2019attaque a \u00e9t\u00e9 rapide parce que les bases de l\u2019hygi\u00e8ne informatique faisaient d\u00e9faut. Des identifiants temporaires, des r\u00f4les attribu\u00e9s avec parcimonie et un regard sur les compartiments de stockage ouverts auraient pu briser la cha\u00eene \u00e0 chaque \u00e9tape. Ces mesures sont anciennes, peu spectaculaires et efficaces.<\/p>\n Un d\u00e9tail devrait en outre alerter les d\u00e9fenseurs. Sysdig met en garde : les traces d\u2019IA trahisseuses dans le code pourraient bient\u00f4t dispara\u00eetre. Les agents plus performants n\u2019\u00e9crivent plus de commentaires en serbe ni n\u2019inventent de num\u00e9ros de compte. La fen\u00eatre permettant de d\u00e9tecter une attaque assist\u00e9e par IA dans le code se referme. Reste le durcissement des syst\u00e8mes, qui freine d\u00e9j\u00e0 chacune de ces \u00e9tapes aujourd\u2019hui.<\/p>\n Le LLMjacking consiste, pour des attaquants, \u00e0 s\u2019emparer de comptes cloud vol\u00e9s afin d\u2019ex\u00e9cuter des mod\u00e8les de langage co\u00fbteux via des services comme Amazon Bedrock. C\u2019est la victime qui paie la facture. Dans l\u2019affaire Sysdig, l\u2019attaquant a d\u00e9tourn\u00e9 des mod\u00e8les \u00e9trangers et lanc\u00e9 en plus une instance GPU \u00e0 ses frais.<\/p>\n<\/details>\n Non. L\u2019affaire pr\u00e9cise des huit minutes provient de l\u2019\u00e9quipe de s\u00e9curit\u00e9 de Sysdig. Le rapport Mandiant de Google, M-Trends 2026, fournit une analyse compl\u00e9mentaire et \u00e9voque une dur\u00e9e m\u00e9diane de d\u00e9tection de 14 jours. L\u2019association des deux sources permet d\u2019obtenir une vision compl\u00e8te de la situation.<\/p>\n<\/details>\n Non. L\u2019attaque a uniquement profit\u00e9 de mauvaises configurations : des cl\u00e9s IAM (Identity and Access Management) \u00e0 longue dur\u00e9e de vie dans un bucket S3 accessible, ainsi qu\u2019un r\u00f4le Lambda dot\u00e9 de droits administrateur. Aucun zero-day n\u2019a \u00e9t\u00e9 utilis\u00e9, et aucun correctif n\u2019est n\u00e9cessaire.<\/p>\n<\/details>\n Remplacer les cl\u00e9s IAM \u00e0 longue dur\u00e9e de vie par des r\u00f4les \u00e9ph\u00e9m\u00e8res et \u00e9viter d\u2019attribuer des droits administrateur aux r\u00f4les d\u2019ex\u00e9cution Lambda. Ainsi, l\u2019attaque observ\u00e9e ne dispose ni de point d\u2019entr\u00e9e ni de moyen d\u2019escalade vers un compte administrateur.<\/p>\n<\/details>\n Nos suggestions de lecture<\/p>\n Plus du r\u00e9seau MBF Media<\/p>\nL’essentiel en bref<\/h2>\n
\n
Huit minutes pour passer d’un bucket S3 \u00e0 une cl\u00e9 d’administration<\/h2>\n
Aucun zero-day, mais une cha\u00eene d\u2019erreurs connues<\/h2>\n
Pourquoi le nombre de minutes induit en erreur<\/h2>\n
Cinq \u00e9tapes pour renforcer la s\u00e9curit\u00e9 des comptes AWS d\u00e8s maintenant<\/h2>\n
\n
Mauvaise configuration vs. configuration renforc\u00e9e<\/h2>\n
\n\n
\n \nAspect<\/th>\n Cas vuln\u00e9rable<\/th>\n Configuration renforc\u00e9e<\/th>\n<\/tr>\n<\/thead>\n \n Cl\u00e9s d’acc\u00e8s<\/strong><\/td>\n longue dur\u00e9e, dans un bucket public<\/td>\n r\u00f4les \u00e9ph\u00e9m\u00e8res<\/td>\n<\/tr>\n \n R\u00f4le d’ex\u00e9cution Lambda<\/strong><\/td>\n droits d’administrateur<\/td>\n seulement droits fonctionnels<\/td>\n<\/tr>\n \n Buckets S3<\/strong><\/td>\n publics avec identifiants d’acc\u00e8s<\/td>\n priv\u00e9s, scann\u00e9s r\u00e9guli\u00e8rement<\/td>\n<\/tr>\n \n Impact d’une cl\u00e9 divulgu\u00e9e<\/strong><\/td>\n acc\u00e8s \u00e0 l’administration du compte<\/td>\n inutilisable apr\u00e8s une heure<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n Ce que les \u00e9quipes doivent retenir de ce cas<\/h2>\n
Questions fr\u00e9quentes<\/h2>\n
Qu\u2019est-ce que le LLMjacking ?<\/strong><\/summary>\n
L\u2019affaire des huit minutes provient-elle de Google ou de GTIG ?<\/summary>\n
Une faille inconnue a-t-elle \u00e9t\u00e9 exploit\u00e9e ?<\/summary>\n
Quelle est la mesure de protection la plus rapide \u00e0 mettre en \u0153uvre ?<\/summary>\n
\n