多要素認証（MFA）を導入しているから安心――そう思っていた組織が、気づかないうちにメールボックスを丸ごと覗かれていた。2025年後半から急増しているOAuthフィッシングは、まさにそのシナリオを現実にする攻撃手法です。
本記事では、OAuthフィッシングの仕組みと従来のフィッシングとの違い、実際の被害事例、そして企業が今すぐ実施できる対策を、セキュリティ担当者から経営層まで理解できる言葉でわかりやすく解説します。
結論：OAuthフィッシングはMFAを「突破」しない。だから防ぎにくい
最初に核心をお伝えします。
OAuthフィッシングの最大の特徴は、MFAを回避せずに攻撃を成立させる点にあります。ユーザーは本物のMicrosoftやGoogleの認証画面でパスワード入力とMFA認証を正常に完了します。その後に表示される「アプリへのアクセス許可画面」で「許可」ボタンを押した瞬間、攻撃者は有効なアクセストークンを手に入れます。
パスワードは盗まれていません。MFAも正しく機能しています。それでも攻撃者はメールボックスやクラウドストレージに自由にアクセスできるようになります。これが、従来の対策だけでは検知も防御も難しい理由です。
OAuthフィッシングが急増している背景
OAuthフィッシングの手法が増えているのはなぜでしょうか。ここではその背景について紹介します。
2024〜2026年の攻撃トレンド
2024年中頃、ロシア系のAPTグループ（MicrosoftはStorm-2372として追跡）が、IoT機器向けの「デバイスコード認証フロー」を悪用した攻撃を開始しました。当初は限定的な被害にとどまっていましたが、2025年に入って状況は一変します。
Proofpointの調査によると、2025年9月以降、金融系の脅威アクター（TA2723）がこの手法を本格的に組み込んだことで被害が急拡大しました。同年10月にはMicrosoft 365全般を標的とした大規模キャンペーンが確認され、2026年2月には「EvilTokens」と呼ばれるフィッシング・アズ・ア・サービス（PhaaS）が登場。わずか数週間で米・英・豪・独など340以上の組織が被害を受けました。
攻撃者の多様化
この攻撃の背後には国家支援型のAPTグループ（APT28/Pawn Storm、UTA0304など）から、金銭目的の犯罪組織まで多様なアクターが確認されています。かつては高度な技術を持つ国家レベルの攻撃者が使う手法でしたが、今やPhaaS（フィッシング・アズ・ア・サービス）として提供される時代になっています。参入障壁の低下が、被害件数の急増に直結しています。
OAuth同意フロー（正規の仕組み）
OAuth 2.0は、アプリがユーザーの代わりにクラウドサービスにアクセスするための認可の仕組みです。たとえば「このアプリにGoogleカレンダーの読み取りを許可しますか？」という確認画面がその典型です。流れを整理すると次のようになります。
攻撃者はこの5番のステップを悪用します。ユーザーを偽アプリへの同意に誘導し、正規に署名された有効なアクセストークンを入手するのです。
OAuthフィッシングの仕組み：3つの攻撃パターン
OAuthフィッシングを理解するには、まずOAuth 2.0の正規フローを知る必要があります。
パターン1：認可コードフィッシング（ConsentFix型）
攻撃者はMicrosoft純正アプリ（Azure CLIやGraph APIなど）のIDを装ったURLを作成し、ユーザーを誘導します。ユーザーが本物のMicrosoft認証画面でMFAを完了すると、認可コードが発行されます。ユーザーはフィッシングサイトの指示に従いそのコードを入力（コピー＆ペースト）し、攻撃者はそのコードをMicrosoftのトークンエンドポイントへ送信してアクセストークンを取得します。
パターン2：デバイスコードフィッシング
テレビやIoT機器など、ブラウザ操作が難しいデバイス向けに用意された「デバイスコード認証フロー」を悪用します。攻撃者が自らデバイスコードを取得し、それをメールでユーザーに送りつけます。ユーザーが指定URLでコードを入力しMFAを完了すると、攻撃者のセッションにトークンが返ります。ユーザーは自分が攻撃者を認証したことに気づきません。
パターン3：アプリ同意フィッシング（AppConsent型）
攻撃者が作成した悪意あるOAuthアプリを、AdobeやDocusignなど信頼性の高いサービスに見せかけてユーザーに同意させます。ユーザーが「許可」ボタンを押した瞬間、悪意あるアプリに指定スコープのトークンが発行されます。
従来のフィッシングとの違いを比較する
OAuthフィッシングは、これまでのフィッシングとは違う特徴を多く持っています。ここではその違いを比較します。
| 比較項目 | 従来のフィッシング | OAuthフィッシング |
|---|---|---|
| 何を盗むか | パスワード・認証情報 | アクセストークン（認可権限） |
| MFAの効果 | 有効（侵入を防げる） | 無効（ユーザー自身がMFAを通過させる） |
| 認証画面 | 偽サイト | 本物のMicrosoft/Google画面 |
| パスワード変更後 | アクセス不能になる | トークンが生きていればアクセス継続 |
| 検知の難しさ | 比較的検知しやすい | 正規サインインとして記録され検知困難 |
最も重要な点は「パスワード変更だけでは攻撃を止められない」という事実です。Guardianのレポートでは、攻撃者がMail.Readとoffline_accessのスコープを持つトークンを取得し、被害者がパスワードを変更した後も4日間にわたってメールボックスへのアクセスを継続した事例が報告されています。
攻撃が成功すると何が起きるか
実際にOAuthフィッシングによる攻撃が成功するとどのようなことが起こるのでしょうか。ここでは考えられる攻撃例と被害について紹介します。
取得される権限スコープの例
攻撃者が要求する権限（スコープ）は、攻撃の目的に応じて異なります。よく使われる高リスクなスコープを以下に示します。
| スコープ名 | 内容 |
|---|---|
Mail.Read / Mail.ReadWrite | メールボックスの閲覧・操作 |
Files.ReadWrite.All | OneDrive・SharePointのファイル読み書き |
offline_access | リフレッシュトークン取得（長期アクセス） |
Contacts.Read | アドレス帳の閲覧 |
https://graph.microsoft.com/.default | Graph API経由の広範なアクセス権 |
侵害後に起きる主な被害
攻撃者はトークンを取得した後、次のような活動を行います。
特に「持続化」は深刻です。攻撃者が自身のMFAデバイスを登録してしまうと、被害者がパスワードを変更しても攻撃者側からの再ログインが可能になります。これが判明するのはフォレンジック調査後になることも少なくありません。
OAuthフィッシングを見抜く：攻撃の検出指標
自組織への攻撃を早期に発見するため、以下の指標（IOC）をSIEMやログ監視に組み込むことが推奨されます。
| 指標の種類 | 具体例 | 意味 |
|---|---|---|
| 不審なドメイン | *.yrqwvevbjcfv.es など | 認可コード窃取用のランディングページ |
| 不審なUser-Agent | axios/1.7.9、axios/1.8.2 | Tycoon/AiTMフィッシングキットの痕跡 |
| 悪意あるアプリID（例） | fdcf7337-92bf-4c70-9888-ea234b6ffb0d | 攻撃で使用された登録済みOAuthアプリ |
| 監査ログイベント | OAuth2ConsentGrant、DeviceCodeFlow | 同意付与・デバイスコードフローの発生 |
ただし、これらのURLやアプリIDは攻撃ごとに変わります。そのため「ブラックリストに頼る」だけでなく、「新規に登録されたOAuthアプリへのアラート設定」や「初見のclient_idによる認可取得の検知」といった振る舞い検知のSIEMルールをあわせて整備することが重要です。
企業が今すぐ取るべき5つの対策
対策は技術的なものとユーザー教育の両輪が必要です。ここでは推奨されている5つの対策方法を紹介します。
対策1：デバイスコードフローを条件付きアクセスで無効化
Azure AD（Entra ID）の条件付きアクセスポリシーで、デバイスコード認証フロー全体をブロックします。正規の業務でデバイスコードフローを必要とするケースは限定的なため、多くの組織で即時適用が可能です。
対策2：ユーザーのアプリ同意を制限する
ユーザーが独自にOAuthアプリへ同意できる範囲を縮小します。「認証済みパブリッシャのアプリのみ許可」「管理者の事前承認が必要」といった設定に変更することで、野良アプリへの同意を防ぎます。Microsoftは未認証パブリッシャからのユーザー同意を禁止するガイドラインを公式に示しています。
対策3：テナント内のOAuthアプリを定期レビューする
すでに許可されているOAuthアプリを棚卸しし、不要な権限や使われていないアプリを削除します。特にoffline_accessやFiles.ReadWrite.Allなど広範なスコープを持つアプリは優先的に確認してください。
対策4：ログ監視とSIEMルールを整備する
Microsoft 365の監査ログで、OAuth2ConsentGrantイベントや未知のclient_idによる認可取得を検知するルールを設定します。Microsoft Defender for Cloud Appsの「新規アプリ承認の異常検知ポリシー」も有効な手段です。
対策5：ユーザーへの教育を行う
「本物のMicrosoft画面が表示されても、アプリへのアクセス許可は安易に与えない」というルールを組織全体に周知します。特に以下の点を伝えることが重要です。
インシデント発生時の対応手順
被害を確認した（または疑われる）場合は、以下の優先順位で対応します。
| 優先度 | 対応内容 |
|---|---|
| 1. 特定 | 監査ログで被害ユーザーと不正なOAuthアプリを洗い出す |
| 2. 権限剥奪 | 攻撃者が使ったOAuthアプリを即時無効化・削除する |
| 3. トークン無効化 | Azure AD PowerShellで全セッションを強制終了する（Revoke-AzureADUserAllRefreshToken）。パスワード変更だけでは不十分 |
| 4. 持続化要素の除去 | 攻撃者が登録したMFAデバイス、メール転送ルール、共有フォルダを削除する |
| 5. パスワード変更 | トークン無効化を実施した後に実行する（順番が重要） |
| 6. 調査 | 通信ログ・Azure ADログで攻撃者の行動範囲（送信メール・DL先）を特定する |
| 7. 再発防止 | 条件付きアクセスとアプリ同意ポリシーを見直し、全社に周知する |
最も緊急性が高いのは「3. トークン無効化」です。アクセストークンが生きている限り攻撃者はアクセスを継続できるため、セッションの全切断を最優先で実施してください。
よくある質問（FAQ）
Q. MFAを導入していれば、OAuthフィッシングは防げますか？
いいえ、防げません。OAuthフィッシングはユーザーにMFAを正常に完了させた上で攻撃を成立させます。MFA自体は機能していますが、同意画面の操作で攻撃者にアクセス権を渡してしまいます。MFAはパスワード窃取型の攻撃には有効ですが、この手法には追加の対策が必要です。
Q. 個人でもできる対策はありますか？
はい。まず、メールや通知に記載されたリンクからのアプリ同意要求には必ず疑いを持つことが大切です。また、Microsoftアカウントの「マイアカウント」画面でアプリのアクセス権を定期的に確認し、見覚えのないアプリへの許可を取り消す習慣をつけてください。
Q. このような攻撃はMicrosoft 365だけが対象ですか？
Microsoft 365が最も多く標的にされていますが、GoogleWorkspaceやSalesforceなどOAuth 2.0を使うクラウドサービス全般が対象になり得ます。特にMicrosoft 365は企業利用が多く、攻撃者から見ると取得できる情報の価値が高いため集中的に狙われています。
Q. 攻撃を受けたかどうか、どうすればわかりますか？
Microsoft 365の管理センター（Entra ID）で「エンタープライズアプリケーション」→「アクティビティ」または「監査ログ」を確認してください。見覚えのないアプリへの同意イベント（OAuth2ConsentGrant）があれば要調査です。Defender for Cloud Appsを利用している場合は、アプリガバナンスのダッシュボードで不審なアプリを検出できます。
まとめ
OAuthフィッシングは、MFAという現代のセキュリティ対策の「盲点」を正面から突く手法です。ユーザーは正規の画面でMFAを完了しているため、自分が攻撃されたとは気づきにくい。パスワードを変更しても攻撃者のアクセスは止まらない。この二重の困難さが、被害の長期化につながっています。
対策の核心は「同意フローへの管理者コントロール」と「ログ監視の整備」です。まずは条件付きアクセスでデバイスコードフローを無効化し、ユーザーが独自にアプリを承認できる範囲を制限することから始めてください。
技術的な対策と並行して、ユーザーへの教育も欠かせません。「MFAを通過した＝安全ではない」という認識を組織全体に広めることが、OAuthフィッシング対策の第一歩です。
本記事は、Microsoft公式ドキュメント「Protect against consent phishing」、Cloud Security Alliance、Proofpoint、Volexity、Wiz、Trend Microなどの公開情報をもとに作成しています。
コメント