L'escalade de privilèges dans Microsoft Entra ID (anciennement Azure AD) est l'un des chemins d'attaque les plus sous-estimés dans les environnements cloud hybrides. La plupart des équipes IT ont une idée assez précise de qui détient le rôle Global Administrator — mais beaucoup ignorent que plusieurs rôles en apparence mineurs permettent d'y arriver en deux ou trois étapes bien enchaînées. Ce n'est pas un scénario théorique : c'est la réalité de la plupart des tenants mal configurés.
Pourquoi Entra ID est un terrain fertile pour l'escalade de privilèges
Entra ID propose plus d'une centaine de rôles intégrés. La tentation est forte de les distribuer généreusement, sous prétexte qu'ils paraissent spécialisés. Mais le modèle de permissions de Microsoft repose sur des délégations imbriquées, et certains rôles donnent accès à des primitives très puissantes — modification de credentials d'applications, réinitialisation de mots de passe, gestion de l'authentification MFA — sans que cela soit rendu visible dans le libellé du rôle.
Le résultat : un attaquant qui compromet un compte avec un rôle intermédiaire dispose souvent d'un tremplin direct vers le contrôle total du tenant.
Les chemins d'escalade les plus exploitables
Application Administrator : une porte dérobée vers n'importe quel Service Principal
Le rôle Application Administrator permet d'ajouter des credentials (secrets ou certificats) à n'importe quelle application enregistrée dans le tenant — y compris celles qui disposent de permissions Microsoft Graph privilégiées, comme RoleManagement.ReadWrite.Directory. En pratique, si une application existante possède déjà ce type de permission consentie, un attaquant avec ce rôle peut créer un nouveau secret sur cette application, s'authentifier en son nom, puis appeler l'API Graph pour s'attribuer le rôle Global Administrator.
La chaîne est courte : Application Administrator → ajout de credentials sur une app privilegiée → appel API → Global Admin. Elle ne nécessite aucun exploit, seulement des appels API légitimes.
Helpdesk Administrator : réinitialisation de MFA et prise de contrôle de compte
Le rôle Helpdesk Administrator autorise la réinitialisation des méthodes d'authentification des utilisateurs qui ne sont pas administrateurs globaux. L'abus consiste à cibler un compte disposant d'un rôle plus élevé (par exemple Privileged Role Administrator), à réinitialiser ses méthodes MFA, puis à prendre le contrôle de la session. Ce chemin est conditionné par le fait que la cible ne soit pas Global Admin — mais des rôles comme Authentication Administrator, Exchange Administrator ou Security Administrator restent accessibles.
Combiner deux rôles pour franchir les barrières
Certains chemins nécessitent la combinaison de deux rôles apparemment inoffensifs. Un compte cumulant Application Administrator et Cloud Application Administrator peut, selon la configuration du tenant, accéder à des périmètres qu'aucun des deux rôles ne couvrirait seul. De même, un Groups Administrator avec la capacité de s'ajouter à des groupes assignés à des rôles élevés crée un chemin indirect vers l'élévation. Cette logique de graphe de permissions est précisément ce que BloodHound for Azure modélise.
Méthodologie d'audit avec AzureHound et BloodHound
Collecte des données avec AzureHound
AzureHound est le collecteur dédié à Entra ID et aux ressources Azure. Il s'authentifie via un Service Principal ou un compte utilisateur et récupère les entités du tenant : utilisateurs, groupes, rôles, applications, Service Principals, et leurs relations. La commande de base ressemble à ceci :
azurehound -u [email protected] -p PASSWORD list --tenant <TENANT_ID> -o output.json
Il est recommandé d'utiliser un compte en lecture seule avec les permissions minimales nécessaires (Directory.Read.All au niveau Graph) pour limiter l'empreinte de l'audit. La collecte produit un fichier JSON ingérable directement dans BloodHound.
Analyse des chemins dans BloodHound
Une fois les données importées, BloodHound Community Edition ou la version Enterprise permet d'exécuter des requêtes Cypher pour identifier les chemins d'escalade. Quelques requêtes particulièrement utiles :
- Trouver tous les principals ayant un chemin vers Global Administrator :
MATCH p=shortestPath((n)-[*1..]->(m:AZRole {name:'Global Administrator'})) RETURN p - Lister les applications avec des permissions Graph sensibles auxquelles un Application Administrator pourrait ajouter des credentials.
- Identifier les comptes sans MFA ciblables par un Helpdesk Administrator.
L'interface graphique permet ensuite de visualiser ces chemins, de les prioriser par longueur et par criticité, et de produire un rapport exploitable par les équipes de remédiation. Pour aller plus loin dans la cartographie de votre exposition réelle, le catalogue de labs Entra ID disponible sur CyberAct propose des environnements reproductibles pour pratiquer ces techniques en conditions contrôlées.
Mesures de remédiation concrètes
L'audit n'a de valeur que s'il débouche sur des actions. Quelques priorités :
- Activer Privileged Identity Management (PIM) pour tous les rôles sensibles, y compris Application Administrator et Helpdesk Administrator. L'activation à la demande avec justification et durée limitée réduit drastiquement la surface d'attaque permanente.
- Auditer régulièrement les applications enregistrées avec des permissions Graph élevées. Toute application disposant de
RoleManagement.ReadWrite.DirectoryouAppRoleAssignment.ReadWrite.Alldoit être traitée comme un actif critique. - Restreindre la capacité à ajouter des credentials aux applications via des Conditional Access Policies ciblant les Service Principals.
- Mettre en place des alertes Microsoft Sentinel ou Defender for Cloud Apps sur les événements d'ajout de credentials à des applications et de réinitialisation de méthodes d'authentification hors procédure normale.
Il est aussi utile de documenter quels rôles peuvent agir sur quels autres — une cartographie statique, tenue à jour à chaque modification de l'annuaire, qui sert de référentiel lors des révisions d'accès. Si vous souhaitez évaluer l'état réel de votre configuration Entra ID, un diagnostic cyber structuré peut constituer un point de départ concret.
Questions fréquentes
Un utilisateur avec le rôle Application Administrator peut-il vraiment devenir Global Administrator sans faille technique ?
Oui, dans de nombreuses configurations par défaut. Si une application du tenant dispose déjà de permissions Graph privilégiées et qu'aucune politique ne restreint l'ajout de credentials, l'escalade est réalisable uniquement via des appels API légitimes, sans exploiter de vulnérabilité logicielle.
Quelle différence entre Application Administrator et Cloud Application Administrator dans Entra ID ?
Application Administrator gère toutes les applications, y compris celles synchronisées depuis un Active Directory on-premise. Cloud Application Administrator a un périmètre limité aux applications cloud uniquement — mais les chemins d'escalade via les Service Principals restent largement similaires. La distinction ne suffit pas à éliminer le risque.
AzureHound nécessite-t-il des droits élevés pour fonctionner en audit ?
Non. AzureHound peut fonctionner avec un compte disposant uniquement des permissions en lecture sur l'annuaire (Directory.Read.All). Il est recommandé de créer un Service Principal dédié à l'audit, avec une durée de vie limitée et une journalisation des accès activée.
PIM suffit-il à bloquer ces chemins d'escalade ?
PIM réduit significativement le risque en limitant la durée pendant laquelle les rôles sont actifs. Mais il ne supprime pas les chemins : un attaquant qui compromet un compte éligible PIM peut toujours tenter d'activer le rôle si les contrôles d'approbation ne sont pas correctement configurés. PIM doit s'accompagner d'alertes et de revues d'accès régulières.