Consent Phishing（同意フィッシング）とは ― OAuth悪用攻撃の手口と対策
「このアプリにアカウントへのアクセスを許可しますか？」
Microsoft 365やGoogle Workspaceを使っていると目にする、OAuthの同意画面。多くのユーザーは深く考えずに「許可」をクリックしてしまいます。Consent Phishing（同意フィッシング）は、この心理を悪用したサイバー攻撃です。
2025年後半から被害が急増しており、従来のフィッシング対策（MFA、メールフィルタリング）だけでは防げない点が特に厄介です。
Consent Phishingとは
Consent Phishingは、攻撃者が作成した悪意のあるOAuthアプリケーションに対して、ユーザー自身が「同意」してアクセス権限を付与してしまう攻撃手法です。
従来のフィッシングとの違い
| 項目 | 従来のフィッシング | Consent Phishing |
|---|---|---|
| 狙うもの | パスワード | OAuthアクセストークン |
| MFAで防げるか | はい | いいえ |
| パスワード変更で無効化 | はい | いいえ（トークンが有効なまま） |
| 検知の難しさ | 中 | 高い（正規のOAuthフローを使用） |
| 攻撃の持続性 | 短い（パスワード変更まで） | 長い（トークン失効まで） |
最大の脅威は「MFAを回避する」点です。 ユーザーは自分のアカウントで正規の認証を行い、その上で悪意のあるアプリに権限を「同意」するため、MFAが正常に通過してしまいます。
攻撃の手口
ステップ1：悪意のあるOAuthアプリを作成
攻撃者は、正規のサービスを装ったOAuthアプリケーションを作成します。
- 「Microsoft Teams Connector」「Google Drive Sync」など、もっともらしい名前を付ける
- アプリのロゴやUIを正規サービスに似せる
- アプリの説明文を信頼性のある内容にする
ステップ2：フィッシングメールで同意画面に誘導
ユーザーに以下のようなメールを送り、OAuth同意画面へのリンクをクリックさせます。
- 「ファイルが共有されました。閲覧するにはこちらをクリック」
- 「Teams会議の録画が準備できました。アプリを許可して閲覧」
- 「セキュリティアップデートのため、アプリの再認証が必要です」
ステップ3：過剰な権限を要求
同意画面で、攻撃に必要な権限を要求します。
- メールの読み取り・送信
- ファイルへのフルアクセス
- 連絡先の読み取り
- カレンダーの読み取り
- ユーザープロフィールの読み取り
ステップ4：アクセストークンを取得して悪用
ユーザーが「同意」をクリックすると、攻撃者は以下のことが可能になります。
- ユーザーのメールをすべて読む・送信する
- OneDrive / Google Driveのファイルをダウンロードする
- ユーザーになりすまして社内にフィッシングメールを送る
- 連絡先リストを窃取してさらに攻撃を拡大する
なぜ被害が急増しているのか
MFAの普及が逆に追い風に
MFAが普及したことで、パスワードを盗む従来のフィッシングの成功率が下がりました。攻撃者はMFAを回避できるConsent Phishingにシフトしています。
クラウドサービスの普及
Microsoft 365やGoogle Workspaceの普及により、OAuthの同意画面が日常的に表示されるようになりました。ユーザーは「また何かのアプリの許可か」と深く考えずにクリックする傾向があります。
検知が難しい
- 正規のOAuthフローを使用するため、セキュリティ製品が正常な操作と区別しにくい
- パスワードが漏洩していないため、パスワード漏洩監視では検知できない
- ユーザー自身が能動的に操作しているため、不審な挙動として検知しにくい
Microsoft 365での対策
1. ユーザーの同意を制限する
Microsoft Entra管理センターで、ユーザーがOAuthアプリに同意できる範囲を制限します。
設定手順：
- Microsoft Entra管理センターにログイン
- ID → エンタープライズアプリケーション → 同意とアクセス許可 → ユーザーの同意設定
- 「ユーザーの同意を許可しない」または「確認済みの発行元のアプリのみ同意を許可」を選択
推奨設定：
- 一般ユーザー：アプリへの同意を禁止（管理者承認フローを使用）
- IT管理者：検証済みアプリのみ同意を許可
2. 管理者同意ワークフローを有効化
ユーザーが直接同意できない代わりに、管理者に承認を依頼するワークフローを設定します。
- Microsoft Entra管理センター → エンタープライズアプリケーション → 同意とアクセス許可
- 「管理者の同意要求」を有効化
- 承認者（IT管理者）を指定
3. 既存の同意済みアプリを監査
すでに不審なアプリに同意されていないか確認します。
# 同意済みアプリの一覧を取得
Get-MgServicePrincipal -All | Where-Object { $_.AppOwnerOrganizationId -ne "f8cdef31-a31e-4b4a-93e4-5f571e91255a" } | Select-Object DisplayName, AppId, PublisherName不審なアプリが見つかった場合：
# 特定アプリの同意を取り消し
Remove-MgServicePrincipalAppRoleAssignment -ServicePrincipalId <AppId> -AppRoleAssignmentId <AssignmentId>4. リスクの高いOAuth権限を監視
Microsoft Defender for Cloud Appsを使用して、以下の権限を要求するアプリを監視します。
- Mail.ReadWrite（メールの読み書き）
- Files.ReadWrite.All（全ファイルへのアクセス）
- User.ReadWrite.All（ユーザー情報の変更）
- Directory.ReadWrite.All（ディレクトリの変更）
Google Workspaceでの対策
1. サードパーティアプリのアクセスを制御
Google Workspace管理コンソールで、サードパーティアプリのアクセスを制限します。
- 管理コンソール → セキュリティ → APIの制御 → サードパーティアプリのアクセス
- 「信頼できるアプリ」のみ許可する設定に変更
- 必要なアプリを個別にホワイトリストに追加
2. OAuth同意画面の制限
- 管理コンソール → セキュリティ → APIの制御
- 「内部アプリのみ」に制限
- 外部アプリは管理者の事前承認を必須にする
3. アプリアクティビティの監視
管理コンソール → レポート → トークン でOAuthトークンの発行状況を確認します。
従業員教育のポイント
技術的な対策と並行して、従業員教育が重要です。
「同意画面」の見分け方を教える
- 要求される権限を確認する習慣をつける: 「メールの読み書き」「ファイルのフルアクセス」を要求するアプリは要注意
- アプリの発行元を確認する: 「確認済みの発行元」バッジがあるか
- 不自然なタイミングの同意要求は疑う: メールのリンクから表示される同意画面は特に注意
「許可してしまったかも」と思ったら
- すぐにIT管理者に報告する
- Microsoft 365：myapps.microsoft.com → アプリの権限を取り消す
- Google Workspace：myaccount.google.com → セキュリティ → サードパーティアクセス → 権限を取り消す
- パスワードを変更する（念のため）
インシデント対応
Consent Phishingの被害が判明した場合の対応手順：
- 即座にトークンを失効させる: 該当アプリの同意を取り消し、ユーザーの全セッションを無効化する
- 影響範囲の調査: 監査ログでアプリがアクセスしたデータを確認する
- 横展開の確認: 同じアプリに同意した他のユーザーがいないか確認する
- 被害の評価: メール、ファイル、連絡先など、漏洩した可能性のあるデータを特定する
- 再発防止: ユーザーの同意設定を制限し、管理者承認フローを導入する
まとめ
Consent Phishingは「MFAでは防げない」フィッシング攻撃です。ユーザーが自ら権限を付与してしまうため、技術的な防御と教育の両面から対策する必要があります。
最も効果的な対策は「ユーザーが直接OAuthアプリに同意できないようにする」ことです。管理者承認フローを導入し、IT部門がアプリを事前検証する運用に切り替えましょう。
OAuthアプリの管理やフィッシング対策でお困りの方は、情シス365の無料相談をご利用ください。