Az - Illicit Consent Grant
OAuth App Phishing
Azure Applications は ユーザーデータ(基本情報、ドキュメントへのアクセス、メール送信など)へのアクセス許可を求めます。
許可されると、通常のユーザーは**「低影響」権限**のみを承認できます。それ以外の場合は、管理者の同意が必要です。
GA
、ApplicationAdministrator
、CloudApplication
Administrator
および permission to grant permissions to applications
を含むカスタムロールは、テナント全体の同意を提供できます。
管理者の同意を必要としない権限のみが低影響として分類されます。これらは、基本的なサインインに必要な権限であり、openid、profile、email、User.Read、および offline_access です。組織がすべてのアプリに対するユーザーの同意を許可する場合、従業員は自分のプロファイルから上記の情報を読み取るためのアプリに同意を与えることができます。
したがって、攻撃者は悪意のあるアプリを準備し、フィッシングでユーザーにアプリを受け入れさせてデータを盗むことができます。
2 Types of Illicit Consent Grant Attacks
Unauthenticated: 外部アカウントから
User.Read
およびUser.ReadBasic.All
の権限を持つアプリケーションを作成し、ユーザーをフィッシングしてディレクトリ情報にアクセスします。これは、フィッシングされたユーザーが外部環境からのOAuthアプリを受け入れることができる必要があります!
Authenticated: 十分な特権を持つプリンシパルを侵害し、アカウント内にアプリケーションを作成し、特権OAuth権限を受け入れることができる特権ユーザーをフィッシングします。
この場合、すでにディレクトリの情報にアクセスできるため、
User.ReadBasic.All
の権限はもはや興味深くありません。管理者が付与する必要がある権限に興味がある可能性が高いです。なぜなら、通常のユーザーはOAuthアプリに権限を与えることができないため、そのユーザーのみをフィッシングする必要があるからです(後でこの特権を付与する役割/権限について詳しく説明します)。
Check if users allowed to consent
次のPowerShellコマンドは、Azure Active Directory (Azure AD) でユーザーがアプリケーションに同意できるかどうかの同意設定を確認するために使用されます:
ユーザーの同意を無効にする: この設定は、ユーザーがアプリケーションに権限を付与することを禁止します。アプリケーションへのユーザーの同意は許可されません。
検証済みの発行者または組織のアプリに対してのみユーザーが同意できる: この設定は、すべてのユーザーが検証済みの発行者によって公開されたアプリケーションおよび自分のテナントに登録されたアプリケーションにのみ同意できるようにします。特定の権限に対してのみ同意を許可することで、制御の層を追加します。
すべてのアプリにユーザーが同意できる: この設定はより寛容で、管理者の同意を必要としない限り、すべてのユーザーがアプリケーションの任意の権限に同意できるようにします。
カスタムアプリ同意ポリシー: この設定は、特定の組織の要件に合わせて調整できるカスタムポリシーが存在することを示します。これは、アプリの発行者、アプリが要求する権限、その他の要因に基づく制限の組み合わせを含む場合があります。
Illicit Consent Grant Attackの理解
Illicit Consent Grant Attackでは、攻撃者がエンドユーザーを騙して、Azureに登録された悪意のあるアプリケーションに権限を付与させます。これは、アプリケーションを正当なものに見せかけ、被害者が知らずに「承認」ボタンをクリックするように仕向けることで行われます。その結果、Azure ADは攻撃者のサイトにトークンを発行し、攻撃者が被害者のデータ(例えば、メールの読み取りや送信、ファイルへのアクセス)にアクセスして操作できるようになります。組織のアカウントは必要ありません。
攻撃フローの概要
この攻撃は、一般的な企業をターゲットにしたいくつかのステップを含みます。以下はその展開方法です:
ドメイン登録とアプリケーションホスティング: 攻撃者は信頼できるサイトに似たドメインを登録します。例えば、「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を含むリンクを作成し、ターゲットユーザーに共有して同意を得るように仕向けます。
攻撃にツールを利用する
この攻撃は、365-Stealerのようなツールを使用して実行できます。
攻撃前の準備:
攻撃者が被害者組織のユーザーに対してある程度のアクセス権を持っている場合、組織のポリシーがユーザーにアプリの受け入れを許可しているかどうかを確認するかもしれません:
攻撃を実行するために、攻撃者は Azure Tenant に新しいアプリを作成 する必要があります(App registrations 内で)、以下の権限で構成されます:
User.ReadBasic.All
は Microsoft Graph
の Delegated permissions
内にあります。(Application permissions は常に追加の承認が必要です)。
User.ReadBasic.All
は、許可されると組織内のすべてのユーザーの情報を読むことができる権限です。GA
、ApplicationAdministrator
、CloudApplication
Administrator
およびpermission to grant permissions to applications
を含むカスタムロールのみがテナント全体の同意を提供できます。したがって、管理者の同意が必要なアプリを承認させたい場合は、これらの役割のいずれかを持つユーザーをフィッシングする必要があります。
cli を使用してアプリを作成することもできます:
https://www.alteredsecurity.com/post/introduction-to-365-stealer をチェックして、設定方法を学びましょう。
取得した access token は、スコープ User.Read
と User.ReadBasic.All
(要求された権限)を持つ graph endpoint 用です。他のアクションは実行できません(ただし、これらの権限は組織内のすべてのユーザーに関する情報をダウンロードするのに十分です)。
このツールを使用して攻撃を実行することもできます。
Post-Exploitation
ユーザーにアクセスした後、機密文書を盗んだり、バックドア付きの文書ファイルをアップロードしたりすることができます。
References
Last updated