（質問１）なぜ攻撃者がアプリを導入しているか説明してください。
ChatGPT:
ChatGPT
攻撃者がアプリを導入する理由は、組織のデータやシステムに対するアクセス権を不正に取得し、持続的に侵害を維持するためです。特に、Microsoft 365環境では、攻撃者は以下のような目的でアプリを導入します。
API権限の悪用: 攻撃者は、アプリに付与されるAPI権限を悪用して、ユーザーのメールボックスやファイルにアクセスすることができます。これにより、メールの読み取りや送信、ファイルのダウンロードなどの不正行為を行えます。また、アプリを通じてデータを窃取し、攻撃をさらに広げることも可能です。
長期間のアクセスを確保: アプリが一度導入されて権限が付与されると、攻撃者はその権限を使って長期間にわたってシステムにアクセスし続けることができます。アプリの存在は、通常のユーザー活動と見分けにくいため、検出されにくく、攻撃者は気づかれずに持続的に攻撃を行うことが可能です。
セキュリティ対策の回避: アプリの導入によって、攻撃者は通常のセキュリティ監視や多要素認証（MFA）を回避できます。アプリが認証を受けると、その後のアクセスは正規のものとして扱われるため、特に注意を払わない限り、不正なアクセスが続く可能性があります。
組織内の拡散: 攻撃者は、不正に導入したアプリを使って、他のユーザーやシステムに対する攻撃を広げることができます。特に、アプリに組織全体のデータやシステムへのアクセス権が付与されている場合、攻撃者はそれを利用してさらに大規模な攻撃を実行できます。
このように、アプリの導入は攻撃者にとって非常に効果的な手段であり、検出を回避しつつ、長期的な不正アクセスを確保するために利用されています。
あなた:
アプリを導入すると、そのアプリ導入の為に乗っ取ったアカウント以上にM365に対してアクセスが可能になるということですか？
ChatGPT:
ChatGPT
はい、その通りです。攻撃者がアプリを導入することで、そのアプリに付与される権限によって、乗っ取ったアカウントが本来持っていた権限以上に、Microsoft 365 (M365) 環境へのアクセスが可能になることがあります。
以下の理由から、アプリを利用することで攻撃者はより広範なアクセスを得ることができます：
アプリの権限範囲が広い: アプリを導入する際、API権限（Graph APIなど）を設定することで、通常のユーザー権限よりも広範な操作が可能です。例えば、メールの読み書き、ファイルの操作、ユーザー情報の取得、カレンダーアクセスなど、アプリに与えられる権限は非常に多岐にわたります。攻撃者はこれを悪用して、対象ユーザー以外のリソースにもアクセスできます。
管理者レベルの権限取得: 一部のアプリは、管理者が承認した場合、M365環境全体に対する管理者レベルの権限を持つことができます。攻撃者が管理者のアカウントを乗っ取るか、管理者の承認を得る形でアプリをインストールできれば、全社的なリソースにアクセスできるようになります。
継続的なアクセス: アプリに一度付与された権限は、ユーザーのセッションやパスワードが変更された場合でも影響を受けないことがあります。これにより、攻撃者は長期間にわたってM365にアクセスし続けることが可能となり、検出を回避しやすくなります。
組織全体のデータにアクセス: アプリが「委任された権限」を持つ場合、アプリはユーザーの代理として動作し、そのユーザーのアクセス権を超えて操作できる場合があります。さらに、「アプリケーションの権限」が与えられると、そのアプリは特定のユーザーに依存せず、組織全体のデータやリソースに直接アクセスできます。
そのため、アプリを導入することで、攻撃者は乗っ取ったアカウントを超えて、M365全体に影響を与える攻撃を仕掛けることが可能になります。このため、組織ではアプリの導入やアクセス権の管理を慎重に行う必要があります。
（質問２）アプリを導入したユーザよりも広い権限をアプリに与えられる理由がわかりません。
ChatGPT:
ChatGPT
アプリが導入したユーザーの権限よりも広い権限を持つことが可能な理由は、Microsoft 365 (M365)のアプリケーション認証と権限付与の仕組みに起因します。以下にその理由を詳しく説明します。
1. アプリケーションの「委任された権限」と「アプリケーションの権限」
M365では、アプリケーションに対して2種類の権限が付与されます：
委任された権限（Delegated Permissions）: これは、アプリがユーザーの代理として実行される際に、そのユーザーの権限を引き継ぐものです。この場合、アプリはユーザーが持っている権限の範囲内でのみ操作を行います。
アプリケーションの権限（Application Permissions）: これは、特定のユーザーに依存せず、アプリ自体に直接付与される権限です。これにより、アプリは組織全体のリソースにアクセスできるようになり、個々のユーザーの権限を超えて操作が可能になります。この権限は通常、グローバル管理者やセキュリティ管理者などが承認した場合にのみ付与されます。
2. 管理者によるアプリ承認プロセス
ユーザーがアプリを導入する際、アプリがリクエストする権限がユーザーの権限を超える場合でも、そのアプリが「管理者の承認」を得ることで、組織全体に対して広範な権限が付与されることがあります。これは以下の理由によります：
アプリが複数ユーザーやリソースに対して操作を行う必要がある場合: 例えば、社内で使われるアプリが全社員のメールボックスやファイルにアクセスする必要がある場合、管理者がアプリに組織全体のリソースへのアクセス権を与えることが求められます。
システムやサービスの自動化を目的とした高い権限: 一部のアプリは、システム管理やIT運用の効率化のために、ユーザーの権限を超えて動作することが必要です。このような場合、アプリには特定の管理者権限や、ユーザーの行動に依存しない権限が必要になります。
3. OAuth 2.0の認可モデル
Microsoft 365はOAuth 2.0認証フレームワークを使用しており、これによってアプリケーションに対して特定の権限が明示的に付与されます。アプリはアクセスをリクエストする際に、アクセスしたいリソースや必要な権限を指定します。管理者がそのリクエストを承認すると、アプリは指定された権限を持って動作できるようになります。
広範な権限をリクエストできる: アプリは設計上、ユーザーの権限を超える範囲のリソースや操作にアクセスを求めることができます。たとえば、あるアプリはメールの読み取りやファイルの操作だけでなく、ユーザーやグループの管理、設定変更といった高レベルの権限を要求する場合があります。
4. セキュリティリスクの可能性
この仕組みによって、ユーザーが悪意のあるアプリを導入し、管理者がそのアプリの権限リクエストを承認してしまうと、攻撃者はそのアプリを利用して、ユーザーの持つ権限を超えたアクセスや操作を行うことが可能になります。このため、組織はアプリの権限リクエストを厳密に管理し、承認プロセスを強化することが重要です。
結論
アプリがユーザーよりも広範な権限を持つ理由は、Microsoft 365の権限付与モデルに基づいており、特に「アプリケーションの権限」が与えられると、ユーザーの権限を超えるアクセスが可能になるためです。これにより、業務上必要な自動化や複数リソースの管理が可能になりますが、同時にセキュリティリスクも存在するため、権限の管理と監査が非常に重要です
（質問３）なぜ、ユーザの権限を超える権限を持つアプリを管理者は承認してしまうのですか？
ChatGPT:
ChatGPT
管理者がユーザーの権限を超える権限を持つアプリを承認してしまう理由はいくつかあります。多くの場合、業務上のニーズや利便性、安全な運用に対する誤った認識が原因となっています。以下に具体的な理由を挙げます。
1. 業務上のニーズ
一部のアプリは、業務を効率化したり、組織全体で利用するために、ユーザーの権限を超える範囲のアクセスが必要になります。例えば、以下のようなシチュエーションがあります。
全社的なツールの導入: メールの自動配信、ファイル管理、チームコラボレーションなど、複数のユーザーやリソースにアクセスする必要があるアプリは、組織全体に対してアクセス権を要求することがあります。この場合、管理者はそのアプリが業務に必要であると判断し、広範な権限を承認することになります。
IT自動化ツール: 例えば、ユーザー管理やシステム監視、バックアップなどを自動化するためのアプリケーションは、管理者レベルの権限を必要とします。こうしたツールは、通常のユーザーが持つ権限を超えて、複数のリソースやデータにアクセスする必要があるため、管理者はその機能を利用するためにアプリの権限を承認します。
2. 権限要求の内容を理解していない
アプリがリクエストする権限の詳細を理解しないまま承認してしまうことがあります。技術的に複雑な権限設定や、アプリが要求するAPI権限が正確に何を意味するかがわかりにくいため、以下のような状況が生じます。
過剰な権限要求: 一部のアプリは、実際には不要な範囲まで権限を要求することがあります。管理者がこの権限が本当に必要かどうかを精査せずに承認してしまうと、結果としてアプリがユーザーの権限を超える操作ができるようになってしまいます。
技術的な専門知識の欠如: 管理者がセキュリティや権限管理に対する十分な知識を持っていない場合、権限要求が過剰であるかどうかを判断できないことがあります。特に、小規模な組織や技術に詳しくない管理者が対応する場合、アプリのリクエストを十分に理解せずに承認してしまうことがあります。
3. 利便性の優先
管理者は、業務効率化や生産性向上のために、利便性を優先してアプリを承認してしまうことがあります。以下のような状況がその一例です。
時間的制約: インシデント対応や日常の業務に忙殺されている管理者が、アプリの権限リクエストを詳しく検討する時間がなく、急いで承認してしまう場合があります。特に、業務に重要なアプリであると判断した場合、その審査を簡略化してしまうことがあります。
利便性の追求: 一部の管理者は、アプリが提供する利便性や効率性を重視し、セキュリティリスクを軽視することがあります。特に、ビジネス部門からの要望が強い場合、権限の過剰さを見過ごしてしまうことがあります。
4. 信頼性への誤った安心感
管理者が、アプリを提供しているベンダーや開発者を信頼している場合、権限に対する警戒心が薄れることがあります。
信頼されているベンダーのアプリ: Microsoft 365環境に導入される多くのアプリは、有名なベンダーや一般的に使用されているソフトウェアによって提供されます。管理者はこれらのベンダーを信頼し、そのアプリが求める権限を深く検討せずに承認してしまうことがあります。
マーケットプレイスの信頼: Microsoftの公式マーケットプレイスで公開されているアプリに対して、管理者は「安全」と誤って信じることがありますが、実際にはアプリの権限要求が過剰であることもあり得ます。
5. セキュリティプロセスの甘さ
組織内でアプリの権限管理に関するプロセスが整備されていない場合、管理者が不適切に広範な権限を付与してしまうことがあります。
承認フローの欠如: 多くの組織では、アプリの権限リクエストを承認する際に複数のチェックが行われるべきですが、こうしたプロセスが曖昧な場合、管理者の一存で承認が行われてしまいます。
ログとモニタリングの不備: 適切な監査ログやモニタリングがないと、アプリがどのような権限でどのリソースにアクセスしているかを追跡できません。そのため、広範な権限を持つアプリが問題を引き起こしても、管理者がそれに気付かない場合があります。
結論
管理者がユーザーの権限を超えるアプリを承認してしまうのは、業務上の必要性や利便性を優先する場合、権限の内容を正確に理解していない場合、信頼感に基づいた誤った判断、または承認プロセスやセキュリティ管理の不備などが原因となります。このため、アプリ導入時には、リクエストされる権限を慎重に審査し、必要最小限の権限を付与することが重要です。
（質問４）ユーザーがアプリを導入する際、アプリがリクエストする権限がユーザーの権限を超える場合でもユーザーが承認できることはありますか？
ChatGPT:
ChatGPT
通常、ユーザーがアプリを導入する際に、アプリがリクエストする権限がユーザー自身の権限を超える場合、ユーザーはその権限を自分で承認することはできません。これは、Microsoft 365 (M365) 環境において、ユーザーが持つ権限以上のアクションやリソースアクセスをアプリがリクエストする場合、管理者の承認が必要になる仕組みがあるためです。
以下に、その仕組みについて詳しく説明します。
1. アプリ権限に対する管理者の承認プロセス
M365では、ユーザーがアプリを導入する際、アプリが以下のような広範な権限をリクエストする場合、ユーザーの権限では承認できず、必ず管理者の承認が求められます。
組織全体のリソースに対するアクセス: アプリが組織内のすべてのユーザーのメールやファイル、カレンダーにアクセスするような権限をリクエストする場合、ユーザーの権限を超えているため、管理者がそのリクエストを審査し、承認する必要があります。
アプリケーションの権限（Application Permissions）: アプリがユーザーに依存せず、システム全体で動作する権限（例えば、全ユーザーのデータを管理する権限）を要求する場合、ユーザーがこの権限を承認することはできません。管理者が明示的に承認しなければ、アプリはこれらの操作を実行できません。
2. ユーザーが承認できる範囲
ユーザーが自分の権限内で承認できるのは、通常、以下のような「委任された権限（Delegated Permissions）」の範囲に限定されます。
ユーザーの個人データへのアクセス: 例えば、アプリがそのユーザーのメールやカレンダー、OneDriveファイルなど、ユーザー自身がアクセス可能なデータに対してアクセスをリクエストする場合、ユーザーは自分のアカウントに関する権限を承認できます。この場合、アプリはそのユーザーの代理として動作し、ユーザーが持つ権限の範囲内で操作します。
ユーザーがアクセスできるリソースの管理: アプリがユーザーの個人データやアクセス権限のあるリソース（メールボックス、カレンダー、ファイルなど）に対して操作を行う場合、ユーザーはこの範囲内での承認が可能です。ただし、組織全体のリソースに影響を与える権限は承認できません。
3. 管理者承認が必要になるケース
以下のような場合には、ユーザーの権限を超えるため、管理者の承認が必要です。
全社的なアクセス要求: アプリが複数ユーザーのデータや組織全体のリソースにアクセスする場合、たとえば全社員のメールボックスにアクセスできるような権限をリクエストする場合、管理者の承認が必須となります。
セキュリティやコンプライアンスに関する権限: アプリがユーザーの権限を超えて、セキュリティやコンプライアンスに影響を与える操作を行う場合、例えば、ユーザーアカウントの管理や監査ログのアクセスなど、これらの権限は管理者の承認が必要です。
4. 管理者が承認を行うプロセス
ユーザーがアプリを導入し、権限の承認が必要な場合、通常、以下のプロセスで管理者が承認します。
ユーザーのリクエスト: ユーザーがアプリを導入し、権限をリクエストすると、管理者に承認リクエストが送信されます。
管理者の確認: 管理者はアプリがリクエストしている権限を確認し、それが適切であるかどうかを審査します。例えば、そのアプリが組織全体のデータにアクセスする必要があるかどうか、またその権限が適切な範囲内かを検討します。
承認または拒否: 管理者は、権限が必要と判断した場合に承認し、アプリに対してリクエストされた権限が付与されます。逆に、不要または過剰な権限がリクエストされている場合、承認を拒否することも可能です。
5. セキュリティリスクと管理者の責任
このプロセスを適切に管理しないと、過剰な権限を持つアプリが導入され、組織全体に対するセキュリティリスクが発生する可能性があります。特に、アプリが管理者の承認を受けて広範な権限を持つ場合、攻撃者に利用されるリスクが高まります。そのため、管理者はアプリのリクエストを慎重に審査し、適切な権限管理を行うことが重要です。
結論
ユーザーは、自分の権限の範囲内でアプリの権限を承認することができますが、ユーザーの権限を超えるようなアプリの権限リクエストは、必ず管理者の承認が必要です。これにより、組織のセキュリティを保ちながら、適切な権限が管理される仕組みになっています。
（質問５）管理者の確認を回避する設定ができますか？
ChatGPT:
ChatGPT
Microsoft 365 (M365) 環境では、ユーザーがアプリを導入する際に、管理者の確認や承認を回避する設定を行うことは推奨されていませんが、一部の設定によって、結果的に管理者の承認を必要としない状況が発生することがあります。これは、組織内のアプリケーション管理や権限設定が適切に制御されていない場合に起こり得ます。以下に、そのような設定やリスクについて説明します。
1. 「ユーザーによるアプリケーションの登録を許可する」設定
Azure Active Directory (Entra ID) では、ユーザーが自分でアプリケーションを登録できる設定が存在します。この設定が有効になっていると、ユーザーがアプリを自由に登録し、その際に一部の権限をリクエストすることが可能になります。具体的には、以下の設定です。
設定場所: Azureポータル > Microsoft Entra ID > 「ユーザー設定」 > 「ユーザーはアプリケーションを登録できる」
デフォルト設定: この設定が「はい」になっていると、通常のユーザーもアプリを登録でき、そのアプリがリクエストする権限に対して管理者の承認を必要としない場合があります。
この設定によって、ユーザーは自分でアプリケーションを導入し、組織内で使用できるようになりますが、権限が過剰であったり、悪意のあるアプリを導入するリスクも高まります。
2. ユーザーによるアプリケーションの同意を許可する設定
Azure Active Directoryには、「ユーザーはアプリケーションに同意できるかどうか」を制御する設定があります。これが適切に管理されていない場合、ユーザーが自分の権限を超えるアプリに同意してしまうリスクがあります。
設定場所: Azureポータル > Microsoft Entra ID > 「エンタープライズ アプリケーション」 > 「同意とアクセス許可」 > 「ユーザーの同意を許可しない」
リスク: この設定が「ユーザーの同意を許可する」になっていると、ユーザーがアプリに対して広範な権限を与えることができ、結果的に管理者の承認を回避してしまうことがあります。たとえば、メールやカレンダーへのアクセスをリクエストするアプリにユーザーが同意することが可能です。
3. アプリケーション同意ポリシーの欠如
Azure ADには、管理者がユーザーのアプリ同意を制限する「アプリケーション同意ポリシー」を設定する機能があります。このポリシーを適切に設定していない場合、ユーザーが自由にアプリに対して同意を行い、管理者の介入なしに広範な権限をアプリに付与できるようになるリスクがあります。
ポリシー設定の場所: Azureポータル > Microsoft Entra ID > 「エンタープライズ アプリケーション」 > 「同意とアクセス許可」 > 「ユーザー同意設定」
ポリシー例: 例えば、ユーザーが個人データのみにアクセスできるアプリに対して同意できるように制限し、全社的なリソースにアクセスする権限を要求する場合は管理者承認を求める設定ができます。このポリシーを設定していないと、ユーザーが自由に同意してしまう状況が発生します。
4. 管理者の確認を回避するリスク
仮に上記のような設定を緩めると、ユーザーが過剰な権限を持つアプリを導入し、結果的に管理者の承認を回避する形になってしまいます。これにより、以下のリスクが発生します。
不正アプリの導入: 悪意のあるアプリが、ユーザーの知らないうちに過剰な権限を取得し、組織のデータにアクセスする可能性があります。
データ漏洩やセキュリティ侵害: 管理者が関与しないまま、ユーザーがアプリに過剰なアクセスを許可することで、重要な情報が漏洩したり、組織のセキュリティが脆弱になる可能性があります。
5. 推奨される対策
管理者が確認を回避される事態を防ぐためには、以下の対策が推奨されます。
アプリケーション登録や同意の制限: 「ユーザーはアプリケーションを登録できる」や「ユーザーの同意を許可する」設定を無効にし、すべてのアプリ登録と同意に対して管理者の承認を必要とする設定に変更します。
アプリケーション同意ポリシーの導入: 組織のポリシーに基づき、ユーザーが同意できるアプリの権限範囲を制限し、広範な権限を要求する場合は必ず管理者が承認するように設定します。
監査とモニタリングの強化: アプリケーションの権限付与や同意に関する活動を監視し、過剰な権限を要求しているアプリの導入を監査できるようにします。また、定期的なセキュリティレビューを実施し、リスクを早期に発見・対処します。
結論
設定によっては、ユーザーがアプリに対して過剰な権限を付与し、管理者の確認を回避することが可能になる場合があります。ただし、これはセキュリティリスクを高める行為であり、組織のセキュリティポリシーに基づいて、必ず管理者の承認を求めるような設定を導入することが重要です。
（質問６）攻撃者はその広い権限を持つアプリをどうやって実行させるのですか？APIを使って外部から命令を出すのでしょうか？
ChatGPT:
ChatGPT
はい、攻撃者は広い権限を持つアプリを実行する際に、APIを使用して外部から命令を出すことが一般的です。具体的には、Microsoft 365やAzure Active Directory（Entra ID）が提供するAPI、特にMicrosoft Graph APIなどを通じて、リモートでアプリケーションを操作し、組織内のデータやリソースにアクセスすることができます。
以下に、攻撃者がAPIを使用してアプリをリモートで操作する方法と、その具体的な手法を説明します。
1. OAuth 2.0 トークンを使った認証とアクセス
アプリがMicrosoft 365に登録されると、攻撃者はOAuth 2.0プロトコルを利用してアクセス・トークンを取得し、そのトークンを使ってAPIを通じてシステムにアクセスします。これが、外部からアプリを制御する基本的な流れです。
認証とトークンの取得: 攻撃者は、アプリに付与された権限（例えば、メールの読み書き、ファイルの操作など）に基づいて、OAuth 2.0の認可フローを通じてトークンを取得します。このトークンは、Microsoft Graph APIなどのAPIに対するアクセス権を与えるものです。
APIリクエストの実行: トークンを取得した後、攻撃者はこのトークンをAPIリクエストに添付し、Microsoft 365環境に対してさまざまなコマンドをリモートで送信します。たとえば、特定のユーザーのメールボックスにアクセスしたり、SharePointやOneDriveに保存されたファイルをダウンロードしたりすることが可能です。
2. Microsoft Graph APIの利用
Microsoft Graph APIは、Microsoft 365やAzure Active Directoryのデータや機能に対してプログラム的にアクセスできる強力なAPIです。攻撃者は、このAPIを使って組織のデータにアクセスし、不正な操作を行います。
メールへのアクセス: 攻撃者はGraph APIを使って、ユーザーのメールボックスにアクセスし、メールを取得したり、送信したりできます。例えば、/me/messages エンドポイントを使って、対象ユーザーのメールを読み取ることができます。
ファイル操作: Graph APIを使って、OneDriveやSharePoint Onlineに保存されたファイルにアクセスし、ダウンロード、削除、または他の不正操作を行います。これも、APIエンドポイント（/me/drive/rootなど）を通じて実行されます。
ユーザー管理: もしアプリにユーザー管理やセキュリティ設定の変更に関する権限が与えられている場合、攻撃者はGraph APIを使って、ユーザーアカウントの権限を変更したり、MFAを無効化したりすることができます。
3. リモートでの操作が可能な理由
アプリが一度認証され、適切な権限が付与されると、攻撃者はMicrosoft Graph APIや他のAPIを使って、リモートからアプリを通じて操作を行うことができます。これには以下の理由があります。
クラウド環境の特性: Microsoft 365やAzureはクラウドサービスであり、インターネットを通じてアクセスが可能です。このため、攻撃者は物理的なネットワーク内にいなくても、クラウドを介してアプリにアクセスし、権限を利用して操作できます。
認証トークンの持続性: OAuth 2.0トークンは有効期間があり、その間は攻撃者が何度でもAPIリクエストを送信してアプリを操作することができます。また、トークンのリフレッシュ機能を利用して、長期間にわたってアクセスを維持することも可能です。
4. C2サーバーによる命令の自動化
攻撃者は、APIを介してアプリを手動で操作するだけでなく、Command & Control (C2) サーバーを使って自動的に命令を送ることもあります。C2サーバーは、攻撃者がリモートでコマンドを発行し、感染したシステムやアプリを自動的に制御する仕組みです。
自動化された攻撃: 攻撃者はC2サーバーにプログラムを設定し、定期的にMicrosoft Graph APIを呼び出してデータを収集したり、システムの設定を変更したりすることができます。これにより、攻撃が持続的かつ広範に展開されることが可能になります。
攻撃の拡大: C2サーバーを使うことで、組織内での攻撃を自動的に拡大し、新しいターゲットに対して不正アクセスやデータ窃取を行うことができます。
5. アプリを利用した隠密性の高い攻撃
攻撃者は、正規のアプリがAPIを利用して操作を行っているように見せかけることで、セキュリティソリューションに検知されにくくすることができます。
正規のAPIトラフィックの悪用: アプリは通常のユーザー活動と同様にMicrosoft 365やAzureにアクセスするため、攻撃者がアプリを通じて行う不正操作は、正規のトラフィックとして見えることがあります。このため、異常なアクティビティを発見するのが難しくなります。
システム管理者の目を欺く: 攻撃者は、アプリの名前や動作を正規のビジネスプロセスに似せることで、システム管理者が不正を見過ごしてしまう可能性を高めます。こうした手法は、APT（高度持続的脅威）攻撃においてよく使われます。
6. フィッシングやソーシャルエンジニアリングの活用
攻撃者はアプリの権限を利用して、フィッシングメールを送信したり、組織内でのさらなる不正アクセスを図ることがあります。
内部フィッシング: 攻撃者は、アプリの権限を使って信頼されるユーザーのメールアカウントからフィッシングメールを送信し、さらに他のユーザーを騙してアカウント情報を盗みます。これにより、組織全体に攻撃が広がる可能性があります。
結論
攻撃者は、広範な権限を持つアプリを導入した後、主にAPI、特にMicrosoft Graph APIを利用して外部から命令を出し、組織内のデータやシステムに対して操作を行います。OAuth 2.0を使った認証トークンの取得により、攻撃者はリモートでアプリを実行し、持続的なアクセスやデータ窃取、さらなる攻撃の拡大を図ります。このため、アプリの権限管理とAPIアクセスの監視が重要です。
コメントを残す