Les attaquants assistés par l’IA ont utilisé des informations d’identification exposées et des rôles permissifs pour passer de l’accès initial au contrôle total de l’administrateur AWS en quelques minutes.
Les auteurs de la menace ont dévasté un environnement Amazon Web Services en moins de huit minutes, enchaînant vol d’identifiants, élévation de privilèges, mouvements latéraux et abus de ressources GPU à l’aide de grands modèles de langage, une attaque si rapide que les défenseurs n’ont pratiquement pas eu le temps de réagir.
Selon de nouvelles découvertes de l’équipe de recherche sur les menaces de Sysdig, les intrus ont transformé un seul identifiant exposé dans un compartiment S3 public en un contrôle administratif complet, démontrant comment l’automatisation assistée par l’IA a réduit le cycle de vie des attaques cloud de quelques heures à quelques minutes seulement.
L’opération, observée en novembre 2025, aurait combiné une mauvaise configuration du cloud avec de grands modèles de langage (LLM) pour compresser l’ensemble du cycle de vie de l’attaque.
« Le monde de la cybersécurité est aujourd’hui tout nouveau », a déclaré Ram Varadarajan, PDG d’Acalvio. « Dans cet environnement de menace, les organisations doivent accepter que la vitesse des violations est passée de quelques jours à quelques minutes. Les intrus autonomes peuvent désormais passer de l’accès initial au contrôle administratif complet en quelques minutes. » Se défendre contre cette classe d’attaques, a-t-il ajouté, nécessite une « technologie axée sur l’IA » capable de raisonner et de répondre à la même vitesse que les attaquants automatisés.
Des compartiments publics pour une escalade de privilèges en quelques minutes
Disposant d’un accès en lecture dans tout l’environnement, l’attaquant a rapidement énuméré les services AWS, puis a élevé les privilèges en modifiant une fonction Lambda existante. En injectant du code malveillant dans une fonction qui avait déjà un rôle d’exécution trop permissif, l’attaquant a pu créer de nouvelles clés d’accès pour un utilisateur administratif et les récupérer directement à partir du résultat de l’exécution Lambda.
Jason Soroko, chercheur principal à Sectigo, a déclaré que la cause profonde était tristement familière. « Nous devons dépasser la nouveauté de l’assistance de l’IA pour reconnaître l’erreur banale qui l’a rendue possible », a-t-il déclaré. « L’ensemble de la compromission a commencé parce que la victime a laissé des informations d’identification valides exposées dans des compartiments publics S3. Cet échec représente un refus obstiné de maîtriser les principes fondamentaux de la sécurité. »
Le code Lambda a montré des signes de génération LLM, notamment une gestion complète des exceptions, une logique de ciblage itérative et même des commentaires non anglais.
Mouvement latéral, LLMjacking et abus du GPU
Une fois l’accès administratif obtenu, l’attaquant s’est déplacé latéralement sur 19 principaux AWS distincts, assumant plusieurs rôles et créant de nouveaux utilisateurs pour répartir l’activité entre les identités. Cette approche a permis la persistance et la détection compliquée, ont noté les chercheurs.
Les attaquants se sont ensuite concentrés sur Amazon Bedrock, énumérant les modèles disponibles et confirmant que la journalisation des appels de modèles était désactivée. Les chercheurs ont déclaré que plusieurs modèles de fondation avaient été invoqués, un modèle cohérent avec le « LLMjacking ».
Ensuite, l’opération a dégénéré en abus de ressources. Après avoir préparé les clés et les groupes de sécurité, les attaquants ont tenté de lancer des instances GPU haut de gamme pour les charges de travail d’apprentissage automatique. Alors que les instances les plus puissantes ont échoué en raison de limites de capacité, une instance GPU coûteuse a finalement été lancée, avec des scripts pour installer CUDA, déployer des cadres de formation et exposer une interface publique JupyterLab.
Une partie du code a été trouvée faisant référence à des référentiels et à des ressources inexistants, que les chercheurs de Sysdig ont attribués aux hallucinations du LLM.
Les experts affirment que le point le plus troublant n’est pas que l’IA ait introduit une nouvelle technique d’attaque. C’est que l’IA a supprimé toute hésitation. « Lorsque vous réduisez cette attaque à l’essentiel, ce qui ressort n’est pas une technique révolutionnaire », a déclaré Shane Barney, RSSI chez Keeper Security. « Il s’agit du peu de résistance offerte par l’environnement une fois que l’attaquant a obtenu un accès légitime. » Il a averti que l’IA regroupe la reconnaissance, les tests de privilèges et les mouvements latéraux en « une séquence unique et rapide », éliminant le temps tampon sur lequel les défenseurs s’appuient historiquement.
Pour réduire l’exposition, les chercheurs de Sysdig ont conseillé d’appliquer le moindre privilège aux utilisateurs, rôles et rôles d’exécution Lambda IAM, en limitant strictement les autorisations telles que « UpdateFunctionCode » et « PassRole », et en garantissant que les compartiments S3 sensibles ne sont jamais publics. L’activation du versioning Lambda, l’activation de la journalisation des appels de modèles Amazon Bedrock et la surveillance des activités d’énumération à grande échelle sont également essentielles, ont-ils ajouté.
