Un rôle d’administrateur d’Agent ID mal défini dans Entra ID a permis aux utilisateurs de s’approprier des principaux de service non liés, ce qui a permis une élévation potentielle des privilèges et un impact à l’échelle du locataire.
Un rôle administratif destiné aux agents IA au sein de l’écosystème Entra ID de Microsoft pourrait permettre des attaques d’élévation de privilèges et de prise de contrôle de locataire, car il disposait de privilèges sur plus que les objets liés aux agents.
Les chercheurs de Silverfort ont découvert que les utilisateurs affectés au rôle « Administrateur d’ID d’agent » de Microsoft, limité aux objets liés aux agents tels que les plans et les identités d’agent, pouvaient s’approprier des principes de service non liés au sein du locataire. Ces utilisateurs pourraient ensuite joindre des informations d’identification et s’authentifier en tant qu’applications (services non liés) pour potentiellement manipuler la communication d’application à application dans les environnements d’entreprise.
« Avant le correctif, le rôle d’administrateur d’ID d’agent permettait d’attribuer la propriété des principaux de service au-delà des identités liées à l’agent, permettant ainsi des fonctionnalités similaires à des rôles tels que l’administrateur d’application, mais sans être spécifiquement limité aux cas d’utilisation d’agent », ont déclaré les chercheurs de Silverfort dans un article de blog.
Agent uniquement signifiait brièvement tout
Le problème était un échec dans l’application de la portée au sein d’une nouvelle offre de sécurité de l’identité des agents.
Introduit dans le cadre des efforts de Microsoft visant à opérationnaliser les agents IA via sa plateforme d’identité d’agent, le rôle d’administrateur d’ID d’agent est un effort visant à donner aux agents autonomes leurs propres identités gouvernées dans Entra ID.
Le rôle a été conçu pour fonctionner au sein d’un ensemble d’objets nouvellement introduits liés aux agents IA. Cependant, comme les identités d’agent sont finalement construites sur les mêmes primitives que les applications, à savoir les principaux de service, la frontière entre les objets « agents » et « non-agents » n’était pas correctement définie.
Cette confusion architecturale pourrait permettre aux détenteurs de rôles de s’ajouter en tant que propriétaires d’un large éventail de principes de service au sein du locataire. Mais la même action a été bloquée pour les objets d’application, ce qui suggère que la faille était spécifique à la couche principale du service plutôt qu’au modèle d’identité plus large.
L’objet d’application et le principal de service sont deux objets liés créés chaque fois qu’une application est enregistrée dans Microsoft Entra ID.
« L’objet application sert de définition globale de l’application et décrit sa configuration », expliquent les chercheurs. « Le principal du service représente l’application en tant qu’identité au sein d’un locataire et est l’objet qui s’authentifie, se voit attribuer des rôles et des autorisations et accède aux ressources. »
Le manque de définition a permis l’expansion des privilèges, permettant au rôle d’imiter les capacités d’un rôle plus privilégié comme celui d’administrateur d’application. Cela se produisait par défaut et n’a déclenché aucune alarme, ont noté les chercheurs.
De la propriété principale à la reprise totale
Une fois la propriété d’un principal de service obtenue, l’attaquant pourrait générer de nouvelles informations d’identification telles que des secrets client ou des certificats, et les utiliser pour s’authentifier en tant qu’application compromise. Si l’application détenait des rôles d’annuaire élevés ou des autorisations API sensibles, les attaquants pourraient hériter de ces privilèges.
« L’impact dépend des privilèges attribués au principal du service ciblé », ont indiqué les chercheurs. « Dans les environnements où les principaux de service sont largement utilisés ou détiennent des autorisations élevées, cela peut conduire à une escalade significative. La posture du locataire peut influencer davantage l’impact, par exemple dans le cas d’applications largement consenties ou de configurations permissives. »
Les chercheurs ont noté que l’agent ID Administrator est relativement nouveau et n’est pas encore largement utilisé, mais que le chemin de remontée d’informations basé sur le principal du service l’est. « Environ 99 % des locataires ont au moins un principal de service privilégié (pas nécessairement lié à un agent) », ont-ils déclaré. Parmi eux, plus de la moitié utilisent des identités d’agent, soit en moyenne environ 100 par locataire, créant un « risque réel ».
Le Microsoft Security Response Center (MSRC) a déclaré à Silverfort qu’un correctif interne avait été entièrement déployé le 9 avril 2026, ne nécessitant aucune autre action de l’utilisateur. Les chercheurs ont tout de même publié quelques recommandations ainsi que des étapes de détection pour aider les utilisateurs à identifier et à répondre à des modèles similaires.
