Détections

Autorisations d'application 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 :cet indicateur d'exposition examine le premier type, voir l'indicateur d'exposition connexe « Autorisations d'application dangereuses affectant les données » pour les menaces pesant sur les données sensibles à l'environnement. Le consentement est donné par les administrateurs et les autorisations s'appliquent à l'ensemble du tenant. Microsoft les décrit comme suit :

Les autorisations d'application sont utilisées par des applications qui s'exécutent sans la présence d'un utilisateur connecté. Par exemple, les applications exécutées en arrière-plan ou en tant que démons. Les autorisations d'application ne peuvent être accordées que par un administrateur.

  • Autorisations déléguées : l'indicateur d'exposition connexe « Autorisations déléguées dangereuses affectant le tenant ».

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é.
  • AppRoleAssignment.ReadWrite.All : permet aux attaquants de s'octroyer 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.

  • Les autorisations d'application nécessitent toujours le consentement de l'administrateur. Formez ces administrateurs à l'identification des applications suspectes et des autorisations sensibles, y compris à l'identification des *autorisations d'application" au niveau du tenant. 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. Le portail Microsoft Entra ID dispose d'une fonction dédiée permettant de passer en revue les autorisations accordées aux applications d'entreprise.

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'application dangereuses affectant le tenant

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

Sévérité: High

Type: Microsoft Entra ID Indicator of Exposure

Informations MITRE ATT&CK: