Scénario EntraGoat 3 : Exploitation de la propriété de groupe dans Entra ID

Note de la rédaction

Ce scénario fait partie d'une série d'exemples démontrant l'utilisation d'EntraGoat, notre environnement de simulation Entra ID. Vous pouvez lire un aperçu d'EntraGoat et de sa valeur ici.

Membre du groupeNaufrage-Voilier dans les eaux administratives

Le scénario 3 d'EntraGoat démontre comment des fonctions administratives légitimes d'Entra ID - la propriété des groupes, les groupes assignables à des rôles, et la gestion des principaux services - peuvent être enchaînées dans un chemin d'escalade de privilèges involontaire d'un utilisateur à faible privilège à l'administrateur global.

L'attaquant commence par un compte d'assistance informatique compromis qui possède plusieurs groupes, y compris un groupe auquel des rôles peuvent être attribués avec l'attribut Application Administrator le rôle. En s'ajoutant à ce groupe, l'attaquant hérite du rôle et obtient un contrôle étendu sur les applications et les principaux services du locataire.

À partir de là, en identifiant un principal de service de grande valeur qui est membre d'un autre groupe auquel des rôles peuvent être attribués et qui détient l'autorisation d'accès à l'information de l'UE. Privileged Authentication Administrator l'attaquant y ajoute un secret client, s'authentifie en tant que principal du service privilégié et réinitialise le mot de passe de l'administrateur global.

Ce scénario met en évidence la façon dont des fonctions Entra ID légitimes individuellement, lorsqu'elles sont combinées à une mauvaise configuration de la propriété des groupes, peuvent se transformer en une chaîne d'escalade des privilèges qui élève un compte de bas niveau en une menace à l'échelle du locataire.

Vue d'ensemble du chemin d'attaque

1. L'histoire d'une première prise de pied : L'attaquant s'authentifie en tant que Michael ChenUn utilisateur compromis, spécialiste de l'assistance informatique, qui, selon la description du scénario, "gère quelques groupes de sécurité".
2. Enumération : L'attaquant découvre la propriété de six groupes, dont un groupe attribuable à un rôle appelé IT Application Managers qui contient le Application Administrator rôle.
3. L'escalade des privilèges : L'attaquant s'ajoute au groupe de sécurité pour hériter du rôle privilégié.
4. Ciblage principal du service : Avec la Application Administrator l'attaquant identifie le rôle de l'annuaire Identity Management Portal principal de service en tant que membre d'un groupe avec le Privileged Authentication Administrator et y ajoute un secret client.
5. Pivot : L'attaquant s'authentifie via le flux OAuth2 d'octroi de justificatifs d'identité du client en tant que principal du service compromis avec le nouveau secret ajouté.
6. Compromission de compte : en utilisant les privilèges inhérents au principal de service, l'attaquant réinitialise le mot de passe de l'administrateur général, s'authentifie en tant qu'administrateur général et récupère l'indicateur de scénario.

Flux d'attaque

La figure 1 illustre le déroulement de cette attaque.

Pourquoi cette attaque fonctionne-t-elle ?

Ce scénario associe plusieurs fonctions légitimes d'Entra ID qui, lorsqu'elles sont mal configurées, créent une voie d'escalade :

