CVE-2025-55241 : Entra ID usurpation de jeton acteur pouvait compromettre tout administrateur global

Qu'est-ce que CVE-2025-55241 : la faille d'usurpation par jeton Actor dans Entra ID

CVE-2025-55241 est une vulnérabilité d'élévation de privilèges dans Microsoft Entra ID, reposant sur l'usurpation par jeton Actor d'Entra ID, découverte par le chercheur en sécurité indépendant Dirk-jan Mollema et signalée au Microsoft Security Response Center (MSRC) le 14 juillet 2025. Le score CVE attribué par Microsoft lui-même était de CVSS 10.0 (Critique) ; le recalcul indépendant du NVD l'a ramené à 9.8 (Critique), avec une classification CWE-287 (authentification incorrecte). Microsoft a attribué le CVE le 4 septembre 2025 et a indiqué qu'aucune action cliente n'était requise, le correctif ayant déjà été déployé sur l'ensemble des tenants.

La faille combinait deux éléments : un type de jeton interne à Microsoft, non documenté, appelé « jeton Actor », et une lacune de validation du tenant dans l'API Azure AD Graph héritée (graph.windows.net). Combinés, ils permettaient au détenteur d'un jeton Actor issu de son propre tenant (contrôlé par l'attaquant) de s'authentifier comme n'importe quel utilisateur — y compris des administrateurs globaux — dans n'importe quel autre tenant Entra ID, sans avoir besoin des identifiants de cet utilisateur, sans déclencher le MFA, et sans générer la trace d'audit sur laquelle les défenseurs comptent habituellement. Mollema a décrit cette exposition comme capable de compromettre « tous les tenants Entra ID au monde », à l'exception des clouds nationaux/souverains.

🚨 Danger : selon Microsoft et Mollema, aucune preuve d'exploitation active n'a été observée. Il s'agit d'une explication rétrospective d'une vulnérabilité déjà corrigée globalement par Microsoft — pas d'une menace active nécessitant une action d'urgence aujourd'hui.

Chronologie de la divulgation

• 14 juillet 2025 — Mollema signale le problème au MSRC ; le MSRC ouvre un dossier le jour même.
• 17 juillet 2025 — Microsoft déploie en production un correctif pour la lacune de validation du tenant dans l'API Azure AD Graph.
• 23 juillet 2025 — Le MSRC confirme à Mollema que le problème principal est résolu.
• 6 août 2025 — Microsoft déploie des mesures d'atténuation supplémentaires restreignant l'émission de jetons Actor pour l'API Azure AD Graph aux seuls services internes de Microsoft.
• 4 septembre 2025 — Microsoft attribue formellement le CVE-2025-55241 et indique qu'aucune action cliente n'est requise.
• 17 septembre 2025 — Mollema publie l'analyse technique complète, avec des recommandations de détection.

Comment fonctionnait le contournement par jeton Actor

Les jetons Actor sont émis par l'Access Control Service (ACS) de Microsoft pour la délégation service à service — le mécanisme qui permet à des backends internes à Microsoft comme Exchange Online d'« agir en tant que » un utilisateur lors d'appels à d'autres services Microsoft pour le compte de cet utilisateur. Selon l'analyse de Mollema, les jetons Actor portent une revendication (claim) trustedfordelegation et, une fois émis, permettent effectivement d'usurper l'identité de n'importe quel utilisateur d'un tenant pendant une durée pouvant aller jusqu'à 24 heures. Il s'agit d'un mécanisme interne légitime et ancien — la vulnérabilité résidait dans la façon dont un consommateur hérité de ces jetons les validait, et non dans l'existence même du mécanisme.

Deux lacunes de conception rendaient cette faille exploitable au-delà des frontières d'un tenant :

Origine du tenant non validée

L'API Azure AD Graph héritée ne vérifiait pas correctement que l'ID de tenant intégré dans les revendications d'usurpation d'un jeton Actor correspondait au tenant réellement interrogé. Comme la charge utile d'usurpation était transportée dans un JWT non signé, un attaquant pouvait substituer l'ID de son propre tenant par celui d'un tenant cible sans invalider la signature du jeton — puisqu'il n'y en avait pas à casser. Cela permettait de rejouer un jeton émis pour le tenant de l'attaquant comme s'il provenait de n'importe quel autre tenant sur Terre.

Identifiants utilisateur prévisibles (netId)

La cible de l'usurpation au sein du tenant de destination était résolue via netId, un identifiant hérité de Microsoft Passport encore présent dans certains rouages internes d'Entra. Contrairement à un ID d'objet Entra (un GUID aléatoire), les valeurs netId s'incrémentent de façon prévisible. Mollema a constaté qu'elles pouvaient être forcées par force brute en « quelques minutes à quelques heures » pour un tenant cible, et pouvaient également être récupérées directement dans les attributs alternativeSecurityIds des utilisateurs invités dans des relations d'approbation B2B, ou dans des jetons ayant fuité via des journaux, des tickets de support et des captures d'écran publiques.

En résumé : un attaquant capable de demander un jeton Actor depuis n'importe quel tenant qu'il contrôlait — y compris un tenant gratuit ou d'essai — pouvait réécrire l'ID du tenant cible et l'associer à un netId résolu, et l'API Azure AD Graph héritée honorait l'usurpation qui en résultait. Cela donnait un accès en lecture et en écriture aux données d'annuaire, la possibilité de créer des principaux de service, de modifier des attributions de rôles et de modifier des stratégies d'accès conditionnel en tant que n'importe quel utilisateur revendiqué par le jeton, jusqu'à un administrateur global inclus.

Pourquoi le MFA, l'accès conditionnel et la journalisation ne pouvaient pas détecter la faille

C'est ce qui rendait cette faille critique et non simplement sérieuse : le contournement opérait sous les contrôles sur lesquels les tenants s'appuient pour détecter une compromission de compte.

• Le MFA et l'accès conditionnel ne s'appliquent pas. Les jetons Actor relèvent d'un mécanisme de délégation service à service, pas d'une connexion interactive — ils ne passent absolument pas par le moteur de stratégies d'accès conditionnel, si bien que le MFA par utilisateur, le risque de connexion et les exigences de conformité des appareils ne sont tout simplement pas évalués. Un rappel que le MFA seul n'a jamais constitué un contrôle complet — il ne couvre que les chemins d'authentification auxquels il est réellement rattaché.
• Demander le jeton ne génère aucun journal. Selon l'analyse de Mollema, l'obtention d'un jeton Actor ne produit aucune entrée de journal visible côté tenant — un attaquant pouvait préparer l'attaque sans laisser la moindre trace dans le tenant cible.
• L'API Graph héritée journalise insuffisamment. graph.windows.net est antérieure à la profondeur de journalisation offerte par Microsoft Graph et le pipeline d'audit moderne d'Entra, si bien que même les actions effectuées avec le jeton d'usurpation n'étaient que partiellement capturées.
• Le jeton était en pratique impossible à révoquer pendant sa validité. En tant que JWT autonome et non signé, valide jusqu'à 24 heures, un jeton Actor divulgué ou forgé ne pouvait pas être invalidé en cours de route, contrairement à un jeton de session compromis.

Détection : que rechercher

Le correctif de Microsoft ayant fermé le chemin d'accès sous-jacent, la détection ici est rétrospective — passer en revue l'historique d'audit Entra à la recherche de signes indiquant que la technique a été utilisée contre votre tenant avant le correctif — plutôt qu'un contrôle de surveillance en continu. Mollema a publié une requête KQL exactement pour cela : les modifications pilotées par jeton Actor apparaissent toujours dans AuditLogs, mais avec une incohérence révélatrice entre le nom d'affichage du service agissant et le contexte d'origine réel.

AuditLogs
| where not(OperationName has "group")
| where not(OperationName == "Set directory feature on tenant")
| where InitiatedBy has "user"
| where InitiatedBy.user.displayName has_any (
    "Office 365 Exchange Online", "Skype for Business Online", "Dataverse",
    "Office 365 SharePoint Online", "Microsoft Dynamics ERP")

Ce que la requête ne détecte pas

Cette requête, adaptée de l'analyse publiée par Mollema, signale les modifications d'annuaire effectuées via l'usurpation par jeton Actor. Elle ne détecte pas la reconnaissance en lecture seule — énumération d'utilisateurs ou de groupes, collecte de secrets, consultation de stratégies — que l'API héritée ne journalisait pas avec suffisamment de détail pour être reconstituée a posteriori. Considérez un résultat vide de cette requête comme la preuve qu'aucune activité d'écriture n'est passée par ce chemin, pas comme la preuve que le tenant n'a jamais été lu.

Remédiation

Le correctif de Microsoft lui-même ne nécessitait aucune action côté client : le MSRC a confirmé que le problème de validation du tenant était résolu le 23 juillet 2025, et au 6 août 2025 a encore restreint l'émission de jetons Actor pour l'API Azure AD Graph aux seuls services internes de Microsoft. Cela referme cette chaîne spécifique. La remédiation durable pour les tenants consiste à réduire la dépendance à la surface héritée et aux schémas de privilèges exploités par cette faille :

1. Éliminez les dépendances à Azure AD Graph. Passez en revue vos inscriptions d'application et principaux de service pour identifier ceux qui appellent encore Azure AD Graph, et migrez-les vers Microsoft Graph ; chaque dépendance supprimée est une surface en moins exposée au prochain bug de validation d'une API héritée.
2. Éliminez les attributions permanentes d'administrateur global. Le pire scénario de cette faille était une usurpation complète d'un administrateur global. Faire basculer les rôles d'administration vers une activation juste-à-temps via Privileged Identity Management (PIM) réduit le nombre de comptes qu'une usurpation réussie pourrait réellement exploiter de façon significative.
3. Exigez un MFA résistant au phishing sur chaque rôle privilégié, pas seulement sur la connexion interactive en général — cela n'arrête pas un contournement par jeton service à service comme les jetons Actor, mais cela referme le chemin bien plus courant que les attaquants utilisent réellement pour atteindre les comptes admin.
4. Bloquez l'authentification héritée à l'échelle du tenant via l'accès conditionnel. L'authentification héritée ne prend en charge ni la validation moderne des jetons ni l'application de l'accès conditionnel, et les tenants qui autorisent encore l'authentification héritée ou laissent des failles d'accès conditionnel ouvertes élargissent la même catégorie d'exposition qui a rendu cette vulnérabilité si sévère : des chemins d'authentification invisibles pour le plan de contrôle moderne.
5. Revoyez la rétention et les alertes sur AuditLogs Entra pour le schéma d'initiateur anormal décrit ci-dessus, afin que tout futur contournement par usurpation d'un service interne déclenche une alerte plutôt qu'un silence. Un audit de sécurité Entra ID plus large couvre ce point avec le reste de la posture de votre tenant, y compris les paramètres par défaut livrés avec les nouveaux tenants.

Pourquoi l'API héritée comptait au-delà de ce CVE

Microsoft retire progressivement graph.windows.net depuis l'annonce de dépréciation de 2019 : les nouvelles applications ont été bloquées dès leur première utilisation à compter du 31 août 2024, et un opt-in pour l'accès étendu est exigé à l'échelle du tenant depuis le 1er février 2025, les applications n'y adhérant pas perdant purement et simplement l'accès. Microsoft a clairement indiqué ne plus investir dans Azure AD Graph au-delà des correctifs de sécurité, et que toute nouvelle fonctionnalité va désormais à Microsoft Graph. CVE-2025-55241 illustre concrètement pourquoi cette migration compte au-delà d'une simple case de conformité à cocher : une surface d'API dépréciée, sous-journalisée et sous-maintenue est exactement l'endroit où une lacune de validation comme celle-ci passe inaperçue le plus longtemps.

Comment EtcSec détecte cela

L'audit Entra ID d'EtcSec n'a aucune visibilité sur la plomberie interne des jetons Actor de Microsoft — ce plan de contrôle se trouve entièrement au sein de l'infrastructure de Microsoft et n'a jamais été quelque chose qu'un audit côté tenant pouvait observer ou corriger directement. Ce qu'EtcSec vérifie en continu, c'est l'ensemble des conditions côté tenant qui déterminent l'ampleur des dégâts que tout contournement de type usurpation (celui-ci ou le prochain) peut causer : les attributions permanentes d'administrateur global (PA_TOO_MANY_GLOBAL_ADMINS, PA_PERMANENT_ADMIN_ASSIGNMENTS), les comptes admin sans MFA fort (PA_GLOBAL_ADMIN_NOT_MFA), et les tenants qui autorisent encore des chemins d'authentification hérités en dehors de l'application de l'accès conditionnel (CA_NO_LEGACY_AUTH_BLOCK).