テナントに影響を与える危険な委任アクセス許可

Microsoft は、Microsoft Entra ID のアプリケーションを介して API を公開し、サードパーティアプリケーションが Microsoft Entra ID 自体、また Microsoft 365 (O365) や Azure クラウドなどでアクションを実行できるようにします。「API アクセス許可」はこれらの API へのアクセスを保護します。それらのアクセス許可を必要とするサービスプリンシパルだけに提供してください。アクセス許可の承認は、「アプリケーションロールの割り当て」または「同意の付与」と呼ばれています。

一部の Microsoft API (以下を参照) に対する特定のアクセス許可は、Microsoft Entra ID テナント全体に深刻な脅威をもたらす可能性があります​。これは、これらのアクセス許可を持つサービスプリンシパルが、グローバル管理者などの強力な管理者ロールを持つユーザーよりも目立たないながらも、非常に強力なユーザーになるためです。これを悪用すると、攻撃者は多要素認証 (MFA) をバイパスし、ユーザーパスワードのリセットを避けることができます。

アクセス許可は、正当と見なされると、テナントのアタックサーフェスを拡大させます。アクセス許可が正当でない場合、権限昇格や永続化といった悪意のある試みである可能性があります。

Microsoft ドキュメントアクセス許可と同意の概要で説明されているように、Microsoft Entra ID には 2 種類の API アクセス許可があります。

• アプリケーションのアクセス許可: 関連する露出インジケーター (IoE) [テナントに影響を与える危険なアプリケーションのアクセス許可] を参照してください。
• 委任されたアクセス許可: この露出インジケーター (IoE) は、この 2 番目の種類について調べます​。環境の機密データに対する脅威については、関連する露出インジケーター [データに影響を与える危険な委任アクセス許可] を参照してください。同意は、組織全体を代表してユーザーまたは管理者から得ます。これらのアクセス許可は、サインインしたユーザーの権限 (つまり、アクセス許可とユーザーの権限レベルの共通部分) に基づいてアプリケーションのアクション実行能力を制限することに注意してください。したがって、これらの委任されたアクセス許可の危険レベルは、委任されたアクセス許可戦略を策定するで説明されているように、アプリケーションのユーザーの実際のアクセス許可によって異なります。例: 標準ユーザーが「Group.ReadWrite.All」アクセス許可を委任した場合、アプリケーションは、すべてのグループではなく、そのユーザーが編集可能なグループだけを変更できます。Microsoft はそれらを次のように説明しています。

委任されたアクセス許可は、サインイン済みユーザーが存在し、管理者またはユーザーが同意を適用できるアプリで使用されます。

API アクセス許可はユーザーではなくサービスプリンシパルのみに適用されるため、この露出インジケーター (IoE) はサービスプリンシパルに関してのみ報告を行います。

この IoE は、Microsoft Graph API および従来の Azure AD Graph API へのアクセスを許可する、次の危険なアクセス許可を追跡します。