• Propriété de groupe : Le modèle de propriété de groupe d'Entra ID accorde un contrôle étendu sur les membres et les propriétés. Bien qu'il soit destiné à déléguer des tâches administratives, il devient risqué lorsqu'il est appliqué à des groupes auxquels des rôles peuvent être attribués ou lorsqu'il est accordé à des utilisateurs inappropriés puisqu'un propriétaire peut directement s'ajouter lui-même (ou tout autre compte contrôlé) au groupe et hériter des rôles qui lui sont attribués.
• Groupes attribuables à des rôles : Les groupes de sécurité attribuables à des rôles permettent aux administrateurs d'attribuer des rôles de répertoire à des groupes plutôt qu'à des utilisateurs individuels, ce qui simplifie la gestion des rôles à grande échelle en faisant en sorte que tout membre du groupe reçoive automatiquement les rôles qui lui sont attribués. Combiné à des autorisations de propriété de groupe, ce système crée une voie d'escalade des privilèges où les propriétaires de groupe peuvent effectivement s'octroyer les rôles attribués aux groupes qu'ils contrôlent.
• Appartenance au groupe principal de service : Les responsables de service, comme les utilisateurs, peuvent être membres de groupes de sécurité et hériter de tous les rôles attribués à ces groupes. Cette conception permet aux administrateurs de gérer les autorisations d'application par le biais de l'appartenance à un groupe plutôt que par l'attribution de rôles individuels. Cependant, les directeurs de service présentent des surfaces d'attaque uniques que les utilisateurs réguliers d'Entra ID n'ont pas. Ces mécanismes supplémentaires créent davantage de vecteurs potentiels pour obtenir un accès non autorisé à tout principal de service privilégié qui détient des adhésions à des groupes privilégiés.
  • Elles peuvent être compromises par des relations de propriété (comme dans le scénario 1).
  • Ils sont soumis à des contrôles de gestion des applications - les identités avec le système de gestion des applications intégré sont soumises à des contrôles de gestion des applications. Application Administrator ou Cloud Application Administrator les rôles personnalisés qui incluent le microsoft.directory/applications/credentials/update ou microsoft.directory/servicePrincipals/credentials/update des actions, ou des chefs de service avec les Application.ReadWrite.All qui permet d'ajouter ou de modifier les informations d'identification du principal de service.
  • Ils peuvent être gérés de manière programmatique par le biais d'API et de flux de travail automatisés.
  • Contrairement aux identités des utilisateurs, ils ne peuvent pas être assignés comme éligibles à la PIM ; ils ne peuvent avoir que des attributions de rôle actives (qui peuvent être limitées dans le temps). Lorsqu'un principal de service fait partie d'un groupe auquel des rôles peuvent être attribués, son accès contourne les contrôles d'activation juste à temps de PIM, ce qui lui permet d'être toujours actif pendant la fenêtre d'attribution des rôles.
  • Ils peuvent s'authentifier dans un contexte d'application uniquement (OAuth2 client-credentials) à l'aide d'un secret ou d'un certificat client, ce qui permet de contourner les contrôles centrés sur l'utilisateur tels que l'AMF interactive et les exigences d'accès conditionnel interactif.
• Champ d'application de l'administrateur d'applications : Ce rôle permet un contrôle étendu des enregistrements d'applications et des principaux services, y compris la possibilité d'ajouter des références d'authentification (secrets et certificats) aux applications dans le locataire, ce qui crée des opportunités pour les attaquants de mettre en place des portes dérobées pour les principaux services de grande valeur qui ne sont pas configurés avec le verrouillage de l'instance de l'application.

Chacune de ces caractéristiques d'Entra ID est légitime et nécessaire pour la délégation administrative, mais en les combinant, elles créent des chemins d'escalade de privilèges involontaires qui peuvent élever une identité à faible privilège jusqu'à l'administrateur global.

Comment détecter et se défendre contre l'utilisation abusive de la propriété collective ?

Le contrôle de la propriété des groupes est une exigence de sécurité fondamentale dans tout environnement Entra ID.

Les propriétaires peuvent gérer l'appartenance, modifier les propriétés du groupe et contrôler indirectement tous les rôles de répertoire attribués à leurs groupes. Sans une visibilité claire des relations de propriété et des attributions de rôles, les voies d'escalade des privilèges à travers les groupes auxquels des rôles peuvent être attribués peuvent rester cachées à la fois aux défenseurs et aux auditeurs.

Les défenseurs doivent surveiller et établir des corrélations :

• Quels sont les groupes auxquels des rôles peuvent être attribués dans le locataire ?
• Quels rôles de répertoire sont attribués à ces groupes ?
• Qui les possède et quelle est la justification commerciale de cette propriété ?
• Des utilisateurs non privilégiés possèdent-ils des groupes auxquels des rôles privilégiés ont été attribués ?
• Quels sont les principaux services qui sont membres de groupes auxquels des rôles peuvent être attribués ?
• Existe-t-il des groupes inutilisés ou orphelins qui peuvent être déclassés ?

Les solutions Semperis permettent de combler les lacunes dans la compréhension de ces questions grâce à plusieurs niveaux de défense, à commencer par les indicateurs d'exposition (IOE) et les indicateurs de compromission (IOC).

Ces indicateurs détectent et alertent automatiquement sur les défauts dangereux et les mauvaises configurations, tels que les groupes auxquels des rôles peuvent être attribués avec des propriétaires inappropriés, les principaux services avec des permissions dangereuses, et les bases de gouvernance de groupe faibles qui permettent l'escalade des privilèges par la manipulation de l'appartenance à un groupe.

