Des acteurs malveillants utilisent l’intelligence artificielle (IA) pour accélérer les intrusions dans le cloud.
Lors d’un incident récent observé par les chercheurs de Sysdig, les attaquants sont passés de clés d’accès dérobées à un accès administratif complet dans un environnement AWS en moins de 10 minutes, illustrant la capacité de l’IA à raccourcir la durée des attaques cloud.
« L’acteur malveillant a obtenu des privilèges administratifs en moins de 10 minutes, compromis 19 principaux AWS distincts et détourné des modèles Bedrock ainsi que des ressources de calcul sur GPU », a déclaré les chercheurs.
Intrusion AWS assistée par l’IA
Selon l’analyse par Sysdig de l’incident de novembre 2025, l’attaque a commencé par la découverte d’identifiants AWS valides exposés dans des compartiments Amazon S3 accessibles au public.
Ces compartiments servaient à stocker des données de génération augmentée par récupération (RAG) pour des modèles d’IA et contenaient des clés d’accès persistantes, exploitables par quiconque les trouvait.
Les identifiants exposés appartenaient à un utilisateur IAM auquel était associée la politique ReadOnlyAccess, ainsi que des autorisations limitées pour Amazon Bedrock.
Reconnaissance dans AWS et les services d’IA
Bien que ces privilèges n’autorisent pas les actions administratives directes, ils offraient une large visibilité sur l’environnement.
Grâce à cet accès, l’acteur malveillant a effectué une reconnaissance approfondie de plusieurs services AWS, notamment Secrets Manager, Lambda, EC2, ECS, RDS, CloudWatch et Key Management Service.
Il a également répertorié les modèles Bedrock et les services d’IA associés dès le début de l’intrusion, ce qui indique un intérêt initial pour l’identification de ressources liées à l’IA susceptibles d’être détournées.
Élévation des privilèges par injection de code Lambda
Après avoir cartographié l’environnement, l’attaquant a tenté d’élever ses privilèges en assumant des rôles IAM généralement associés aux accès administratifs.
Après l’échec de ces tentatives, il s’est tourné vers une technique d’élévation plus fiable : l’injection de code dans une fonction Lambda.
Comme l’utilisateur IAM compromis disposait des autorisations UpdateFunctionCode et UpdateFunctionConfiguration, l’attaquant a pu modifier le code d’une fonction Lambda existante qui s’exécutait avec un rôle d’exécution trop permissif.
L’attaquant a répété cette approche à plusieurs reprises et a finalement réussi à créer de nouvelles clés d’accès pour un utilisateur IAM administrateur.
Cette étape lui a effectivement donné le contrôle total de l’environnement AWS sans nécessiter d’infrastructure externe de commande et contrôle (C2), puisque la fonction Lambda malveillante renvoyait directement les identifiants nouvellement créés dans sa sortie d’exécution.
L’analyse du code Lambda injecté a révélé plusieurs indices d’un développement assisté par l’IA.
Le script comportait une gestion détaillée des exceptions, des ajustements du délai d’expiration de l’exécution et des commentaires rédigés en serbe.
Les chercheurs ont également observé un comportement cohérent avec les hallucinations des grands modèles de langage (LLM), notamment des tentatives d’assumer des rôles dans des identifiants de comptes AWS inexistants et des références à un dépôt GitHub qui n’existe pas.
Mouvement latéral et persistance
Une fois l’accès administratif sécurisé, l’acteur malveillant a étendu son emprise en se déplaçant latéralement dans l’environnement.
Il a opéré sur 19 principaux AWS distincts, notamment plusieurs rôles et utilisateurs IAM, créé de nouvelles clés d’accès et mis en place un utilisateur de porte dérobée persistant auquel était associée la politique AdministratorAccess.
Détournement de LLM et abus des ressources GPU
L’attaquant s’est ensuite tourné vers le détournement de LLM, exploitant l’accès Amazon Bedrock de la victime pour invoquer plusieurs modèles de fondation, dont Claude, DeepSeek, Llama et Amazon Titan.
La journalisation des invocations de modèles étant désactivée, cette activité est probablement passée inaperçue tout en générant de véritables coûts d’utilisation pour l’organisation.
Lors de la dernière phase de l’attaque, l’acteur malveillant a provisionné une infrastructure GPU haut de gamme pour des charges de travail de machine learning.
Il a lancé avec succès une instance EC2 p4d.24xlarge qui coûte environ 32,77 dollars par heure, et a utilisé des scripts de données utilisateur pour installer CUDA, PyTorch et d’autres frameworks de ML.
Les scripts ont également lancé un serveur JupyterLab accessible au public, créant une porte dérobée qui aurait permis de conserver l’accès à l’instance même si les identifiants AWS étaient révoqués par la suite.
Réduire les risques cloud à l’ère de l’IA
À mesure que les attaques cloud assistées par l’IA gagnent en rapidité et en automatisation, les organisations ont besoin de contrôles défensifs qui vont au-delà de simples corrections de mauvaises configurations.
Les mesures suivantes visent à réduire l’exposition aux privilèges, à limiter les déplacements des attaquants et à améliorer la visibilité sur les activités cloud et d’IA à haut risque.
- Imposer un accès strict selon le principe du moindre privilège aux utilisateurs IAM, aux rôles et aux rôles d’exécution Lambda, et remplacer les clés d’accès persistantes par des identifiants temporaires fondés sur des rôles.
- Restreindre les capacités de modification de Lambda et de transmission de rôles en contrôlant strictement UpdateFunctionCode, UpdateFunctionConfiguration, et PassRole et en limitant les déploiements aux pipelines CI/CD approuvés.
- Sécuriser l’IA et les espaces de stockage de données cloud en veillant à ce que les compartiments S3 contenant des identifiants, des données RAG ou des artefacts de modèles ne soient jamais publics et soient surveillés en continu pour détecter toute exposition.
- Améliorer la détection des attaques assistées par l’IA en surveillant les énumérations à grande vitesse, les changements d’identité, les chaînes de rôles et les activités API anormales sur les services cloud.
- Verrouiller l’utilisation des ressources d’IA et de calcul en activant la journalisation des invocations de modèles Amazon Bedrock, en limitant les modèles pouvant être invoqués et en appliquant des quotas et des alertes aux familles d’instances GPU.
- Réduire le rayon d’explosion grâce à une segmentation stricte des comptes, à des politiques de confiance intercomptes renforcées et à un examen continu des résultats d’IAM Access Analyzer.
- Se préparer à une mise en quarantaine rapide en conservant des journaux d’audit immuables et en testant régulièrement les plans de réponse aux incidents propres au cloud, notamment pour les scénarios impliquant la compromission de systèmes serverless et l’abus de services d’IA.
Ensemble, ces mesures peuvent contribuer à raccourcir les délais de détection et à limiter le rayon d’explosion.
L’IA accélère les attaques cloud
Cet incident montre à quelle vitesse les intrusions cloud peuvent s’intensifier lorsque des identifiants exposés, des identités trop permissives et des outils automatisés sont combinés.
L’adoption croissante des grands modèles de langage dans les processus d’attaque devrait encore réduire le temps disponible pour la détection et la réponse.
À mesure que les attaques s’accélèrent et que la confiance implicite s’effrite, les organisations se tournent de plus en plus vers le zero trust pour limiter les accès et réduire l’impact des identités compromises.