Des agents IA ont trouvé des secrets exposés. La frontière suivante était l’identité cloud
Microsoft a observé des attaques assistées par IA allant de secrets publics aux ressources cloud. Comment enquêter et contenir l’exposition.
Au-delà de l’ASPM
Une AppSec fondée sur la preuve pour les équipes qui développent avec l’IA
Plexicus utilise AI Swarm Pentest pour explorer des chemins d’application autorisés, valider ce qui est exploitable et fournir les preuves nécessaires pour prioriser la remédiation.
Découvrir AI Swarm PentestLe 5 novembre, Microsoft Threat Intelligence a rapporté que des acteurs utilisaient un framework à agents pour rechercher des identifiants exposés dans des dépôts publics et mener ensuite des actions dans le cloud. Dans au moins un cas, Microsoft a observé cinq minutes entre la recherche de secrets et l’extraction de données d’Azure Key Vault. Il s’agit d’un cas observé, pas d’un délai général pour toute attaque.
La valeur exposée est un point de départ
L’enquête décrit la recherche d’identifiants d’application et d’autres secrets, suivie dans certains incidents de connexions de principaux de service et de reconnaissance des ressources cloud. Une identité applicative peut atteindre ce que ses autorisations permettent. Le risque dépend donc du secret et des accès associés.
Microsoft a aussi observé des séquences adaptatives où des requêtes cloud échouées étaient suivies de changements de version ou de méthode d’API. Le rapport décrit des comportements observés ; il ne démontre pas que tous les secrets exposés ont produit le même résultat ni que chaque action était entièrement autonome.
Cette image est un exemple de documentation Microsoft, pas une capture d’une organisation touchée ni de l’attaque rapportée.
Enquêter sur les accès, pas seulement sur le signalement
| Question | Éléments à recueillir |
|---|---|
| Qu’a-t-on exposé ? | Révision, chemin, type d’identifiant et copies possibles. Éviter de copier le secret dans les tickets. |
| Quelle identité pouvait l’utiliser ? | Responsable, principal de service, périmètre du tenant, autorisations et expiration. |
| Qu’était-il possible d’atteindre ? | Coffres, stockage, applications et autres ressources autorisées. |
| Que s’est-il passé ensuite ? | Journaux disponibles de connexion et d’accès, reconnaissance, téléchargements et changements d’identifiants. |
| Qu’a-t-on contenu ? | Révocation ou rotation, confirmation du responsable et contrôle ultérieur. |
Supprimer un secret du fichier actuel n’invalide pas un identifiant existant. Suivez rapidement votre procédure d’incident : identifier le responsable, révoquer ou renouveler si nécessaire, examiner les droits et enquêter sur les accès pendant l’exposition. Microsoft précise que les jetons déjà émis peuvent rester valides jusqu’à leur expiration ; la réponse doit couvrir l’identité et ses accès en aval.
Réduire le chemin avant la prochaine alerte
Privilégiez les identités gérées ou de courte durée lorsqu’elles sont prises en charge, évitez les identifiants dans le code et accordez uniquement les droits nécessaires. Vérifiez les accès des principaux de service et les chemins de récupération exploitables. Si un coffre a pu être consulté, déterminez les identifiants stockés à renouveler dans le cadre de votre réponse à incident.
Plexicus décrit des tests applicatifs fondés sur des preuves et des flux de remédiation. Les équipes peuvent les associer à leurs processus existants de gestion des identités et d’incident cloud pour rendre les constats et le suivi vérifiables. Ces pages ne démontrent pas une contention Azure ni une rotation des identifiants automatisées par Plexicus.
Source de l’image : Documentation Microsoft Entra, récupération des applications, CC BY 4.0 ; capture originale non modifiée présentée comme exemple. Licence. Used with permission from Microsoft.