Approfondissement du scénario : Présentation de la solution étape par étape

Vous pouvez trouver la description complète et les commandes qui l'accompagnent dans le dépôt EntraGoat GitHub sous solutions/EntraGoat-Scenario3-Solution.ps1.

Étape 1 : Prise d'ancrage initiale

Nous commençons le scénario 3, en tant que Figure 2 montre, avec l'accès à un utilisateur compromis à faible privilège nommé Michael ChenMichael est un spécialiste de l'assistance informatique. L'histoire nous apprend que Michael possède plusieurs groupes de sécurité - une mauvaise configuration qui ouvre la voie à l'escalade.

Nous nous authentifions à l'aide de ses données d'identification en utilisant la fonction Connect-MgGraph puis exécutez Get-MgContext pour confirmer notre contexte de sécurité actuel (Figure 3).

Étape 2 : Dénombrement

Ensuite, puisque l'indice nous oriente dans cette direction, nous énumérons tous les groupes appartenant à l'utilisateur actuel(figure 4).

Nous découvrons qu'il possède six groupes au total. Pour évaluer le potentiel d'escalade des privilèges, nous vérifions si l'un d'entre eux est attribuable à un rôle et si des rôles lui ont effectivement été attribués(figure 5).

Un groupe se distingue immédiatement : IT Application Managersqui détient le Application Administrator rôle.

Ce rôle est puissant car il donne un contrôle total sur tous les enregistrements d'applications et les principaux services dans le locataire, y compris la possibilité d'ajouter des secrets ou des certificats à toutes les applications tierces (dans le cas où elles ne sont pas configurées avec le verrouillage de l'instance de l'application). Ensuite, l'attaquant peut utiliser l'identité du principal de service pour s'authentifier auprès du locataire via le flux d'octroi de crédences du client OAuth 2.0, en opérant dans un contexte d'application uniquement qui contourne les protections centrées sur l'utilisateur.

Note : Les étapes d'énumération ci-dessus peuvent être intégrées dans des fonctions d'aide dédiées (par ex, Get-GroupsOwnedBy pour la propriété et Get-GroupRoles pour les rôles attribués) afin de rendre le processus plus interactif et verbeux, de la même manière que les outils open-source présentent les résultats.

Les figures 6 et 7 illustrent la mise en œuvre.

La figure 8 montre l'aspect de la sortie flashy lorsque nous exécutons cette fonction d'énumération avec l'identifiant de l'utilisateur actuel.

Bien que cela puisse s'avérer utile dans les grands environnements, Microsoft Graph propose également une cmdlet bien plus efficace : Get-MgUserOwnedObject (Figure 9).

Get-MgUserOwnedObject énumère tous les objets du répertoire appartenant à un utilisateurce qui élimine le besoin d'interroger chaque type d'objet (groupes, appareils, applications et services principaux) individuellement, contrairement à notre implémentation intentionnelle. La commande peut être légèrement modifiée avec Sonnet pour obtenir une sortie plus agréable (Figure 10).

La commande Get-MgUserOwnedObject fait généralement une demande d'API à https://graph.microsoft.com/v1.0/users/{userId}/ownedObjects (en ajoutant éventuellement une ou deux requêtes supplémentaires, en fonction de la pagination), le reste étant géré par la logique PowerShell locale pour traiter, extraire et formater la réponse.

En comparaison, la Get-GroupsOwnedBy La fonction que nous avons créée, qui pourrait être plus interactive et plus conviviale, fait de la 100-1000x les demandes d'APImême s'il ne vérifie qu'un seul type d'objet possédé.

Lors de la sélection d'outils d'énumération, il est toujours judicieux de privilégier l'efficacité. Moins d'appels à l'API signifie moins de journaux et une empreinte de détection plus petite. Il existe de nombreux outils open-source géniaux (et d'autres moins géniaux) pour dénombrer les environnements Entra ID. Le point clé est que, bien que les outils puissent être des raccourcis utiles, ils ne doivent jamais être utilisés comme des boîtes noires. Si vous pouvez lire le code source, faites-le. Prenez le temps de comprendre comment les requêtes sont construites, quels sont les points d'accès à l'API et quelles sont les données renvoyées. Les outils ne sont efficaces que dans la mesure où l'opérateur comprend leurs méthodes et leurs limites.

