Az - OAuth Apps Phishing
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Azureアプリケーションは、ユーザーがアプリケーションに同意したときに使用できる権限で構成されています（ディレクトリの列挙、ファイルへのアクセス、またはその他のアクションの実行など）。アプリケーションはユーザーの代理で動作するため、アプリが管理者権限を要求しても、同意したユーザーがその権限を持っていない場合、アプリは管理者アクションを実行できません。
デフォルトでは、ユーザーはアプリに同意できますが、これは設定可能で、ユーザーが選択された権限の確認済みパブリッシャーからのアプリにのみ同意できるようにしたり、ユーザーがアプリケーションに同意する権限を削除することもできます。
ユーザーが同意できない場合、GA、Application Administrator、またはCloud Application Administratorのような管理者が、ユーザーが使用できるアプリケーションに同意することができます。
さらに、ユーザーが低リスクの権限を持つアプリにのみ同意できる場合、これらの権限はデフォルトでopenid、profile、email、User.Read、およびoffline_accessですが、このリストにさらに追加することも可能です。
ユーザーがすべてのアプリに同意できる場合、すべてのアプリに同意できます。
未認証: 外部アカウントから、例えば低リスク権限User.ReadおよびUser.ReadBasic.Allを持つアプリケーションを作成し、ユーザーをフィッシングすると、ディレクトリ情報にアクセスできます。
フィッシングされたユーザーが外部テナントからのOAuthアプリを受け入れることができる必要があります。
フィッシングされたユーザーが任意の権限を持つアプリに同意できる管理者である場合、アプリケーションは特権権限を要求することもできます。
認証済み: 十分な権限を持つプリンシパルを侵害した後、アカウント内にアプリケーションを作成し、特権OAuth権限を受け入れることができる特権ユーザーをフィッシングします。
この場合、すでにディレクトリの情報にアクセスできるため、権限User.ReadBasic.Allはもはや興味深くありません。
管理者が付与する必要がある権限に興味がある可能性が高いです。なぜなら、通常のユーザーはOAuthアプリに権限を与えることができないからです。そのため、そのユーザーのみをフィッシングする必要があります（この特権を付与する役割/権限については後で詳しく説明します）。
テナント内のユーザーからこのコマンドを実行する必要があることに注意してください。外部からテナントのこの設定を見つけることはできません。次のCLIは、ユーザーの権限を理解するのに役立ちます：
ユーザーはすべてのアプリに同意できます: 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 のみが見つかる場合、ユーザーは同意できません。
コメントされたポリシーのそれぞれの意味を見つけることができます:
新しいアプリケーションを受け入れることができるアプリケーション管理者と見なされるユーザーを確認します：
攻撃は、一般的な企業をターゲットにしたいくつかのステップを含みます。以下のように展開される可能性があります：
ドメイン登録とアプリケーションホスティング: 攻撃者は、信頼できるサイトに似たドメイン（例："safedomainlogin.com"）を登録します。このドメインの下に、認証コードをキャプチャし、アクセストークンを要求するために設計されたアプリケーションをホストするサブドメイン（例："companyname.safedomainlogin.com"）を作成します。
Azure ADでのアプリケーション登録: 攻撃者は、ターゲット企業の名前を付けたマルチテナントアプリケーションを自分のAzure ADテナントに登録し、正当性を装います。彼らは、悪意のあるアプリケーションをホストするサブドメインを指すようにアプリケーションのリダイレクトURLを設定します。
権限の設定: 攻撃者は、さまざまなAPI権限（例：Mail.Read、Notes.Read.All、Files.ReadWrite.All、User.ReadBasic.All、User.Read）を持つアプリケーションを設定します。これらの権限は、ユーザーによって付与されると、攻撃者がユーザーの代理で機密情報を抽出できるようにします。
悪意のあるリンクの配布: 攻撃者は、悪意のあるアプリケーションのクライアントIDを含むリンクを作成し、ターゲットユーザーと共有して、同意を与えるように騙します。
新しいアプリケーションを登録します。攻撃されたディレクトリのユーザーを使用している場合は現在のディレクトリのみに、外部攻撃の場合は任意のディレクトリのために登録できます（次の画像のように）。
リダイレクトURIを、トークンを取得するためのコードを受け取る期待されるURL（デフォルトではhttp://localhost:8000/callback）に設定します。
次に、アプリケーションシークレットを作成します：
API権限を選択します（例：Mail.Read、Notes.Read.All、Files.ReadWrite.All、User.ReadBasic.All、User.Read）
権限を要求するウェブページを実行します（azure_oauth_phishing_example)：
URLを被害者に送信する
この場合 http://localhost:8000
被害者はプロンプトを受け入れる必要があります:
アクセストークンを使用して要求された権限にアクセスする:
365-Stealer: https://www.alteredsecurity.com/post/introduction-to-365-stealerを確認して、設定方法を学んでください。
要求された権限に応じて、テナントの異なるデータにアクセスできる可能性があります（ユーザー、グループのリスト...または設定を変更することさえ）およびユーザーの情報（ファイル、ノート、メール...）。その後、これらの権限を使用してこれらのアクションを実行できます。
ページのアプリケーションおよびサービスプリンシパルセクションを確認してください：
Az - EntraID PrivescAWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)
