Microsoft expose des API dans Entra ID pour permettre à des applications tierces d'effectuer des actions sur les services Microsoft pour le compte des utilisateurs (appelées « autorisations déléguées »). Certaines autorisations peuvent constituer une grave menace pour l'ensemble du tenant Microsoft Entra.

Microsoft expose des API par l'intermédiaire d'applications dans Entra ID pour permettre à des applications tierces d'effectuer des actions au sein de Microsoft Entra ID, de Microsoft 365 (O365), du cloud Azure, etc. Des « autorisations d'API » protègent l'accès à ces API, qui doivent être disponibles uniquement pour les principaux de service qui en font la demande. L'approbation des autorisations s'appelle « attribution de rôle d'application » ou « octroi d'autorisation ».
Certaines autorisations sur certaines API Microsoft (voir ci-dessous) peuvent représenter une grave menace pour l'ensemble du tenant Microsoft Entra ID, car un principal de service qui dispose de ces autorisations devient très puissant, tout en étant plus discret qu'un utilisateur disposant d'un rôle d'administrateur puissant tel que l'Administrateur général. En exploitant ces autorisations, un attaquant peut contourner l'authentification multifacteur (MFA) et résister aux réinitialisations de mot de passe des utilisateurs.
Lorsqu'elles sont légitimes, les autorisations augmentent la surface d'attaque pour le tenant. Lorsqu'elles ne le sont pas, il peut s'agir d'une tentative malveillante d'élévation de privilèges ou d'une méthode de persistance.
Il existe deux types d'autorisations d'API dans Microsoft Entra ID, comme décrit dans la documentation Microsoft <a href="https://learn.microsoft.com/fr-fr/entra/identity-platform/permissions-consent-overview">Présentation des autorisations et du consentement</a> :
<ul>
<li>Autorisations d'application : voir l'indicateur d'exposition connexe « Autorisations d'application dangereuses affectant le tenant ».</li>
<li>Autorisations déléguées : cet indicateur d'exposition examine ce second type ; voir l'indicateur d'exposition connexe « Autorisations déléguées dangereuses affectant les données » pour les menaces pesant sur les données sensibles à l'environnement. Le consentement est donné par les utilisateurs ou les administrateurs au nom de l'ensemble de l'organisation. Notez que ces autorisations limitent la possibilité pour une application d'effectuer des actions, sur la base des privilèges de l'utilisateur connecté (autrement dit, ses possibilités se limitent à l'intersection de l'autorisation et du niveau de privilège de l'utilisateur). Par conséquent, le niveau de danger que représentent ces autorisations déléguées dépend des autorisations réelles de l'utilisateur de l'application, comme décrit dans la section <a href="https://learn.microsoft.com/fr-fr/security/zero-trust/develop/developer-strategy-delegated-permission">Développement d'une stratégie de délégation des autorisations</a>. Exemple : si un utilisateur standard délègue l'autorisation « Group.ReadWrite.All », l'application peut modifier uniquement les groupes que l'utilisateur peut modifier et non pas tous les groupes. Microsoft les <a href="https://learn.microsoft.com/fr-fr/security/operations/incident-response-playbook-app-consent#delegated-permissions-vs-application-permissions">décrit</a> comme suit :</li>
</ul>
<blockquote>
Les autorisations déléguées sont utilisées par les applications qui disposent d'un utilisateur connecté et qui peuvent faire appliquer des consentements par l'administrateur ou l'utilisateur.
</blockquote>
Cet indicateur d'exposition (IoE) ne porte que sur les principaux de service, car les autorisations d'API s'appliquent uniquement aux principaux de service, et non pas aux utilisateurs.
Cet IoE identifie les autorisations dangereuses suivantes qui permettent d'accéder à l'<a href="https://learn.microsoft.com/fr-fr/graph/overview">API Microsoft Graph</a> et à l'[API Azure AD Graph] héritée(<a href="https://learn.microsoft.com/fr-fr/graph/migrate-azure-ad-graph-overview">https://learn.microsoft.com/fr-fr/graph/migrate-azure-ad-graph-overview</a>) :
<ul>
<li><code>AdministrativeUnit.ReadWrite.All</code> : permet aux attaquants de supprimer un administrateur général d'une <a href="https://learn.microsoft.com/fr-fr/entra/identity/role-based-access-control/admin-units-restricted-management">unité administrative de gestion restreinte (RMAU)</a> pour ensuite réinitialiser son mot de passe s'il est combiné avec d'autres autorisations.</li>
<li><code>Application.ReadWrite.All</code> : permet aux attaquants d'injecter des identifiants dans des applications plus privilégiées, et ainsi d'obtenir un accès non autorisé jusqu'à l'administrateur général par emprunt d'identité.</li>
<li><code>Application.ReadWrite.OwnedBy</code> : identique à <code>Application.ReadWrite.All</code>, mais s'applique uniquement aux principaux de service détenus par le principal de service signalé. Notez qu'elle n'est généralement pas disponible en tant qu'autorisation déléguée.</li>
<li><code>AppRoleAssignment.ReadWrite.All</code> : permet aux attaquants de s'accorder l'autorisation <code>RoleManagement.ReadWrite.Directory</code>.</li>
<li><code>DeviceManagementConfiguration.ReadWrite.All</code> : permet aux attaquants de compromettre des appareils gérés par Intune en déployant des scripts de gestion malveillants, comme le décrit Mandiant dans <a href="https://cloud.google.com/blog/topics/threat-intelligence/abusing-intune-permissions-entra-id-environments/">(In)tuned to Takeovers: Abusing Intune Permissions for Lateral Movement and Privilege Escalation in Entra ID Native Environments</a>. Cela peut permettre une élévation de privilèges vers l'administrateur général si un administrateur utilise un appareil géré par Intune.</li>
<li><code>DeviceManagementRBAC.ReadWrite.All</code> : permet aux attaquants d'attribuer des rôles Intune privilégiés à un compte qu'ils contrôlent, et ainsi d'exécuter des commandes arbitraires sur des appareils Intune, comme indiqué dans <code>DeviceManagementConfiguration.ReadWrite.All</code>.</li>
<li><code>Directory.ReadWrite.All</code> : permet aux attaquants de s'ajouter en tant que membres de groupes non assignables par rôle pour ainsi pouvoir obtenir des privilèges dans le cloud Azure. Cela peut leur permettre de passer par les ressources Azure, ce qui peut entraîner une élévation de privilèges pour le rôle d'administrateur général dans Entra ID (par exemple, via des identités gérées) ou même vers les administrateurs du domaine dans Active Directory (par exemple, via des machines virtuelles de contrôleur de domaine hébergées dans Azure).</li>
<li><code>EntitlementManagement.ReadWrite.All</code> : permet aux attaquants de mettre à jour la stratégie d'affectation d'un package d'accès qui accorde le rôle d'administrateur général, et ainsi de demander ce rôle sans approbation.</li>
<li><code>Group.ReadWrite.All</code> : identique à <code>Directory.ReadWrite.All</code></li>
<li><code>GroupMember.ReadWrite.All</code> : identique à <code>Directory.ReadWrite.All</code></li>
<li><code>Organization.ReadWrite.All</code> : permet aux attaquants d'ajouter un certificat racine de confiance à Entra ID et de s'authentifier en tant qu'utilisateur, y compris ceux affectés à l'administrateur général. Cela nécessite l'activation de <a href="https://learn.microsoft.com/fr-fr/entra/identity/authentication/concept-certificate-based-authentication">l'authentification par certificat (CBA)</a> ou, dans le cas contraire, l'autorisation <code>Policy.ReadWrite.AuthenticationMethod</code> pour activer au préalable la CBA.</li>
<li><code>Policy.ReadWrite.AuthenticationMethod</code> : permet aux attaquants d'activer la méthode d'authentification <a href="https://learn.microsoft.com/fr-fr/entra/identity/authentication/howto-authentication-temporary-access-pass">Passe d'accès temporaire (TAP)</a>, condition préalable à l'exploitation de l'autorisation <code>UserAuthenticationMethod.ReadWrite.Tout</code> lorsqu'elle est associée à celle-ci. Elle permet également aux attaquants d'activer <a href="https://learn.microsoft.com/fr-fr/entra/identity/authentication/concept-certificate-based-authentication">l'authentification par certificat (CBA)</a> pour exploiter l'autorisation <code>Organization.ReadWrite.All</code> .</li>
<li><code>Policy.ReadWrite.PermissionGrant</code> : permet aux attaquants de créer une <a href="https://learn.microsoft.com/fr-fr/graph/api/permissiongrantpolicy-post-includes?view=graph-rest-1.0&amp;tabs=http">stratégie d'octroi d'autorisation</a> pour un principal de service contrôlé, accordant ainsi l'autorisation <code>RoleManagement.ReadWrite.Directory</code> et permettant l'exploitation.</li>
<li><code>PrivilegedAccess.ReadWrite.AzureADGroup</code> : permet aux attaquants d'ajouter un compte utilisateur contrôlé en tant que membre d'un groupe assigné au rôle d'administrateur général.</li>
<li><code>PrivilegedAssignmentSchedule.ReadWrite.AzureADGroup</code> : identique à <code>PrivilegedAccess.ReadWrite.AzureADGroup</code>.</li>
<li><code>PrivilegedEligibilitySchedule.ReadWrite.AzureADGroup</code> : permet aux attaquants de rendre un compte utilisateur contrôlé admissible à un groupe affecté au rôle d'administrateur général, puis d'activer l'appartenance et ainsi permettre une élévation de privilèges.</li>
<li><code>RoleAssignmentSchedule.ReadWrite.Directory</code> : permet aux attaquants d'attribuer le rôle d'administrateur général à un compte utilisateur contrôlé en créant une attribution de rôle PIM active.</li>
<li><code>RoleEligibilitySchedule.ReadWrite.Directory</code> : permet aux attaquants de rendre un compte utilisateur contrôlé admissible au rôle d'administrateur général, puis de l'activer pour permettre une élévation de privilèges.</li>
<li><code>RoleManagement.ReadWrite.Directory</code> : permet aux attaquants de s'élever au rôle d'administrateur général.</li>
<li><code>RoleManagementPolicy.ReadWrite.AzureADGroup</code> : permet aux attaquants de supprimer des attributions de rôle de groupe et des contraintes d'activation, telles que des exigences MFA ou l'approbation de l'administrateur, pour exploiter <code>PrivilegedAccess.ReadWrite.AzureADGroup</code>, <code>PrivilegedAssignmentSchedule.ReadWrite.AzureADGroup</code> ou <code>PrivilegedEligibilitySchedule.ReadWrite.AzureADGroup</code>, et suivre le même chemin que ces autorisations dans un tenant avec des paramètres PIM stricts.</li>
<li><code>RoleManagementPolicy.ReadWrite.Directory</code> : permet aux attaquants de supprimer une attribution de rôle Entra et des contraintes d'activation telles que des exigences MFA ou l'approbation de l'administrateur pour exploiter <code>RoleAssignmentSchedule.ReadWrite.Directory</code> ou <code>RoleEligibilitySchedule.ReadWrite.Directory</code>, et suivre le même chemin que ces autorisations dans un tenant avec des paramètres PIM stricts.</li>
<li><code>User.DeleteRestore.All</code>: permet aux attaquants de supprimer tous les comptes utilisateur du tenant pour le rendre indisponible, puis d'exiger une rançon pour restaurer l'un des comptes de secours. Bien que cette autorisation ne permette pas l'élévation au rôle d'administrateur général, elle perturbe l'accès.</li>
<li><code>User.EnableDisableAccount.All</code> : permet aux attaquants de désactiver tous les comptes utilisateur du tenant pour le rendre indisponible, puis d'exiger une rançon pour restaurer l'un des comptes de secours. Bien que cette autorisation ne permette pas l'élévation au rôle d'administrateur général, elle perturbe l'accès.</li>
<li><code>User.ReadWrite.All</code> : permet aux attaquants de modifier les propriétés sensibles d'un compte utilisateur contrôlé, telles que « ID de l'employé » et « Service », pour en faire un membre d'un groupe dynamique (voir l'IoE correspondant) disposant d'autorisations Azure privilégiées. Ils peuvent ensuite tirer parti des ressources Azure pour éventuellement s'élever au rôle d'administrateur général.</li>
<li><code>User-PasswordProfile.ReadWrite.All</code> : identique à <code>Directory.ReadWrite.All</code></li>
<li><code>UserAuthenticationMethod.ReadWrite.All</code> : permet aux attaquants de générer un <a href="https://learn.microsoft.com/fr-fr/entra/identity/authentication/howto-authentication-temporary-access-pass">passe d'accès temporaire (TAP)</a> et de prendre le contrôle de n'importe quel compte utilisateur dans le tenant. Si le TAP n'est pas déjà activé, ils doivent l'utiliser avec <code>Policy.ReadWrite.AuthenticationMethod</code> pour activer le TAP comme méthode d'authentification dans le tenant (voir l'IoE correspondant).</li>
</ul>
Cet IoE identifie également <a href="https://www.tenable.com/blog/despite-recent-security-hardening-entra-id-synchronization-feature-remains-open-for-abuse">cette autorisation dangereuse</a> de l'API « Service de synchronisation Microsoft Entra AD » :
<ul>
<li><code>ADSynchronization.ReadWrite.All</code> : permet aux attaquants d'appeler l'API de synchronisation non documentée, et ainsi de modifier les comptes utilisateurs hybrides et de réinitialiser leurs mots de passe.</li>
</ul>
Les applications légitimes disposant de ces autorisations dangereuses demandent un accès qui peut être trop large. Ce peut également être le signe d'une attaque par hameçonnage appelée « octroi d'autorisation illicite », au cours de laquelle un attaquant obtient le consentement d'un administrateur.
Par défaut, cet IoE ignore les principaux de service désactivés, car les attaquants ne peuvent pas les utiliser immédiatement.
Références externes :
<ul>
<li><a href="https://posts.specterops.io/azure-privilege-escalation-via-azure-api-permissions-abuse-74aee1006f48">Andy Robbins - Azure Privilege Escalation via Azure API Permissions Abuse </a></li>
<li><a href="https://posts.specterops.io/directory-readwrite-all-is-not-as-powerful-as-you-might-think-c5b09a8f78a8">Andy Robbins - Directory.ReadWrite.All Is Not As Powerful As You Might Think </a></li>
<li><a href="https://csandker.io/2022/11/10/Untangling-Azure-II-Privileged-Access.html">Carsten Sandker - Untangling Azure Active Directory Permissions II: Privileged Access </a></li>
<li><a href="https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/">Dirk-jan Mollema - Azure AD privilege escalation - Taking over default application permissions as Application Admin </a></li>
<li><a href="https://github.com/emiliensocchi/azure-tiering/tree/main/Microsoft%20Graph%20application%20permissions#-tier-0-family-of-global-admins">Emilien Socchi - Tier 0 permissions (en anglais)</a> (à consulter pour plus de détails, notamment sur les motifs d'exploitabilité)</li>
<li><a href="https://m365internals.com/2021/07/24/everything-about-service-principals-applications-and-api-permissions/">Huy Kha - Everything about Service Principals, Applications, and API Permissions </a></li>
<li><a href="https://www.inversecos.com/2021/10/how-to-backdoor-azure-applications-and.html">Lina Lau - How to Backdoor Azure Applications and Abuse Service Principals </a></li>
<li><a href="https://cloud.google.com/blog/topics/threat-intelligence/abusing-intune-permissions-entra-id-environments/">Mandiant Red Team - (In)tuned to Takeovers: Abusing Intune Permissions for Lateral Movement and Privilege Escalation in Entra ID Native Environments</a></li>
<li><a href="https://youtu.be/jMOFWVOm-Y4?t=2229">Marius Solbakken Mellum - Surprising ways to escalate privileges in Entra ID </a></li>
<li><a href="https://winsmarts.com/how-to-grant-admin-consent-to-an-api-programmatically-e32f4a100e9d">Sahil Malik - How to grant admin consent to an API programmatically</a></li>
<li><a href="https://learningbydoing.cloud/blog/audit-ms-graph-app-role-assignments/">Stian A. Strysse - What's lurking in your Microsoft Graph app role assignments?</a></li>
</ul>

Initial Access

Phishing

Persistence

Cloud Application Integration

Détections

Autorisations déléguées dangereuses affectant le tenant

HIGH

Version 202507070935

Version 202411251447

Version 202507070935 Jul 7, 2025, 9:35 AM Metadata (link to blogpost) Release: 202507070935
Version 202411251447 Nov 25, 2024, 2:47 PM New Release: 202411251447