• AdministrativeUnit.ReadWrite.All: 他のアクセス許可と組み合わせることで、攻撃者が制限付き管理の管理単位 (RMAU) からグローバル管理者を削除し、そのパスワードをリセットすることが可能です。
• Application.ReadWrite.All: 攻撃者が認証情報を、より高い特権を持つアプリケーションに挿入し、グローバル管理者へのなりすましによる不正アクセスが可能になります。
• Application.ReadWrite.OwnedBy: Application.ReadWrite.All と同じですが、報告されたサービスプリンシパルが所有するサービスプリンシパルにのみ適用されます。これは委任アクセス許可として通常は使用できません。
• AppRoleAssignment.ReadWrite.All: 攻撃者が自身に RoleManagement.ReadWrite.Directory アクセス許可を付与することが可能です。
• DeviceManagementConfiguration.ReadWrite.All: Mandiant が (In)tuned to Takeovers: Abusing Intune Permissions for Lateral Movement and Privilege Escalation in Entra ID Native Environments で説明しているように、攻撃者が悪意のある管理スクリプトをデプロイすることにより、Intune が管理するデバイスを侵害することが可能です。これにより、Intune が管理するデバイスを管理者が使用している場合、グローバル管理者への権限昇格が可能になります。
• DeviceManagementRBAC.ReadWrite.All: DeviceManagementConfiguration.ReadWrite.All で説明されているように、攻撃者が Intune の特権ロールを制御下に置いたアカウントに割り当てることで、Intune デバイスで任意のコマンドを実行できるようになります。
• Directory.ReadWrite.All: 攻撃者が自分自身をロール割り当て不可のグループのメンバーとして追加し、Azure クラウドで特権を取得する可能性があります。これにより、Azure リソースにピボットして、Entra ID のグローバル管理者 (例: マネージドアイデンティティ経由) や、さらには Active Directory のドメイン管理者 (例: Azure でホストされているドメインコントローラー VM 経由) への権限昇格につながる可能性があります。
• Domain.ReadWrite.All: 攻撃者は、パスワードや MFA 要求をバイパスしながら、フェデレーションドメインを追加したり、グローバル管理者を含め、任意のユーザーとして認証したりすることが可能です。
• EntitlementManagement.ReadWrite.All: 攻撃者が、グローバル管理者ロールを付与するアクセスパッケージの割り当てポリシーを更新し、承認なしでそのロールを要求することが可能です。
• Group.ReadWrite.All: Directory.ReadWrite.All と同じ
• GroupMember.ReadWrite.All: Directory.ReadWrite.All と同じ
• Organization.ReadWrite.All: 攻撃者は、Entra ID に信頼されたルート証明書を追加し、グローバル管理者に割り当てられたユーザーを含め、任意のユーザーとして認証することが可能です。そのためには、証明書ベース認証 (CBA) が有効になっているか、有効になっていない場合は CBA を有効にする Policy.ReadWrite.AuthenticationMethod アクセス許可が事前に必要になります。
• Policy.ReadWrite.AuthenticationMethod: 攻撃者が、一時アクセスパス (TAP) の認証方法を有効にすることが可能です。これは、併用することで、UserAuthenticationMethod.ReadWrite.All アクセス許可を悪用するための前提条件となる認証方法です。または、攻撃者が証明書ベースの認証 (CBA) を有効にして、Organization.ReadWrite.All アクセス許可を悪用することが可能です。
• Policy.ReadWrite.PermissionGrant: 攻撃者は、制御下に置いたサービスプリンシパルに対してアクセス許可付与ポリシーを作成し、RoleManagement.ReadWrite.Directory アクセス許可を付与して悪用することが可能です。
• PrivilegedAccess.ReadWrite.AzureADGroup: 攻撃者は、制御下に置いたユーザーアカウントを、グローバル管理者ロールに割り当てられたグループのメンバーとして追加することが可能です。
• PrivilegedAssignmentSchedule.ReadWrite.AzureADGroup: PrivilegedAccess.ReadWrite.AzureADGroup と同じ。
• PrivilegedEligibilitySchedule.ReadWrite.AzureADGroup: 攻撃者は、制御下に置いたユーザーアカウントをグローバル管理者ロールに割り当てられたグループに追加可能なアカウントにし、それからメンバーシップをアクティブにして特権を昇格させることが可能です。
• RoleAssignmentSchedule.ReadWrite.Directory: 攻撃者は、アクティブな PIM ロール割り当てを作成することで、制御下に置いたユーザーアカウントにグローバル管理者のロールを割り当てることが可能です。
• RoleEligibilitySchedule.ReadWrite.Directory: 攻撃者は、制御下に置いたユーザーアカウントをグローバル管理者ロールの対象とし、それからそのロールをアクティブにして特権を昇格させることが可能です。
• RoleManagement.ReadWrite.Directory: 攻撃者は、自身をグローバル管理者ロールに昇格させることが可能です。
• RoleManagementPolicy.ReadWrite.AzureADGroup: 攻撃者は、グループロールの割り当てやアクティベーションの制約 (MFA 要求や管理者承認など) を解除し、PrivilegedAccess.ReadWrite.AzureADGroup、PrivilegedAssignmentSchedule.ReadWrite.AzureADGroup、または PrivilegedEligibilitySchedule.ReadWrite.AzureADGroup を利用することが可能です。同じ行程をたどって、厳格な PIM 設定がされているテナントでこれらのアクセス許可も利用することが可能です。
• RoleManagementPolicy.ReadWrite.Directory: 攻撃者は、Entra ロール割り当てやアクティベーションの制約 (MFA 要件や管理者承認など) を解除し、RoleAssignmentSchedule.ReadWrite.Directory または RoleEligibilitySchedule.ReadWrite.Directory を利用することが可能です。同じ行程をたどって、厳格な PIM 設定がされているテナントでこれらのアクセス許可も利用することが可能です。
• User.DeleteRestore.All: 攻撃者はテナントのすべてのユーザーアカウントを削除して使用できないように見せ、その後、緊急アクセス用アカウントの 1 つを復元するためにランサムを要求することが可能です。グローバル管理者への昇格はできませんが、アクセスが中断されます。
• User.EnableDisableAccount.All: 攻撃者はテナントのすべてのユーザーアカウントを無効にして使用できないように見せ、その後、緊急アクセス用アカウントの 1 つを復元するためにランサムを要求することが可能です。グローバル管理者への昇格はできませんが、アクセスが中断されます。
• User.ReadWrite.All: 攻撃者は、「従業員 ID」や「部署」など、制御下に置いたユーザーアカウントの機密性の高いプロパティを編集し、特権 Azure アクセス許可が割り当てられている動的グループ (対応する IoE を参照) のメンバーにすることが可能です。その後、Azure リソースを利用して、最終的にグローバル管理者に昇格する可能性があります。
• User-PasswordProfile.ReadWrite.All: Directory.ReadWrite.All と同じ。
• UserAuthenticationMethod.ReadWrite.All: 攻撃者が一時アクセスパス (TAP) を生成し、テナントの任意のユーザーアカウントを乗っ取ることが可能です。TAP がまだ有効になっていない場合は、Policy.ReadWrite.AuthenticationMethod と組み合わせて、テナントの認証方法として TAP を有効にする必要があります (対応する IoE を参照)。

