Huit minutes ont suffi. Des cloud exposées au contrôle administratif total dans AWS, l'attaque documentée par Sysdig montre à quelle vitesse un cloud peut être compromis lorsque l'automatisation, l'usurpation d'identité et cloud permissifs convergent.
Il n'ya eu aucun zero-day, aucun malware aucune chaîne d'exploits inédite. L'attaquant s'est entièrement appuyé sur des identifiants valides, des services AWS natifs et une prise de décision automatisée pour passer de l'accès initial aux privilèges d'administrateur à la vitesse de l'éclair.
Au cours des dernières semaines, nous avons examiné le comportement initial des agents IA autonomes, la manière dont ils ont commencé à interagir et à s'influencer mutuellement dans des environnements partagés, et comment une coordination s'est rapidement mise en place sans intervention humaine.
Cet incident montre ce qui se passe lorsque ces dynamiques sont appliquées à un cloud réel.
Ce que nous avions anticipé est désormais observable : la reconnaissance s'accélère, et dès lors qu'un pirate contrôle une identité, il contrôle de fait l'environnement. Il n 'en résulte pas une nouvelle catégorie d'attaques, mais des attaques nettement plus rapides.
Cette analyse détaille l'intrusion étape par étape, en mettant en évidence les moments où l'attaque s'est accélérée, les moments où les défenseurs auraient pu intervenir de manière réaliste, et les raisons pour lesquelles la détection comportementale centrée sur l'identité est désormais le seul moyen viable d'arrêter cloud qui se déplacent à la vitesse de l'IA.
Quand l'automatisation réduit considérablement la durée d'une attaque
Cet incident se distingue par le fait que l'IA a éliminé les frictions. L'attaquant n'a pas sondé prudemment ni enchaîné les vulnérabilités. L'automatisation lui a permis d'énumérer les services, d'évaluer les chemins d'accès privilégiés et d'exécuter l'escalade plus rapidement qu'un opérateur humain ne pourrait le faire manuellement.
Pour les défenseurs, la plupart des actions impliquées sembleraient légitimes prises isolément. Les appels API ont été authentifiés, les services ont été accessibles via des mécanismes approuvés et les autorisations ont été utilisées de manière abusive, sans être contournées.
Le seul signal fiable était comportemental : qui agissait, à quelle vitesse ils se déplaçaient et quelle séquence d'actions se déroulait à travers les services.
Flux d'attaque de haut niveau
À un niveau élevé, l'intrusion s'est déroulée en cinq phases :
- Accès initial via des actifs exposés
- Reconnaissance inter-services
- Élévation des privilèges via l'utilisation abusive de Lambda
- Persistance et expansion
- Abus des ressources et externalisation des données
Bien que la séquence complète comporte de nombreuses étapes individuelles, seules certaines d'entre elles sont essentielles à la réussite de l'attaque. Si ces étapes sont détectées ou interrompues, l'attaque échoue complètement.
Phase 1 : accès initial via Cloud exposées
Ce qui s'est passé :
L'attaque a commencé en dehors du compte AWS et ne visait pas une organisation spécifique.
L'attaquant a recherché des compartiments S3 accessibles au public en utilisant des conventions de nommage couramment associées aux outils d'IA et cloud . Tout environnement AWS respectant ces conventions constituait un point d'entrée potentiel.
Dans l'un des compartiments, l'attaquant a trouvé des fichiers contenant des clés d'accès IAM. Grâce à ces identifiants valides, il s'est directement authentifié sur le compte AWS de la victime.
Du point de vue d'AWS, une identité valide s'était connectée avec succès.
Pourquoi est-ce important ?
C'est là que de nombreux cloud commencent discrètement. Les problèmesCloud créent souvent une brèche, mais c'est l'utilisation abusive des identités qui détermine jusqu'où un pirate peut aller.
Une fois authentifié, l'attaquant est immédiatement passé à la phase suivante de l'attaque.
Phase 2 : Reconnaissance interservices à la vitesse de la machine
Ce qui s'est passé :
Après authentification, l'attaquant a procédé à une reconnaissance approfondie de plusieurs services AWS, notamment S3, Lambda, EC2, IAM, Bedrock et CloudTrail.
L'activité était rapide, systématique et automatisée. Les réponses API étaient ingérées et évaluées en temps réel afin d'identifier les chemins d'escalade viables.
Pourquoi est-ce important ?
La reconnaissance rend possible tout ce qui suit. Sans visibilité sur les services, les rôles et la confiance, les voies d'escalade restent cachées.
C'est là que l'automatisation change la donne. Les outils assistés par l'IA permettent aux pirates d'ingérer les réponses API, d'évaluer les autorisations et d'identifier les chemins viables en quelques secondes.
Pour les équipes SOC, cette phase représente la première occasion réaliste d'intervenir. Une fois que l'escalade des privilèges commence, les fenêtres de réponse se réduisent considérablement.
Ce comportement correspond étroitement aux techniques documentées dans MITRE ATLAS, concernant l'utilisation abusive de comptes valides et la découverte cloud . Plutôt que d'inventer de nouvelles techniques, l'attaquant a accéléré des comportements connus à l'aide de l'automatisation.
Phase 3 : L'abus de Lambda comme principal point d'étranglement
Ce qui s'est passé :
L'attaquant s'est concentré sur une fonction AWS Lambda existante et l'a utilisée comme mécanisme d'élévation des privilèges.
Tout d'abord, ils ont modifié le code de la fonction et augmenté son délai d'exécution. Ce Lambda disposait d'un rôle d'exécution avec des autorisations suffisantes pour créer des utilisateurs IAM et des clés d'accès.
Ensuite, ils ont invoqué la fonction modifiée. Lors de son exécution, la fonction a créé de nouvelles clés d'accès IAM avec des privilèges administratifs.
Chaque étape était légitime en soi, mais prises ensemble, elles ont transformé un composant d'automatisation de routine en une voie d'escalade.
Pourquoi est-ce important ?
Cette séquence a marqué le moment où l'attaque est devenue irréversible.
Si l'un des maillons de la chaîne est défaillant, celle-ci se rompt. Si la fonction ne peut être modifiée, elle ne peut être détournée. Si elle n'est jamais exécutée, aucune nouvelle identité n'est créée. Si elle est exécutée mais ne parvient pas à créer de clés d'accès administrateur, l'attaquant est bloqué.
Les fonctions Lambda concentrent l'automatisation et les privilèges comme peu d'autres services le font. Les rôles d'exécution sont souvent plus larges que prévu. Les modifications du code sont peu fréquentes et peu contrôlées. L'invocation est courante et attendue.
Rien dans cette séquence ne viole la politique AWS ni ne déclenche une défaillance manifeste du contrôle. Le risque n'apparaît que lorsque l'on examine comment le comportement de la fonction a changé et ce qu'il a permis immédiatement après.
Il s'agit d'un schéma récurrent dans cloud modernes. Les pirates n'ont pas besoin d'exploiter l'infrastructure. Ils la réutilisent.
Phase 4 : Élévation programmatique des privilèges
Ce qui s'est passé :
À l'aide de la fonction Lambda modifiée, l'attaquant a créé de nouvelles clés d'accès IAM dotées de privilèges administratifs.
Il s'agissait d'une élévation de privilèges sans exploitation.
L'attaquant a simplement utilisé un rôle d'exécution pour effectuer des actions qu'il était autorisé à effectuer, mais pas de la manière prévue par ses créateurs.
À partir de ce moment, l'attaquant a pris le contrôle du compte.
Pourquoi est-ce important ?
Pour les défenseurs, c'est là que les contrôles de sécurité traditionnels échouent souvent. Les systèmes de gestion des identités et des accès appliquent les politiques, pas les intentions.
Une fois les privilèges d'administrateur accordés, la plupart des contrôles sont levés. Une fois l'accès administratif accordé, le champ d'action se réduit et la correction devient nettement plus complexe.
Phase 5 : Persévérance et expansion
Ce qui s'est passé :
Une fois l'accès administratif sécurisé, l'attaquant s'est concentré sur la persistance.
Plus précisément, ils ont créé un nouvel utilisateur IAM et ont joint le fichier Accès administrateur politique, généré des clés d'accès supplémentaires pour les utilisateurs existants et récupéré des secrets à partir de Secrets Manager et SSM Parameter Store.
Chaque action renforçait la position de l'attaquant et réduisait l'efficacité des mesures correctives. Même si un identifiant était révoqué, les autres restaient valides.
Pourquoi est-ce important ?
Cette phase reflète un passage de l'accès à l'assurance. L'attaquant s'assurait de conserver le contrôle même si les défenseurs réagissaient.
Une fois encore, ces actions ont été effectuées via des API légitimes à l'aide d'autorisations valides. La différence entre maintenance et compromission réside entièrement dans le comportement et le timing.
Phase 6 : Abus des ressources et externalisation des données
Ce qui s'est passé :
L'attaquant s'est déplacé pour frapper.
Ils ont lancé une instance GPU haut de gamme avec un groupe de sécurité ouvert et ont exposé l'interface JupyterLab.
Ils ont invoqué les modèles Bedrock et partagé un instantané EBS en externe.
Pourquoi est-ce important ?
À ce stade, le compromis avait déjà réussi. Ces actions indiquent clairement les intentions des attaquants : abus de ressources, exfiltration potentielle de données et monétisation.
Cette étape correspond aux modèles abordés dans notre épisode de podcast sur la manière dont les attaquants ciblent AWS Bedrock, notamment le LLMjacking, l'abus de coûts et l'exposition des données une fois que cloud sont compromises.
« Et si... ? »
L'attaque documentée s'est arrêtée là où elle s'est arrêtée parce qu'elle a été observée, et non parce que l'attaquant était à court d'options.
Avec un accès administrateur permanent, l'attaquant aurait pu :
- Persistance à long terme établie grâce à des politiques de confiance et des rôles inter-comptes
- Pipelines CI/CD modifiés pour injecter du code malveillant dans la production
- Création d'une infrastructure fantôme reflétant les charges de travail légitimes
- Exfiltration silencieuse et progressive des données à l'aide d'instantanés et de réplications
- Utilisation continue des services d'IA, en intégrant l'abus de coûts dans l'utilisation normale
- Pivoté vers des comptes AWS connectés ou des plateformes SaaS
Aucune de ces actions ne nécessite d'exploits supplémentaires. Elles nécessitent du temps. Huit minutes n'étaient qu'un point de départ.
Le besoin crucial d'une détection post-compromission
Au moment où l'impact se produit, la prévention a déjà échoué.
La valeur défensive se déplace plus tôt dans la chaîne d'attaque, avant que l'escalade des privilèges et la persistance ne verrouillent le contrôle de l'attaquant.
Bien que la chaîne d'attaque complète soit longue, les défenseurs peuvent se concentrer sur un ensemble réduit d'étapes critiques tout au long du flux d'attaque :
- Reconnaissance rapide et étendue entre les services
- Modification d'une fonction Lambda existante
- Création programmatique d'un accès administrateur
- Établissement d'identités IAM persistantes
- Externalisation des données via des mécanismes cloud
Il s'agit de comportements qui s'écartent nettement des modèles d'utilisation normaux lorsqu'ils sont considérés dans leur séquence.
Le défi réside dans la corrélation.
La plupart des contrôles cloud sont statiques de par leur conception et peinent à lutter contre les intentions malveillantes.
Dans cet incident :
- Les informations d'identification étaient valides.
- Les API ont été utilisées conformément à leur conception.
- Les autorisations existaient légitimement
La seule anomalie concernait le comportement au fil du temps.
C'est cette lacune en matière de détection que les attaques rapides assistées par l'IA exploitent.
Pourquoi la détection comportementale centrée sur l'identité est nécessaire
Lorsque les attaques se déplacent à la vitesse d'une machine, la détection doit fonctionner au même niveau.
Cela nécessite de comprendre :
- Comment les identités humaines, machines et agents se comportent normalement
- Comment accéder aux services
- Quelles séquences d'actions sont courantes ou rares ?
- Comment le comportement change lorsque le contrôle passe à l'attaquant
La détection centrée sur l'identité traite cloud , humaines, non humaines et agentives, comme le signal principal. L'IA comportementale modélise la manière dont ces identités fonctionnent à travers les services et les environnements.
Lorsque la reconnaissance s'accélère, lorsque le comportement Lambda change, lorsque des privilèges sont accordés de manière inattendue, ces changements sont détectés en temps réel.
C'estle seul moyen pratique d'interrompre les attaques avant que l'escalade des privilèges ne devienne irréversible.
Comment Vectra AI ce type d'attaque
La Vectra AI est conçue précisément pour répondre à ce type de problèmes.
En analysant les comportements d'identité à travers les plans cloud , le trafic réseau, l'activité SaaS et cloud , Vectra AI les premières étapes des attaques qui s'appuient sur des accès valides et l'automatisation.
Au lieu d'attendre l'impact, il se concentre sur :
- Modèles de reconnaissance
- Abus de privilèges
- Mouvement latéral
- Utilisation abusive des données
Lorsque l'accès administrateur peut être compromis en quelques minutes, la réponse automatisée n'est pas facultative. C'est le seul moyen d'agir dans le laps de temps très court entre l'accès et l'escalade.
Cet incident devrait remettre les attentes à zéro.
Huit minutes, ce n'est plus exceptionnel. C'est ce que permet l'automatisation lorsque l'identité est usurpée et que les défenses reposent sur des hypothèses statiques. La leçon à retenir n'est pas de craindre l'IA, mais de reconnaître que les attaquants l'utilisent déjà pour réduire les délais, éliminer les hésitations et prendre des décisions à grande échelle.
Les défenseurs doivent réagir de la même manière : la détection doit être comportementale, la couverture doit être centrée sur l'identité et la réponse doit être automatisée.
En effet, lorsque l'accès cloud atteint la vitesse de l'IA, il n'y a plus le temps de rassembler les alertes après coup.