Étape 3 : Construction de la chaîne d'attaque

Posséder un groupe avec Application Administrator présente un potentiel important d'escalade des privilèges car une fois que nous nous sommes ajoutés en tant que membre, nous pouvons gérer (== ajouter un secret client à) tous dans le locataire, ce qui ouvre de multiples voies à la compromission du locataire.

Mais nous ajouter maintenant serait bruyant et inutile du point de vue de l'OPSEC. Tout d'abord, nous devons confirmer qu'il existe un service principal privilégié sur lequel nous pouvons nous appuyer pour atteindre la chaîne suivante de l'attaque - le rôle de l'agent général.

Il est temps de se mettre à la recherche de prestataires de services à forte valeur ajoutée.

Remarque : Dans le cadre de ce guide, nous nous concentrerons sur l'énumération des principaux de service ayant des rôles privilégiés qui permettent de réinitialiser le mot de passe de l'AG en quelques étapes seulement :

• Administrateur de rôles privilégiés (PRA)
• Administrateur d'authentification privilégié (AAP)
• Administrateur mondial (AG)

Cela dit, dans un véritable locataire, il ne faut pas s'arrêter là. Il est tout aussi important d'énumérer les principaux de service avec d'autres rôles et avec des permissions d'application puissantes, car ils peuvent ouvrir des voies d'escalade tout aussi dangereuses, comme le montre le scénario 2.

Nous commencerons par utiliser la fonction Get-MgRoleManagementDirectoryRoleAssignment pour vérifier si des mandants de service se voient directement attribuer des rôles privilégiés (Figure 11).

Résultat ? Rien. Pas un seul directeur de service ne détient directement des AG, des PRA ou des AAP dans mon locataire.

Mais ce n'est pas l'ensemble des responsables de service qui peuvent se voir attribuer des rôles privilégiés. Entra ID permet l'attribution de rôles à des groupes, et tout comme les utilisateurs, les responsables de service peuvent être membres de ces groupes. Si un groupe a GA, PRA, ou PAA, alors tout directeur de service à l'intérieur de ce groupe hérite de ces privilèges. Il s'agit d'un vecteur d'escalade souvent négligé.

Ensuite, nous énumérons tous les groupes auxquels des rôles peuvent être attribués et nous vérifions lesquels ont des rôles attribués(figure 12).

Maintenant que nous disposons d'une liste de groupes privilégiés, nous devons inspecter leurs membres. Puisque la fonction Get-MgGroupMember fonctionne sur la version 1.0, il ne montre pas les membres du principal de service. Pour résoudre ce problème, nous allons intégrer un appel direct à la fonction /beta dans une fonction d'aide (Figure 13).

Nous pouvons maintenant l'utiliser pour filtrer l'appartenance des principaux de service aux groupes privilégiés(Figure 14).

C'est maintenant que les choses deviennent intéressantes - nous avons découvert des responsables de service potentiels avec des rôles privilégiés. En fonction de votre environnement, vous pouvez en avoir beaucoup plus.

Nous pouvons simplement choisir le premier ($targetSPs[0]), mais par souci de cohérence (et pour que chaque joueur ait le même chemin sans risquer de compromettre la stabilité du locataire), nous nous concentrerons sur l'élément Identity Management Portal, comme Figure 15 montre. Celle-ci fait partie du script d'installation et ne cassera rien en cas de changement de fonctionnalité (je croise les doigts).

À ce stade, nous avons établi la chaîne d'attaque complète. Voici comment nous passerons de l'utilisateur actuel à faible privilège à l'administrateur global :

1. Nous ajouter à la IT Application Managers pour hériter du groupe Application Administrator rôle.
2. Utilisez ce rôle pour ajouter un secret de client à la base de données Identity Management Portal principal de service.
3. S'authentifier en tant que principal de service.
4. Utiliser ses privilèges d'AAP hérités pour réinitialiser le mot de passe de l'administrateur général.
5. Connectez-vous en tant qu'administrateur global avec le nouveau mot de passe.
6. Récupérer le drapeau pour prouver le compromis.

Étape 4 : Exécution du chemin d'attaque

Tout d'abord, nous nous ajoutons en tant que membres au IT Application Managers groupe, en tant que Figure 16 montre.