この IoE は、「Microsoft Entra AD 同期サービス」API のこの危険なアクセス許可も追跡します。

• ADSynchronization.ReadWrite.All: 攻撃者が記録に残らない同期 API を呼び出すことができるようになり、ハイブリッドユーザーアカウントの変更やパスワードのリセットを許してしまいます。

これらの危険なアクセス許可を持つ正当なアプリケーションは、本来必要とされる範囲を超えている可能性があるアクセスを要求します。これは、攻撃者が管理者の同意を不正に取得する「不正な同意の付与」として知られるフィッシング攻撃を示唆する可能性もあります。

攻撃者は無効になっているサービスプリンシパルをすぐに使用できないので、この IoE はデフォルトで無視します。

外部参照:

• Andy Robbins - Azure Privilege Escalation via Azure API Permissions Abuse
• Andy Robbins - Directory.ReadWrite.All Is Not As Powerful As You Might Think
• Carsten Sandker - Untangling Azure Active Directory Permissions II: Privileged Access
• Dirk-jan Mollema - Azure AD privilege escalation - Taking over default application permissions as Application Admin
• Emilien Socchi - Tier 0 permissions (悪用可能性の判断理由を含む詳細は本資料を参照してください)
• Huy Kha - Everything about Service Principals, Applications, and API Permissions
• Lina Lau - How to Backdoor Azure Applications and Abuse Service Principals
• Mandiant Red Team - (In)tuned to Takeovers: Abusing Intune Permissions for Lateral Movement and Privilege Escalation in Entra ID Native Environments
• Marius Solbakken Mellum - Surprising ways to escalate privileges in Entra ID
• Sahil Malik - How to grant admin consent to an API programmatically
• Stian A. Strysse - What's lurking in your Microsoft Graph app role assignments?

アクセス許可を持つ、報告されたサービスプリンシパルが正当であるかどうかを判断​することから始めます。フィッシング攻撃では、表示名を偽装することが技術的に可能ですのでご注意ください。サービスプリンシパルが既知のソフトウェアベンダーに属しているように見える場合、報告されたアプリケーション ID がそのベンダーに属しているかどうかを確認するよう、ベンダーに依頼します。サービスプリンシパルが不正なもので、既知のアプリケーション名になりすましている場合、フォレンジック分析​を実行してください。

