Az - OAuth Apps Phishing
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Les applications Azure sont configurées avec les autorisations qu'elles pourront utiliser lorsque l'utilisateur consent à l'application (comme énumérer le répertoire, accéder aux fichiers ou effectuer d'autres actions). Notez que l'application agira au nom de l'utilisateur, donc même si l'application peut demander des autorisations d'administration, si l'utilisateur qui consent n'a pas cette autorisation, l'application ne pourra pas effectuer d'actions administratives.
Par défaut, tout utilisateur peut donner son consentement aux applications, bien que cela puisse être configuré pour que les utilisateurs ne puissent consentir qu'aux applications de publishers vérifiés pour des autorisations sélectionnées ou même supprimer l'autorisation pour que les utilisateurs puissent consentir à des applications.
Si les utilisateurs ne peuvent pas consentir, des administrateurs comme GA, Application Administrator ou Cloud Application Administrator peuvent consentir aux applications que les utilisateurs pourront utiliser.
De plus, si les utilisateurs peuvent consentir uniquement aux applications utilisant des autorisations à faible risque, ces autorisations sont par défaut openid, profile, email, User.Read et offline_access, bien qu'il soit possible d'ajouter plus à cette liste.
Et s'ils peuvent consentir à toutes les applications, ils peuvent consentir à toutes les applications.
Non authentifié : À partir d'un compte externe, créez une application avec les autorisations à faible risque User.Read et User.ReadBasic.All, par exemple, hameçonnez un utilisateur, et vous pourrez accéder aux informations du répertoire.
Cela nécessite que l'utilisateur hameçonné soit capable d'accepter des applications OAuth d'un locataire externe.
Si l'utilisateur hameçonné est un administrateur qui peut consentir à n'importe quelle application avec n'importe quelles autorisations, l'application pourrait également demander des autorisations privilégiées.
Authentifié : Ayant compromis un principal avec suffisamment de privilèges, créez une application à l'intérieur du compte et hameçonnez un utilisateur privilégié qui peut accepter des autorisations OAuth privilégiées.
Dans ce cas, vous pouvez déjà accéder aux informations du répertoire, donc l'autorisation User.ReadBasic.All n'est plus intéressante.
Vous êtes probablement intéressé par des autorisations qui nécessitent qu'un administrateur les accorde, car un utilisateur ordinaire ne peut pas donner d'autorisations aux applications OAuth, c'est pourquoi vous devez hameçonner uniquement ces utilisateurs (plus d'informations sur les rôles/permissions qui accordent ce privilège plus tard).
Notez que vous devez exécuter cette commande à partir d'un utilisateur à l'intérieur du locataire, vous ne pouvez pas trouver cette configuration d'un locataire depuis un externe. Le cli suivant peut vous aider à comprendre les autorisations des utilisateurs :
Les utilisateurs peuvent consentir à toutes les applications : Si à l'intérieur de permissionGrantPoliciesAssigned vous pouvez trouver : ManagePermissionGrantsForSelf.microsoft-user-default-legacy alors les utilisateurs peuvent accepter chaque application.
Les utilisateurs peuvent consentir aux applications de publishers vérifiés ou de votre organisation, mais seulement pour les autorisations que vous sélectionnez : Si à l'intérieur de permissionGrantPoliciesAssigned vous pouvez trouver : ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team alors les utilisateurs peuvent accepter chaque application.
Désactiver le consentement des utilisateurs : Si à l'intérieur de permissionGrantPoliciesAssigned vous ne pouvez trouver que : ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-chat et ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team alors les utilisateurs ne peuvent consentir à aucune.
Il est possible de trouver la signification de chacune des politiques commentées dans :
Vérifiez les utilisateurs qui sont considérés comme des administrateurs d'application (peuvent accepter de nouvelles applications) :
L'attaque implique plusieurs étapes ciblant une entreprise générique. Voici comment cela pourrait se dérouler :
Enregistrement de Domaine et Hébergement d'Application : L'attaquant enregistre un domaine ressemblant à un site de confiance, par exemple, "safedomainlogin.com". Sous ce domaine, un sous-domaine est créé (par exemple, "companyname.safedomainlogin.com") pour héberger une application conçue pour capturer des codes d'autorisation et demander des jetons d'accès.
Enregistrement de l'Application dans Azure AD : L'attaquant enregistre ensuite une Application Multi-Tenant dans son locataire Azure AD, la nommant d'après l'entreprise cible pour paraître légitime. Il configure l'URL de redirection de l'application pour pointer vers le sous-domaine hébergeant l'application malveillante.
Configuration des Autorisations : L'attaquant configure l'application avec diverses autorisations API (par exemple, Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read). Ces autorisations, une fois accordées par l'utilisateur, permettent à l'attaquant d'extraire des informations sensibles au nom de l'utilisateur.
Distribution de Liens Malveillants : L'attaquant crée un lien contenant l'identifiant client de l'application malveillante et le partage avec des utilisateurs ciblés, les trompant pour qu'ils accordent leur consentement.
Enregistrer une nouvelle application. Elle peut être uniquement pour le répertoire actuel si vous utilisez un utilisateur du répertoire attaqué ou pour n'importe quel répertoire si c'est une attaque externe (comme dans l'image suivante).
Définir également l'URI de redirection sur l'URL attendue où vous souhaitez recevoir le code pour obtenir des jetons (http://localhost:8000/callback par défaut).
Ensuite, créer un secret d'application :
Sélectionner les autorisations API (par exemple, Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read)
Exécuter la page web (azure_oauth_phishing_example) qui demande les autorisations :
Envoyez l'URL à la victime
Dans ce cas http://localhost:8000
Les victimes doivent accepter l'invite :
Utilisez le jeton d'accès pour accéder aux autorisations demandées :
365-Stealer: Consultez https://www.alteredsecurity.com/post/introduction-to-365-stealer pour apprendre à le configurer.
Selon les autorisations demandées, vous pourriez être en mesure de accéder à différentes données du locataire (liste des utilisateurs, groupes... ou même modifier des paramètres) et informations de l'utilisateur (fichiers, notes, e-mails...). Ensuite, vous pouvez utiliser ces autorisations pour effectuer ces actions.
Vérifiez les sections Applications et Service Principal de la page :
Apprenez et pratiquez le Hacking AWS :HackTricks Training AWS Red Team Expert (ARTE) Apprenez et pratiquez le Hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)