Comme les jetons ne sont pas mis à jour automatiquement, nous pouvons nous déconnecter et nous réauthentifier pour obtenir un nouveau jeton d'accès avec le nouveau rôle attribué. Comme indiqué dans le scénario 2, cette étape n'est pas indispensable, car la plupart des terminaux Entra ID évaluent généralement les attributions de rôle de manière dynamique.

Nous pouvons utiliser le parse-JWTToken par BARK pour voir le rôle d'administrateur ajouté à l'application (la fonction wids dans le jeton JWT que Figure 17 ) attribués à l'utilisateur.

Avec Application Administrator nous pouvons ajouter une porte dérobée à l'accès au système. Identity Management Portal (Figure 18), comme nous l'avons fait dans Scénario 1.

Cela nous donne un accès permanent au principal de service, indépendamment de tout compte d'utilisateur. Nous pouvons l'utiliser pour nous authentifier en tant que principal de service auprès d'Entra ID, comme le montre la figure 19 .

L'étape suivante consiste à trouver l'utilisateur cible de l'AG et à réinitialiser son mot de passe(figure 20).

Enfin, nous pouvons nous authentifier en tant qu'AG et récupérer le drapeau (Figure 21). Nous utiliserons Get-MSGraphTokenWithUsernamePassword pour s'authentifier à partir de l'interface de programmation (comme dans le cas de Scénario 2), mais vous pouvez également définir un TAP (comme dans Scénario 1) et ouvrez une session interactive à partir du portail Azure ou du centre d'administration Entra ID.

Scénario 3 terminé !

Étape 5 : Nettoyage

N'oubliez pas d'exécuter le script de nettoyage(Figure 22) pour ramener l'environnement du locataire à son état d'origine.

Enseignements tirés

Le scénario 3 montre comment des erreurs de configuration apparemment mineures dans la propriété d'un groupe peuvent se transformer en une compromission totale du locataire. La chaîne d'attaque (de l'utilisateur à faible privilège à l'administrateur global) n'a nécessité aucune technique sophistiquée, juste une compréhension du modèle de délégation d'Entra ID, du fonctionnement de l'héritage des rôles et du plan de contrôle des identités principales de service.

Ce qu'il faut retenir : La propriété d'un groupe est une délégation administrative déguisée. Lorsque des utilisateurs possèdent des groupes auxquels des rôles peuvent être attribués, ils contrôlent effectivement tous les rôles attribués à ces groupes. Les principes de service amplifient ce risque parce qu'ils peuvent être compromis par de multiples voies au-delà du vol traditionnel d'informations d'identification - relations de propriété, rôles de gestion d'application et accès programmatique.

Le scénario montre que dans les environnements modernes d'identité en nuage, les chemins d'escalade des privilèges sont rarement linéaires. Ils passent par les relations de propriété, l'appartenance à des groupes et les identités des principaux services, ce qui oblige les défenseurs à réfléchir systématiquement aux relations d'identité plutôt qu'aux autorisations individuelles.

Le spécialiste de l'assistance informatique ayant peu de privilèges n'avait pas besoin de casser quoi que ce soit : le chemin d'escalade était intégré dès le départ dans la configuration du locataire.

Relevez le prochain défi d'EntraGoat

GitHub - Semperis/EntraGoat
Qu'est-ce qu'EntraGoat ? Un environnement de simulation Entra ID délibérément vulnérable
Démarrer avec EntraGoat : casser Entra ID de manière intelligente
Scénario 1 : Abus de propriété de service principal dans Entra ID
Scénario 2 : Exploitation des permissions de graphes réservées aux applications dans Entra ID
Scénario 6 : Exploitation de l'authentification par certificat pour usurper l'identité d'un administrateur global dans Entra ID

Note de bas de page

1. https://github.com/BloodHoundAD/BARK

Clause de non-responsabilité

Ce contenu est fourni à des fins éducatives et informatives uniquement. Il vise à promouvoir la prise de conscience et la remédiation responsable des vulnérabilités de sécurité qui peuvent exister sur les systèmes que vous possédez ou que vous êtes autorisé à tester. L'utilisation non autorisée de ces informations à des fins malveillantes, d'exploitation ou d'accès illégal est strictement interdite. Semperis n'approuve ni ne tolère aucune activité illégale et décline toute responsabilité découlant d'une mauvaise utilisation du matériel. En outre, la Semperis ne garantit pas l'exactitude ou l'exhaustivité du contenu et n'assume aucune responsabilité pour les dommages résultant de son utilisation.