Entra ID 監査ログから OAuth 同意攻撃を追跡:ChatGPT を悪用してユーザーのメール・アカウントを侵害

OAuth Attacks in Entra ID Can Leverage ChatGPT to Compromise User Email Accounts

2026/02/25 CyberSecurityNews — 信頼されるプラットフォームを悪用する新たな手法を、脅威アクターたちは常に模索している。最近になって増加しているのは、OAuth 同意悪用 (OAuth consent abuse) と呼ばれる手法を通じて、Microsoft Entra ID を標的とするケースである。 新たに確認/文書化された攻撃シナリオが示すのは、悪意を持って過剰な権限を要求するサードパーティ製アプリケーション (ChatGPT などに酷似) が、企業ユーザーのパスワードを一切必要とすることなく、受信トレイ (inbox) に密かにアクセスできることだ。 

OAuth (Open Authorization の略) は、ユーザーの許可のもとで、アプリケーションによるデータ・アクセスを可能にする標準プロトコルである。Entra ID では、ユーザーがサードパーティ・アプリを Microsoft アカウントへ接続する際に、アプリが要求する権限を列挙した同意プロンプトが表示される。 

この仕組みを悪用する攻撃者は、Mail.Read のような機密性の高い権限を要求する悪意のアプリケーションを構築する。この権限が承認されると、ユーザーのメール・アカウント内の全メールを閲覧できる完全なアクセス権を、当該アプリは取得することになる。 

Red Canary のアナリストにより確認されたのは、Entra ID テナント内の企業ユーザー “TestUser@ContosoCorp.onmicrosoft.com” が、ChatGPT をサードパーティのサービス・プリンシパルとして追加し、非管理者ユーザーとして Mail.Read/offline_access/profile/openid の OAuth 権限に同意するというインシデントである。

この調査では、当該アプリケーションが OpenAI 所有の正規の ChatGPT であると結論付けられたが、Red Canary が以前に観測した実際のインシデントと同一のシーケンスが明らかになった。 この操作は、2025年12月2日 20:22:16 UTC に発生し、IP アドレス “3.89.177.26” から実行されていた。 

本質的なリスクは、ChatGPT 固有の問題ではなく、攻撃のパターン自体にある。ユーザー同意を経由して、Mail.Read 権限を取得したサードパーティ・アプリケーションは、正規/悪意を問わず、標的の受信トレイ内のすべてのメッセージを読み取ることが可能である。 

実際の攻撃では、脅威アクターが信頼性の高い名称を持つアプリケーションを設計し、フィッシング・リンク経由で配布/誘導する。その結果、被害者がアカウント侵害に気付かないまま、機密メール/内部通信/認証情報が収集されてしまう。 

このリスクを増幅させる要因は、Entra ID がデフォルト設定で、管理者承認を必要としない権限について、標準ユーザーに同意を許可している点にある。そのため、特権を持たない単一の従業員であっても、通常のアプリ接続要求に見えるプロンプトを承認するだけで、組織の機密データが意図せずに露出するという可能性が生じる。

Entra ID 内部での同意攻撃の仕組み

アプリケーション接続へとユーザーが誘導された場合 (フィッシング・メール/ソーシャル・エンジニアリング/正規閲覧を問わない) に、Entra ID 内部では “Add service principal”  と “Consent to application” という 2 つの監査ログイベントが記録される。両イベントは共通の CorrelationId を保持しているため、それらを関連付けるセキュリティ・チームは、単一のユーザー操作まで遡って同意チェーン全体を追跡できる。 

Red Canary の検知アプローチは、新規に導入されたサードパーティ製アプリケーションに対する非管理者同意のうち、悪用されやすい OAuth スコープを 1 つ以上含むものにフラグを立てることから始まる。特に重要な指標は、監査ログ内の AppOwnerOrganizationId フィールドである。この値がテナント自身の ID または既知の Microsoft ファーストパーティ識別子と一致しない場合、そのアプリケーションはサードパーティであり、直ちに疑義対象とすべきである。 

これらの攻撃で頻繁に悪用されるスコープには、Mail.Read/Files.Read.All/Chat.Read/Sites.Read.All が含まれる。 

悪意/未承認の同意付与が確認された場合は、直ちに 2 つの是正措置を実施する必要がある。最初に、”Consent to application” 監査イベントから取得したグラント ID (Grant ID) を使用して、OAuth 許可グラントを無効化する。次に、当該オブジェクト ID (Object ID) を用いてテナントからサービス・プリンシパルを削除する。これらの作業は、いずれも Microsoft Graph PowerShell コマンドで実行可能である。 

予防策として、Microsoft が提供するのは、3 種類の設定可能な同意ポリシー・オプションである。最も安全なアプローチは、すべての同意要求に対して管理者承認を必須とし、非管理者ユーザーによるアプリケーション承認を無効化する設定である。よりバランスの取れた設定では、検証済み発行元に限定し、事前承認済みの低リスク権限のみを許可する。Microsoft が推奨する設定では、同社の最新ユーザー同意ガイドラインが自動適用され、セキュリティと運用利便性の間に実用的な中間点が提供される。