• サービスプリンシパルが正当である場合:

  • その所有者とロールを特定して、実際にこれらの危険なアクセス許可が必要かどうかを評価します。
    • これが内部アプリケーションである場合、Microsoft Graph API ドキュメントの同意と認証セクションで概説されているように、その機能を評価し、最小権限の原則に従ってアクセス許可を削減します。このガイダンスに沿って、各 API に必要な最低限のアクセス許可を特定します。
    • これがサードパーティアプリケーションである場合、ベンダーに掛け合って、必須アクセス許可を減らしてもらうか、少なくともそれらのアクセス許可が必要な理由を文書化してもらいます。
  • 必要な Workload Identities Premium ライセンスを持っている場合、徹底的な防御策として、ワークロード ID への条件付きアクセスを使用することを検討してください。これにより、高リスクのサービスプリンシパルを既知の信頼できる場所に限定し、危険なサインインに応じてアクセスを制限できます。

• デフォルトでは、すべてのユーザーが任意のアプリケーションにアクセス許可を委任することができます。つまり、ユーザーが機密性の高いセキュリティに関する決定を行うことができます。対応する [アプリケーションの無制限のユーザー同意] 露出インジケーター (IoE) を参照してください。Microsoft Entra ID には、ユーザーの同意設定をするために、有効にできるオプションがあります。制限を有効にすると、特定のロールを持つ Microsoft Entra ID の管理者が、アプリケーションの同意を管理し、同意要求を評価する必要があります。管理者の同意要求の確認方法も参照してください。

• 特権ユーザーまたは機密ユーザーから委任されたアクセス許可 など、不審なアプリケーションと機密性の高いアクセス許可を特定できるように管理者をトレーニングしてください。これは、大規模なアプリケーションガバナンスの取り組みの一環として行う必要があります。

• 不正と見なしたアクセス許可は削除します。より詳細なフォレンジック調査の実施を計画する場合、Tenable はまず証拠を保存することを推奨しています。Microsoft のガイダンスに従って、エンタープライズアプリケーションに付与されたアクセス許可を確認してください。残念ながら、この機能は Microsoft Entra 管理者ポータルで利用できなくなりました。

Microsoft Entra 管理者ポータルを使って、[ユーザーの同意] タブからアクセス許可を取り消すことはできません。ただし、Microsoft Graph API 呼び出しまたは PowerShell コマンドレットを使用して、これらのアクセス許可を取り消すことができます。詳細については、この記事 の PowerShell と Microsoft Graph のセクションを参照してください。

Microsoft は、アプリケーションの同意付与の調査の実行方法と不正な同意の付与を検出して修復する方法に関する 2 つのガイドも発行しています。

危険なアクセス許可を、アプリケーション ([アプリ登録] メニュー) から削除するのではなく、サービスプリンシパル (ポータルの [エンタープライズアプリケーション] メニュー) から削除するようにしてください。アプリケーションから削除しても、アクセス許可リクエストを削除するだけで、実際のアクセス許可の割り当てには影響しません。

特に DeviceManagementConfiguration.ReadWrite.All アクセス許可に関しては、アクセスポリシーを使用して複数の管理承認を要求することができます。このアプローチにより、管理スクリプトの作成や変更には別のアカウントによる検証が必要になるので、1 つのアプリケーションが悪意のある変更を導入するリスクが軽減されます。

最後に、Graph API アクティビティログを有効にして、Graph API イベントに関する詳細情報をキャプチャします。これは、SOC または SIEM が疑わしいアクティビティを特定したり、攻撃が発生した時にフォレンジック調査を実施したりするのに役立ちます。さらに、サービスプリンシパルのサインインを監視し、特にここで強調されている高リスクのサービスプリンシパルに関して、不審な動作を知らせるアラートを設定します。

名前: テナントに影響を与える危険な委任アクセス許可

コード名: DANGEROUS-DELEGATED-PERMISSIONS-AFFECTING-THE-TENANT

深刻度: High

タイプ: Microsoft Entra ID Indicator of Exposure