Les vulnérabilités d'Entra ID de Microsoft auraient pu avoir des conséquences catastrophiques et permettre à des pirates d'accéder à pratiquement tous les comptes clients Azure Cloud.Une faille critique d'Azure Entra ID met en évidence les problèmes d'IAM de Microsoft. Bien que la vulnérabilité du cloud ait été corrigée avant sa divulgation, le chercheur qui l'a découverte affirme qu'elle aurait pu conduire à des attaques catastrophiques, ce qui a alarmé certains membres de la communauté de la sécurité.
Microsoft Entra ID (anciennement Microsoft Azure Active Directory ou Azure AD) est une solution de gestion des identités et des accès (IAM) basée sur le cloud. Il s'agit d'un service de gestion des répertoires et des identités qui fonctionne dans le cloud et offre des services d'authentification et d'autorisation à divers services Microsoft, tels que Microsoft 365, Dynamics 365, Microsoft Azure et des services tiers.
Entra ID propose différentes méthodes d'authentification, notamment l'authentification par mot de passe, l'authentification multifactorielle, l'authentification par carte à puce et l'authentification par certificat. Il comprend également plusieurs fonctionnalités de sécurité, telles que des politiques d'accès conditionnel, l'authentification basée sur les risques et la protection de l'identité.
En 2024, Microsoft a été au cœur d'une polémique concernant la perte de plus de deux semaines de journaux de sécurité pour certains de ses produits cloud. Cet incident, qui s'est produit entre le 2 et le 19 septembre 2024, a été attribué à un bogue dans l'un des agents de surveillance internes de l'entreprise. Ce problème a empêché l'envoi des données de journal vers la plateforme de journalisation interne de Microsoft, laissant les défenseurs des réseaux sans données cruciales pour détecter d'éventuelles intrusions.
Récemment, une vulnérabilité critique de l'authentification Microsoft aurait pu permettre à un acteur malveillant de compromettre pratiquement tous les locataires Entra ID dans le monde. La vulnérabilité d'élévation de privilèges (EoP), référencée sous le numéro CVE-2025-55241, a été corrigée au cours de l'été et divulguée au début du mois, mais rien n'indique que cette faille, qui avait initialement reçu une note CVSS de 9,0 avant d'être reclassée à 10,0, ait été exploitée dans la nature. Cela dit, selon le chercheur qui a découvert la faille, cette vulnérabilité aurait pu être utilisée pour mener des attaques dévastatrices et met en évidence un manque de sécurité autour des composants clés de la pile d'authentification d'Azure.
Selon Dirk-jan Mollema, chercheur en sécurité et fondateur du cabinet de conseil néerlandais Outsider Security, la vulnérabilité provient d'une défaillance d'authentification dans l'API Azure AD Graph. Ce service, dont la suppression est prévue cette année, est une API REST qui permet aux utilisateurs d'accéder aux ressources cloud Azure, notamment Entra ID (anciennement Azure Active Directory ou Azure AD).
Selon Mollema, cette défaillance d'authentification permet à des utilisateurs non autorisés de tirer parti d'un autre problème de sécurité qu'il a découvert, appelé « Actor tokens ». Ces jetons non documentés, conçus pour les communications de service à service en arrière-plan, ne sont pas soumis à des politiques de contrôle d'accès et, surtout, peuvent être utilisés pour élever des privilèges.
Mollema a découvert que la vulnérabilité d'authentification dans l'API Azure AD Graph pouvait créer des jetons d'usurpation d'identité et les utiliser pour un accès inter-locataires. « Concrètement, cela signifie qu'avec un jeton que j'ai demandé dans mon locataire de laboratoire, je pouvais m'authentifier en tant que n'importe quel utilisateur, y compris les administrateurs globaux, dans n'importe quel autre locataire ».
Mollema a découvert cette faille en juillet alors qu'il préparait sa présentation pour les conférences Black Hat USA 2025 et DEF CON 33 à Las Vegas, intitulée « Advanced Active Directory to Entra ID Lateral Movement Techniques » (Techniques avancées de déplacement latéral d'Active Directory vers Entra ID). La présentation détaillait en partie comment les acteurs malveillants peuvent abuser des jetons Actor non signés, qui sont générés par ce qu'il considère comme un service hérité appelé « Access Control Service » (service de contrôle d'accès).
Les jetons d'authentification non signés sont particulièrement dangereux en soi, mais Mollema a constaté que le jeton Actor présentait un risque encore plus grand car il « manque de presque tous les contrôles de sécurité que l'on pourrait souhaiter ». Par exemple, ils ne peuvent pas être révoqués pendant leur durée de vie de 24 heures, ils contournent les politiques d'accès conditionnel et leur visibilité est extrêmement limitée.
« La demande de jetons Actor ne génère pas de journaux », a écrit Mollema. « Même si c'était le cas, ils seraient générés dans mon locataire plutôt que dans celui de la victime, ce qui signifie qu'il n'y a aucune trace de l'existence de ces jetons. » Lorsqu'il a testé les jetons Actor, il a modifié certains de leurs champs pour voir s'ils fonctionnaient toujours. Dans un test, il a changé l'ID du locataire du jeton pour quelque chose de complètement différent : un locataire de son compte de test.
Lorsqu'il a essayé d'accéder au nouveau locataire via Azure AD Graph, Mollema a reçu un message d'erreur indiquant que le jeton Actor était valide, mais que l'identité de l'utilisateur était introuvable dans le locataire. Il a alors trouvé un netID (c'est-à-dire un identifiant utilisateur pour Azure AD Graph) pour le nouveau locataire et découvert que son accès était autorisé. « J'ai testé cela sur quelques autres locataires test auxquels j'avais accès, pour m'assurer que je n'étais pas fou, mais je pouvais effectivement accéder aux données d'autres locataires, à condition de connaître leur identifiant de locataire (qui est une information publique) et l'identifiant réseau d'un utilisateur de ce locataire », a-t-il écrit.
Bien que les identifiants réseau ne soient pas publics, Mollema a découvert que les identifiants utilisateur sont générés de manière incrémentielle et sont donc vulnérables aux attaques par force brute. De plus, Mollema a découvert qu'en modifiant les jetons Actor et en devinant l'identifiant netID d'un administrateur global, il pouvait obtenir un accès illimité à ce locataire, sans laisser aucune trace dans les journaux. « Sans l'absence totale de mesures de sécurité dans ces jetons, je ne pense pas qu'un impact aussi important avec une télémétrie aussi limitée aurait été possible », a-t-il écrit.
Mollema explique que, bien que l'API Azure AD Graph soit prévue pour être retirée cette année, de nombreuses applications Microsoft l'utilisent encore. « Je ne pense pas que le plan de retrait ait eu un impact sur la vulnérabilité, mais une API en voie de disparition n'est pas susceptible de bénéficier d'une attention particulière de la part des ingénieurs pour « moderniser » le code et/ou l'authentification », dit-il.
Si l'échec de l'authentification avec Azure AD Graph permet l'accès inter-locataires, Mollema estime que le problème le plus important concerne les jetons Actor, qui, selon lui, n'auraient jamais dû exister. Il existe un flux de jetons OAuth conçu pour empêcher ce type de scénarios d'usurpation d'identité, mais il n'a pas été suivi, explique-t-il. « Dans ce flux, le fournisseur d'identité émet un jeton signé, qui ne peut donc pas être modifié. Cela signifie également que des journaux sont générés lorsque ces jetons sont émis, ce qui nous permet d'avoir au moins un certain niveau d'audit », explique Mollema. « À mon avis, ce sont là des propriétés importantes qui devraient être mises en place dans un protocole d'usurpation d'identité. »
Les recherches de Mollema ont, à juste titre, alarmé de nombreux membres de la communauté de la sécurité de l'information. Dans un message publié sur la plateforme de réseau social X, Heather Adkins, vice-présidente de l'ingénierie de sécurité chez Google, a déclaré qu'il s'agissait de « l'une des pires vulnérabilités que j'ai jamais vues ».
Cette vulnérabilité a également ravivé les critiques à l'égard de la sécurité de Microsoft, en particulier en ce qui concerne la gestion des identités et des accès (IAM) Azure. « Nous avons besoin d'un autre CSRB [Cyber Safety Review Board] pour garantir que msft [sic] détruise complètement ce mécanisme de jetons d'usurpation d'identité », a déclaré Michael Bargury, directeur technique (CTO) chez Zenity, dans un message publié sur X.
En 2024, le CSRB du département de la Sécurité intérieure a publié un rapport accablant sur Microsoft à la suite d'une violation massive commise par un acteur malveillant chinois identifié sous le nom de Storm-0558. Le rapport du CSRB, aujourd'hui dissous, critiquait de nombreux aspects de la posture de sécurité de Microsoft, en particulier pour ses services cloud, et qualifiait la culture de sécurité de l'entreprise d'« inadéquate » et nécessitant une refonte.
En outre, ce rapport cinglant révélait que Microsoft n'avait toujours pas déterminé comment Storm-0558 avait volé une clé de signature de compte Microsoft (MSA) grand public, que les pirates avaient utilisée pour pirater les comptes de messagerie de plus de 20 organisations clientes. Le CRSB critiquait également l'entreprise pour avoir attendu plusieurs mois avant de corriger un article de blog publié précédemment, qui affirmait que les pirates avaient volé la clé sur le réseau de Microsoft après qu'elle ait été incluse par erreur dans un vidage sur incident.
Cela rappelle qu'en janvier dernier, Microsoft a poursuivi des pirates informatiques pour avoir exploité des services d'intelligence artificielle (IA) à l'aide d'identifiants Azure volés. Le groupe aurait contourné les contrôles de sécurité dans des services comme Azure OpenAI pour générer du contenu nuisible, monétiser l'accès et distribuer des outils à d'autres cybercriminels. Microsoft a décrit les actions du groupe comme faisant partie d'une vaste "entreprise d'abus d'Azure", mettant en évidence un modèle coordonné et persistant d'activité illégale.
Mollema affirme que d'après ce qu'il a pu observer depuis la publication du rapport du CSRB, Microsoft « travaille d'arrache-pied pour améliorer la sécurité de sa plateforme et de ses systèmes ». Le géant du logiciel a annoncé en 2024 son initiative Secure Future Initiative (SFI) afin de remédier aux problèmes détaillés dans le rapport, et a pris plusieurs mesures pour améliorer ses pratiques et son dispositif de sécurité.
Mollema a également salué la réponse rapide et complète de Microsoft à son rapport sur la vulnérabilité, notamment une mesure d'atténuation supplémentaire mise en place par l'entreprise à la suite de ses sessions Black Hat et DEF CON. « Grâce à cette mesure d'atténuation supplémentaire, Microsoft a complètement bloqué la possibilité pour les clients de demander ces jetons d'acteur pour Azure AD Graph, ce qui signifie que s'il y avait une faille de validation inter-locataires similaire dans cette API, il ne serait pas possible d'en abuser puisque même la demande de jetons au sein d'un locataire est désormais bloquée, ce qui en fait une bonne mesure d'atténuation en profondeur », explique-t-il.
Cependant, Mollema dit qu'il a encore des inquiétudes. « Étant donné que les protocoles utilisés dans cette faille remontent probablement aux tout débuts d'Azure/Entra ID, je pense qu'il s'agit davantage d'une mauvaise décision de sécurité prise dans le passé et ayant un impact important sur le présent que d'un problème récent », explique-t-il. « Je suis plus préoccupé par le manque de transparence concernant les protocoles et les processus utilisés en interne par Microsoft, qui ne sont pas accessibles aux chercheurs externes pour qu'ils puissent les évaluer ou y trouver des failles. »
Face à cette nouvelle découverte, Tom Gallagher, vice-président de l'ingénierie au Microsoft Security Response Center, a commenté : « Nous apprécions le travail de Dirk-Jan Mollema, d'Outsider Security, qui a identifié et signalé de manière responsable cette vulnérabilité dans le cadre d'une divulgation coordonnée. Nous avons rapidement atténué le problème nouvellement identifié et accéléré les travaux de correction en cours pour mettre hors service l'utilisation de ce protocole hérité, dans le cadre de notre initiative Secure Future Initiative (SFI).
Nous avons mis en œuvre une modification du code dans la logique de validation vulnérable, testé le correctif et l'avons appliqué à l'ensemble de notre écosystème cloud. Nous n'avons trouvé aucune preuve d'abus de cette vulnérabilité et, afin de maintenir la transparence, nous avons publié un CVE-2025-55241 sans action. Nous restons déterminés à renforcer nos normes d'identité, à encourager leur adoption grâce à l'utilisation de SDK standard dans 100 % des applications, tout en poursuivant notre collaboration avec la communauté afin d'identifier et de corriger les vulnérabilités de manière responsable, améliorant ainsi la sécurité pour tous ».
Voici un extrait du rapport de Dirk-jan Mollema :
Un seul jeton pour tous les contrôler : obtenir les droits d'administrateur global dans chaque tenant Entra ID via les jetons Actor.
Alors que je préparais mes interventions pour les conférences Black Hat et DEF CON en juillet dernier, j'ai découvert la vulnérabilité Entra ID la plus grave que j'ai jamais rencontrée. Cette vulnérabilité m'aurait permis de compromettre tous les locataires Entra ID dans le monde (à l'exception probablement de ceux utilisant des déploiements cloud nationaux1). Si vous êtes un administrateur Entra ID et que vous lisez ceci, oui, cela signifie un accès complet à votre locataire. La vulnérabilité comprenait deux composants : des jetons d'usurpation d'identité non documentés, appelés « jetons d'acteur », que Microsoft utilise dans son backend pour la communication de service à service (S2S). De plus, il y avait une faille critique dans l'API Azure AD Graph (héritée) qui ne validait pas correctement le locataire d'origine, permettant à ces jetons d'être utilisés pour un accès inter-locataires.
Concrètement, cela signifie qu'avec un jeton que j'ai demandé dans mon locataire de laboratoire, je pouvais m'authentifier en tant que n'importe quel utilisateur, y compris les administrateurs globaux, dans n'importe quel autre locataire. En raison de la nature de ces jetons d'acteur, ils ne sont pas soumis à des politiques de sécurité telles que l'accès conditionnel, ce qui signifie qu'aucun paramètre n'aurait pu atténuer ce problème pour des locataires spécifiques renforcés. L'API Azure AD Graph étant une API plus ancienne permettant de gérer le service Azure AD / Entra ID de base, l'accès à cette API aurait pu être utilisé pour apporter toute modification au locataire que les administrateurs généraux peuvent effectuer, y compris la prise de contrôle ou la création de nouvelles identités et l'octroi de toute autorisation dans le locataire. Avec ces identités compromises, l'accès pouvait également être étendu à Microsoft 365 et Azure.
J'ai signalé cette vulnérabilité le jour même au Microsoft Security Response Center (MSRC). Microsoft a corrigé cette vulnérabilité de son côté dans les jours qui ont suivi la soumission du rapport et a déployé d'autres mesures d'atténuation qui empêchent les applications de demander ces jetons d'acteur pour l'API Azure AD Graph. Microsoft a également publié le CVE-2025-55241 pour cette vulnérabilité.
Impact
Ces jetons permettaient un accès complet à l'API Azure AD Graph dans n'importe quel locataire. La demande de jetons d'acteur ne génère pas de journaux. Même si c'était le cas, ils seraient générés dans mon locataire plutôt que dans le locataire victime, ce qui signifie qu'il n'y a aucune trace de l'existence de ces jetons.
De plus, l'API Azure AD Graph ne dispose pas de journalisation au niveau de l'API. Son successeur, Microsoft Graph, dispose de cette journalisation, mais pour Azure AD Graph, cette source de télémétrie est encore en phase de prévisualisation très limitée et je ne connais aucun locataire qui en dispose actuellement. Comme il n'y a pas de journalisation au niveau de l'API, cela signifie que les données Entra ID suivantes pourraient être consultées sans laisser de traces :
Ces informations pourraient être consultées en se faisant passer pour un utilisateur régulier du locataire victime. Si vous souhaitez connaître l'impact total, mon outil roadrecon utilise la même API. Si vous l'exécutez, tout ce que vous trouvez dans l'interface graphique de l'outil pourrait avoir été consulté et modifié par un attaquant abusant de cette faille.
Si un administrateur global était usurpé, il serait également possible de modifier n'importe lequel des objets et paramètres ci-dessus. Cela entraînerait une compromission totale du locataire avec un accès à tous les services qui utilisent Entra ID pour l'authentification, tels que SharePoint Online et Exchange Online. Cela donnerait également un accès complet à toutes les ressources hébergées dans Azure, car ces ressources sont contrôlées au niveau du locataire et les administrateurs globaux peuvent s'octroyer des droits sur les abonnements Azure. La modification d'objets dans le locataire entraîne (généralement) la génération de journaux d'audit. Cela signifie que, même si, en théorie, toutes les données de Microsoft 365 auraient pu être compromises, toute action autre que la lecture des informations du répertoire laisserait des journaux d'audit susceptibles d'alerter les défenseurs. Cependant, sans connaissance des artefacts spécifiques générés par les modifications avec ces jetons d'acteur, il semblerait qu'un administrateur global légitime ait effectué ces actions.
D'après la télémétrie interne de Microsoft, aucune utilisation abusive de cette vulnérabilité n'a été détectée. Si vous souhaitez rechercher d'éventuels artefacts d'abus dans votre propre environnement, une détection KQL est incluse à la fin de cet article.
Alors que je préparais mes interventions pour les conférences Black Hat et DEF CON en juillet dernier, j'ai découvert la vulnérabilité Entra ID la plus grave que j'ai jamais rencontrée. Cette vulnérabilité m'aurait permis de compromettre tous les locataires Entra ID dans le monde (à l'exception probablement de ceux utilisant des déploiements cloud nationaux1). Si vous êtes un administrateur Entra ID et que vous lisez ceci, oui, cela signifie un accès complet à votre locataire. La vulnérabilité comprenait deux composants : des jetons d'usurpation d'identité non documentés, appelés « jetons d'acteur », que Microsoft utilise dans son backend pour la communication de service à service (S2S). De plus, il y avait une faille critique dans l'API Azure AD Graph (héritée) qui ne validait pas correctement le locataire d'origine, permettant à ces jetons d'être utilisés pour un accès inter-locataires.
Concrètement, cela signifie qu'avec un jeton que j'ai demandé dans mon locataire de laboratoire, je pouvais m'authentifier en tant que n'importe quel utilisateur, y compris les administrateurs globaux, dans n'importe quel autre locataire. En raison de la nature de ces jetons d'acteur, ils ne sont pas soumis à des politiques de sécurité telles que l'accès conditionnel, ce qui signifie qu'aucun paramètre n'aurait pu atténuer ce problème pour des locataires spécifiques renforcés. L'API Azure AD Graph étant une API plus ancienne permettant de gérer le service Azure AD / Entra ID de base, l'accès à cette API aurait pu être utilisé pour apporter toute modification au locataire que les administrateurs généraux peuvent effectuer, y compris la prise de contrôle ou la création de nouvelles identités et l'octroi de toute autorisation dans le locataire. Avec ces identités compromises, l'accès pouvait également être étendu à Microsoft 365 et Azure.
J'ai signalé cette vulnérabilité le jour même au Microsoft Security Response Center (MSRC). Microsoft a corrigé cette vulnérabilité de son côté dans les jours qui ont suivi la soumission du rapport et a déployé d'autres mesures d'atténuation qui empêchent les applications de demander ces jetons d'acteur pour l'API Azure AD Graph. Microsoft a également publié le CVE-2025-55241 pour cette vulnérabilité.
Impact
Ces jetons permettaient un accès complet à l'API Azure AD Graph dans n'importe quel locataire. La demande de jetons d'acteur ne génère pas de journaux. Même si c'était le cas, ils seraient générés dans mon locataire plutôt que dans le locataire victime, ce qui signifie qu'il n'y a aucune trace de l'existence de ces jetons.
De plus, l'API Azure AD Graph ne dispose pas de journalisation au niveau de l'API. Son successeur, Microsoft Graph, dispose de cette journalisation, mais pour Azure AD Graph, cette source de télémétrie est encore en phase de prévisualisation très limitée et je ne connais aucun locataire qui en dispose actuellement. Comme il n'y a pas de journalisation au niveau de l'API, cela signifie que les données Entra ID suivantes pourraient être consultées sans laisser de traces :
- Les informations sur les utilisateurs, y compris toutes leurs données personnelles stockées dans Entra ID.
- Informations sur les groupes et les rôles.
- Paramètres du locataire et politiques (d'accès conditionnel).
- Applications, entités de service et toute attribution d'autorisation d'application.
- Informations sur les appareils et clés BitLocker synchronisées avec Entra ID.
Ces informations pourraient être consultées en se faisant passer pour un utilisateur régulier du locataire victime. Si vous souhaitez connaître l'impact total, mon outil roadrecon utilise la même API. Si vous l'exécutez, tout ce que vous trouvez dans l'interface graphique de l'outil pourrait avoir été consulté et modifié par un attaquant abusant de cette faille.
Si un administrateur global était usurpé, il serait également possible de modifier n'importe lequel des objets et paramètres ci-dessus. Cela entraînerait une compromission totale du locataire avec un accès à tous les services qui utilisent Entra ID pour l'authentification, tels que SharePoint Online et Exchange Online. Cela donnerait également un accès complet à toutes les ressources hébergées dans Azure, car ces ressources sont contrôlées au niveau du locataire et les administrateurs globaux peuvent s'octroyer des droits sur les abonnements Azure. La modification d'objets dans le locataire entraîne (généralement) la génération de journaux d'audit. Cela signifie que, même si, en théorie, toutes les données de Microsoft 365 auraient pu être compromises, toute action autre que la lecture des informations du répertoire laisserait des journaux d'audit susceptibles d'alerter les défenseurs. Cependant, sans connaissance des artefacts spécifiques générés par les modifications avec ces jetons d'acteur, il semblerait qu'un administrateur global légitime ait effectué ces actions.
D'après la télémétrie interne de Microsoft, aucune utilisation abusive de cette vulnérabilité n'a été détectée. Si vous souhaitez rechercher d'éventuels artefacts d'abus dans votre propre environnement, une détection KQL est incluse à la fin de cet article.
Et vous ?
Pensez-vous que ce rapport est crédible ou pertinent ? Quel est votre avis sur le sujet ?Voir aussi :
Une campagne permanente compromet les comptes Azure des cadres supérieurs et les verrouille, à l'aide de l'authentification multifacteur Microsoft a déployé des puces de sécurité personnalisées sur tous les serveurs Azure Cloud afin de lutter contre une menace cybercriminelle estimée à 10 000 milliards de $ Microsoft lance une mise en garde contre "Silk Typhoon", un groupe d'espionnage chinois, qui se focalise sur les outils de gestion à distance et les applications cloud
Vous avez lu gratuitement 314 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.