Détections

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

HIGH

Langue :

Description

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 Présentation des autorisations et du consentement :

  • Autorisations d'application : voir l'indicateur d'exposition connexe « Autorisations d'application dangereuses affectant le tenant ».
  • 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 Développement d'une stratégie de délégation des autorisations. 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 décrit comme suit :

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.

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'API Microsoft Graph et à l'[API Azure AD Graph] héritée(https://learn.microsoft.com/fr-fr/graph/migrate-azure-ad-graph-overview) :

  • AdministrativeUnit.ReadWrite.All : permet aux attaquants de supprimer un administrateur général d'une unité administrative de gestion restreinte (RMAU) pour ensuite réinitialiser son mot de passe s'il est combiné avec d'autres autorisations.
  • Application.ReadWrite.All : 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é.
  • Application.ReadWrite.OwnedBy : identique à Application.ReadWrite.All, 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.
  • AppRoleAssignment.ReadWrite.All : permet aux attaquants de s'accorder l'autorisation RoleManagement.ReadWrite.Directory.
  • DeviceManagementConfiguration.ReadWrite.All : 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 (In)tuned to Takeovers: Abusing Intune Permissions for Lateral Movement and Privilege Escalation in Entra ID Native Environments. 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.
  • DeviceManagementRBAC.ReadWrite.All : 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 DeviceManagementConfiguration.ReadWrite.All.
  • Directory.ReadWrite.All : 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).
  • EntitlementManagement.ReadWrite.All : 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.
  • Group.ReadWrite.All : identique à Directory.ReadWrite.All
  • GroupMember.ReadWrite.All : identique à Directory.ReadWrite.All
  • Organization.ReadWrite.All : 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 l'authentification par certificat (CBA) ou, dans le cas contraire, l'autorisation Policy.ReadWrite.AuthenticationMethod pour activer au préalable la CBA.
  • Policy.ReadWrite.AuthenticationMethod : permet aux attaquants d'activer la méthode d'authentification Passe d'accès temporaire (TAP), condition préalable à l'exploitation de l'autorisation UserAuthenticationMethod.ReadWrite.Tout lorsqu'elle est associée à celle-ci. Elle permet également aux attaquants d'activer l'authentification par certificat (CBA) pour exploiter l'autorisation Organization.ReadWrite.All .
  • Policy.ReadWrite.PermissionGrant : permet aux attaquants de créer une stratégie d'octroi d'autorisation pour un principal de service contrôlé, accordant ainsi l'autorisation RoleManagement.ReadWrite.Directory et permettant l'exploitation.
  • PrivilegedAccess.ReadWrite.AzureADGroup : 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.
  • PrivilegedAssignmentSchedule.ReadWrite.AzureADGroup : identique à PrivilegedAccess.ReadWrite.AzureADGroup.
  • PrivilegedEligibilitySchedule.ReadWrite.AzureADGroup : 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.
  • RoleAssignmentSchedule.ReadWrite.Directory : 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.
  • RoleEligibilitySchedule.ReadWrite.Directory : 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.
  • RoleManagement.ReadWrite.Directory : permet aux attaquants de s'élever au rôle d'administrateur général.
  • RoleManagementPolicy.ReadWrite.AzureADGroup : 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 PrivilegedAccess.ReadWrite.AzureADGroup, PrivilegedAssignmentSchedule.ReadWrite.AzureADGroup ou PrivilegedEligibilitySchedule.ReadWrite.AzureADGroup, et suivre le même chemin que ces autorisations dans un tenant avec des paramètres PIM stricts.
  • RoleManagementPolicy.ReadWrite.Directory : 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 RoleAssignmentSchedule.ReadWrite.Directory ou RoleEligibilitySchedule.ReadWrite.Directory, et suivre le même chemin que ces autorisations dans un tenant avec des paramètres PIM stricts.
  • User.DeleteRestore.All: 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.
  • User.EnableDisableAccount.All : 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.
  • User.ReadWrite.All : 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.
  • User-PasswordProfile.ReadWrite.All : identique à Directory.ReadWrite.All
  • UserAuthenticationMethod.ReadWrite.All : permet aux attaquants de générer un passe d'accès temporaire (TAP) 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 Policy.ReadWrite.AuthenticationMethod pour activer le TAP comme méthode d'authentification dans le tenant (voir l'IoE correspondant).

Cet IoE identifie également cette autorisation dangereuse de l'API « Service de synchronisation Microsoft Entra AD » :

  • ADSynchronization.ReadWrite.All : permet aux attaquants d'appeller l'API de synchronisation non documentée, et ainsi de modifier les comptes utilisateurs hybrides et de réinitialiser leurs mots de passe.

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 :

Solution

Commencez par déterminer si le principal de service signalé avec l'autorisation est légitime. Notez qu'il est techniquement possible d'usurper le nom d'affichage dans une attaque par hameçonnage. Si le principal de service semble appartenir à un éditeur de logiciels connu, demandez-lui de confirmer que l'ID d'application signalée lui appartient. Si le principal de service est illégitime et s'il usurpe le nom d'une application connue, vous devez effectuer une analyse forensique.

  • Si le principal de service est légitime :

    • Identifiez son propriétaire et son rôle, afin de déterminer s'il a réellement besoin de ces autorisations dangereuses.
      • S'il s'agit d'une application interne, évaluez ses fonctionnalités et réduisez les autorisations en suivant le principe du moindre privilège, comme indiqué dans la section Consentement et autorisation de la documentation de l'API Microsoft Graph. Ces conseils précisent les autorisations minimales requises pour chaque API.
      • S'il s'agit d'une application tierce, demandez au fournisseur de baisser la ou les autorisations requises, ou au moins de documenter la raison pour laquelle elles sont nécessaires.
    • En guise de mesure de défense en profondeur, si vous disposez des licences Workload Identities Premium requises, envisagez d'utiliser l'Accès conditionnel pour les identités de charge de travail. Cela vous permet de limiter les principaux de service à haut risque à des emplacements approuvés connus et de limiter l'accès en fonction des connexions risquées.

  • Par défaut, tous les utilisateurs peuvent déléguer des autorisations à n'importe quelle application, ce qui leur permet de prendre des décisions de sécurité sensibles. Reportez-vous à l'indicateur d'exposition « Consentement non restreint des utilisateurs pour les applications » correspondant. Microsoft Entra ID fournit des options que vous pouvez activer pour configurer le consentement utilisateur. Lorsque vous activez des restrictions, les administrateurs Microsoft Entra ayant certains rôles doivent gérer le consentement accordé aux applications et évaluer les demandes de consentement. Voir aussi comment Examiner les demandes de consentement de l'administrateur.

  • Formez les administrateurs à l'identification des applications suspectes et des autorisations sensibles, notamment les autorisations déléguées d'utilisateurs privilégiés ou sensibles. Cette démarche doit s'inscrire dans le cadre d'un effort plus large de gouvernance des applications.

  • Retirez une autorisation si vous pensez qu'elle n'est pas légitime. Tenable recommande de sauvegarder d'abord les preuves si vous prévoyez d'effectuer une analyse forensique plus approfondie. Veuillez suivre les conseils de Microsoft et passer en revue les autorisations accordées aux applications d'entreprise. Malheureusement, cette fonctionnalité n'est plus disponible sur le portail d'administration Microsoft Entra :

Vous ne pouvez pas annuler les autorisations depuis l'onglet « Consentement utilisateur » via le portail d'administration Microsoft Entra. Toutefois, vous pouvez retirer ces autorisations via des appels à l'API Microsoft Graph ou des cmdlets PowerShell. Pour plus de détails, reportez-vous aux sections concernant PowerShell et Microsoft Graph de cet article.

Microsoft a également publié deux guides pour vous aider à effectuer un examen d’octroi de consentement d’application et à détecter et corriger les octrois de consentement illicites.

Veillez à supprimer l'autorisation dangereuse à partir du principal de service (disponible dans le menu « Applications d'entreprise » du portail) et non pas de l'application (disponible dans le menu « Inscriptions d'applications »). Sa suppression depuis l'application entraîne la suppression de la demande d'autorisation et n'affecte pas l'attribution réelle des autorisations.

En ce qui concerne l'autorisation DeviceManagementConfiguration.ReadWrite.All spécifiquement, vous pouvez utiliser des stratégies d'accès pour demander plusieurs approbations administratives. Cette approche garantit que la création ou la modification de scripts de gestion nécessite une validation par un autre compte, réduisant ainsi le risque qu'une seule application introduise des changements malveillants.

Enfin, activez les journaux d'activité de l'API Graph pour collecter des informations détaillées sur les événements de l'API Graph, afin d'aider votre SOC ou votre SIEM à identifier les activités suspectes ou à mener des investigations forensiques en cas d'attaque. Vous devez également surveiller les connexions des principaux de service et configurer des alertes pour détecter tout comportement suspect, en particulier pour les principaux de service à haut risque mis en évidence ici.

Détails de l'indicateur

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

Nom de code: DANGEROUS-DELEGATED-PERMISSIONS-AFFECTING-THE-TENANT

Sévérité: High

Type: Microsoft Entra ID Indicator of Exposure

Informations MITRE ATT&CK: