Révélé à l’occasion de travaux pour une conférence, le problème associait un ancien service d’authentification et une API en fin de vie. Une combinaison qui, avant correction, offrait un terrain d’attaque inédit dans les annuaires Microsoft.
Le chercheur en sécurité Dirk-jan Mollema a découvert une faille majeure, capable d’octroyer les pleins pouvoirs dans n’importe quel tenant Entra ID, le service d’identité et d’accès qui sous-tend Microsoft 365, Azure et une multitude d’applications SaaS. En combinant un jeton hérité et une API vieillissante, il aurait pu usurper n’importe quel compte, y compris ceux dotés des privilèges les plus élevés, dans la quasi-totalité des organisations à travers le monde s’appuyant sur ce système d’authentification. Microsoft a réagi rapidement et publié un correctif mi-juillet côté serveur, mais cet épisode rappelle combien la négligence vis-à-vis de composants anciens ou oubliés peut fragiliser l’ensemble des infrastructures de sécurité.
Offre partenaire
Protection avancée des e-mails, des calendriers, des mots de passe, du réseau… de votre entreprise grâce à la suite d'applications professionnelles sécurisées.
Offre partenaire
Un enchaînement muet, mais lourd de conséquences
Comme souvent dans ce type d’affaire, la découverte de cette vulnérabilité relève presque du hasard. En préparant ses interventions pour la Black Hat et la DEF CON, Mollema a identifié un lien inattendu entre les « actor tokens », émis par le service hérité Access Control Service et encore utilisés en interne par Microsoft et par Exchange pour certaines communications, et un défaut de validation dans l’API Azure AD Graph.
Pour rappel, ces jetons, valables vingt-quatre heures et signés lors de leur création, permettent ensuite à certains services Microsoft de forger des jetons non signés, un point d’autant plus problématique que leur émission n’est pas consignée et que leur usage via Azure AD Graph n’apparaît pas dans les journaux d’activité.
Plus grave encore, en combinant ces éléments, le chercheur a démontré qu’un token obtenu dans son propre tenant pouvait être accepté dans n’importe quel autre, à condition de connaître son ID public et le numéro interne de l’utilisateur (netId). Un enchaînement qui permettait alors d’usurper n’importe quel compte (hors clouds nationaux), y compris celui d’un administrateur général, puis de créer ou modifier d’autres comptes, d’accorder des privilèges, d’ajuster les paramètres du tenant ou de prendre la main sur les services connectés à Entra ID sans faire de bruit, seules les opérations modifiant le répertoire pouvant laisser quelques entrées ambiguës dans les journaux d’activité.
Tirer les leçons d’un héritage encombrant
Signalée à Microsoft le 14 juillet 2025, la faille a été corrigée côté serveur trois jours plus tard. Des mesures supplémentaires ont suivi début août pour restreindre l’usage de ces jetons avec Azure AD Graph, et Redmond a officiellement documenté la vulnérabilité le 4 septembre sous l’identifiant CVE-2025-55241.
Malgré tout, l’existence d’une telle vulnérabilité souligne l’importance de maîtriser l’héritage technique dans les environnements cloud. Par conséquent, si vous êtes admin, vérifiez que vos applications et scripts n’utilisent plus d’API dépréciées, notamment Azure AD Graph, et migrez vers Microsoft Graph dès que possible.
Réduisez aussi le périmètre des privilèges élevés : limitez le nombre de comptes Global Admin, privilégiez des rôles plus fins et n’accordez les droits étendus que pour la durée strictement nécessaire. Surveillez régulièrement l’activité inscrite dans les journaux, en couvrant spécifiquement la période précédant le 17 juillet 2025 et jusqu’aux mesures complémentaires du 6 août, et ciblez en priorité les modifications pour lesquelles l’initiateur apparaît comme un service Microsoft (par exemple Office 365 Exchange Online, SharePoint Online, Skype for Business Online, Dataverse, Microsoft Dynamics ERP) lié à l'UPN d’un admin. Pensez également à nettoyer les comptes et services hérités (anciens SPN, applications inutilisées, comptes invités inactifs) afin qu’aucun composant oublié ne devienne un point d’entrée, et appliquez sans délai les correctifs publiés par Microsoft.
Enfin, gardez un œil sur la mise hors service des composants anciens, comme l’Access Control Service ou d’autres technos internes dépréciées, pour ne plus dépendre d’éléments dont la sécurité n’est plus garantie.
Source : Dirk-jan Mollema,
