OAuth同意が“MFAを通過した後”を突く──EvilTokensが示したリフレッシュトークン窃取の現在地

今日の深掘りポイント

• ユーザーの「同意」は、攻撃者にとって最短の永続化ルートになり得ます。MFAを回避するのではなく、MFA“後”の同意で有効なリフレッシュトークンを奪うのが本質です。
• OAuth 2.0のデバイスコードフローは、正規のマイクロソフトドメイン上のサインインと同意を伴うため、ユーザーの警戒心を下げやすいです。
• PhaaS化で手口が量産可能になり、短期間・多組織に波及する拡散力が高まっています。貴社のリスクは“個別の標的化”より“量で押し込まれる”方向にシフトしています。
• 入口対策（MFA強化）では止まりません。権限付与（Consent）とトークン寿命管理、アプリ同意ポリシー、検知・失効の運用が新たな第一線になります。
• メトリクス全体像からは、発生確度・即時性・実務上の対処可能性がいずれも高い領域に位置づきます。訓練強化だけでなく、同意ポリシーとトークン運用の構造的見直しを“すぐに”始めるべき局面です。

はじめに

2026年2月に登場したとされるフィッシング・アズ・ア・サービス（PhaaS）「EvilTokens」は、Microsoft 365のデバイスコード方式とOAuth同意の“押しやすさ”を突き、ユーザーが正規のMFAを完了したと信じ込ませた上で有効なリフレッシュトークンを奪取したと報じられています。公開情報では、5週間で5カ国・340超の組織に影響を与えた可能性が示されています。ユーザーは疑わしいサイトではなく正規のドメインでコード入力と同意を行うため、従来の「怪しいURLを避ける」訓練が効きづらいのが特徴です。
参考情報としては、報道ベースの技術解説がまとまっています。一次情報の公開は限定的ですが、攻撃の焦点が「同意とトークン」に移っていることは、今回の事案が示す強いシグナルと言えます。

• The Hacker News: The New Phishing Click: How OAuth Consent Renders MFA Useless（2026-05）
  https://thehackernews.com/2026/05/the-new-phishing-click-how-oauth.html

深掘り詳細

事実関係（公開情報から読み解けるポイント）

• PhaaS「EvilTokens」は、ユーザーに正規のMicrosoft 365サインイン（デバイスコード）とMFAを完了させる流れを踏ませつつ、背後で攻撃者のアプリに対する同意を取得し、リフレッシュトークンを確保する手口と報じられています。
• デバイスコードフローは、画面を持たない機器やCLI等向けの正規フローで、ユーザーはmicrosoft.com配下の正規ページでコード入力・認証・MFA・同意を行います。結果として「自分は正しい手順でMFAを通過した」という強い安心感が生まれやすいです。
• 一度付与されたリフレッシュトークンは、ユーザーの認証情報を再度盗むことなく長期的なアクセス維持に使われ得ます。オフラインアクセス（offline_access）等のスコープが絡むと、セッションが切れにくい構造的な永続化ポイントになります。
• 報道上の規模感（短期間で多国・多数組織）から、攻撃TTPがテンプレ化され、簡便に再利用できる“サービス化”の性質を帯びていることが示唆されます。

編集部インサイト（構造的課題と実務的示唆）

• MFAを“破る”のではなく、“MFAの後”にやってくる同意が新たな攻撃面です。ユーザーのメンタルモデルは「MFAを通れば安全」になりがちですが、OAuthの世界では「MFA≠最終防衛線」です。最終防衛線は“誰に何を委任するのか（Consent）”にあります。
• デバイスコードは「正規ドメインでの操作」を軸に社会的エンジニアリングを強化します。URLの目視チェックやTLSロックアイコンといった“古典的な指さし確認”は、ここでは機能しづらいです。
• 防御の主戦場は、同意ポリシー・スコープ設計・トークン寿命戦略・失効運用・ログの継続監視に移ります。訓練は重要ですが、訓練だけでは“クリック疲れ”に勝てません。
• 実務では、ユーザーによる同意の権限をどこまで許可するか（誰が・どの種類の権限を・どの発行者のアプリに）、そして付与されたリフレッシュトークンをどうモニタし、どのイベントをトリガーに全失効するかを、運用設計として具体に落とす必要があります。
• PhaaS化は“手口の再現性と速さ”を高め、SOC側には“発見と無効化の速さ”が求められます。入口検知が薄くなる分、サインイン／同意イベント／トークン使用のテレメトリを、平時から相関できる運用基盤の有無が決定打になります。

脅威シナリオと影響

以下は編集部の仮説に基づくシナリオとMITRE ATT&CK準拠の位置づけです。実環境ではテナント設定や統制レベルにより変動します。

• シナリオA：業務アカウントの持続的侵害とBEC（ビジネスメール詐欺）連鎖

  1. フィッシングでユーザーにデバイスコード入力を促す（ATT&CK: Phishing, T1566.002）。
  2. 正規サインイン・MFA後に攻撃者アプリへ同意が成立し、リフレッシュトークンを取得（Credential Access: Steal Application Access Token, T1528）。
  3. Graph/Exchange API経由でメールボックス・ファイルへ継続アクセス（Collection/Exfiltration Tactics）。
  4. ルール改ざん（自動転送/隠蔽）によるBEC準備（Defense Evasion/Collection）。
  5. 取引先に対するなりすまし請求・振込誘導で金銭被害に波及（Impact）。

• シナリオB：重要部門の横断的覗き見と情報優位の獲得

  1. 同意で得た長期トークンを使い、共有ドライブ/Teams/予定表/メールを断続的に閲覧。
  2. ログイン頻度を抑え、夜間や休日にAPI呼び出しを分散（Defense Evasion）。
  3. 広報前の機密や対外戦略情報を先取りし、競争・交渉・地政学的優位を確保（Impact: Competitive Advantage）。

• シナリオC：特権近傍の権限連鎖（稀だが高インパクト）

  1. 最初はユーザー権限の同意だが、部門アプリ管理者や影響範囲の広いサービスへの同意に横展開。
  2. ポリシーの粗いテナントでは、高感度スコープ（Mail.ReadWrite、Files.ReadWrite.All、Directory.Read.All等）に到達し、組織横断のデータ面が開口。
  3. 運悪く特権アカウントに同意が刺さると、監査や検知の網目を一気にすり抜ける恐れ（Defense Evasion/Persistence）。

ATT&CKの観点（仮説）:

• 初期アクセス: T1566.002 Spearphishing Link
• 資格情報/トークン窃取: T1528 Steal Application Access Token
• 永続化: リフレッシュトークンによるセッション維持（Persistenceタクティクス）
• 防御回避・発見回避: ログイン頻度の抑制、API分散アクセス
• 収集/流出: SaaS APIによる断続的なデータ持ち出し

メトリクス全体像からは、攻撃の確度・即時性・運用的な対処可否がいずれも高い一方で、ポジティブ要素（抑止材料）は弱い配置に見えます。つまり「来る可能性が高く、すぐ来て、手は打てるが、放置すれば深手」という領域です。SOCは“入口の異常”より“同意・トークン・API利用の異常”を優先監視対象に繰り上げるべき局面です。

セキュリティ担当者のアクション

“訓練を強化する”で終わらせず、構造的コントロールと運用失効の仕組みまで一気通貫で整えることを推奨します。以下は優先度順の提案です。

• すぐにやるべきこと（インシデント予防・即応）

  • ユーザー同意ポリシーの見直し
    • 一般ユーザーのアプリ同意を原則禁止、もしくは「検証済み発行者＋低影響スコープ」に限定し、管理者承認ワークフローを必須化します。
    • offline_accessや広範な読み書き系スコープはユーザー同意不可にし、管理者レビューを通す設計にします。
  • サインイン/同意/トークン利用の監視項目を定義
    • 直近30～90日の「新規アプリ同意イベント」「未知/未承認アプリのトークン使用」「デバイスコードによるサインイン」を棚卸します。
    • 既知正常値（曜日・時間帯・APIコール量・利用アプリ）を可視化し、逸脱を検知ルール化します。
  • 強制失効の標準手順を確立
    • 影響アカウントに対し、リフレッシュトークンの一括失効（サインインセッション失効）を即時に打てる運用を整えます。
    • 問題のサービスプリンシパル（悪性アプリ）を特定し、同意の取り消し・ブロック・削除の手順をプレイブック化します。

• 設定強化（構造的コントロール）

  • 条件付きアクセス（CA）の設計見直し
    • 高感度リソース（メール、ストレージ、ディレクトリ）のアクセスに対し、同意済みアプリ経由のAPI呼び出しにも適用される評価（デバイス準拠、信頼済みネットワーク、セッション制御）を検討します。
    • サインイン頻度・セッション最大存続期間の短縮を、業務影響とトレードオフで最適化します。
  • トークン戦略
    • 連続アクセス評価（CAE）や再認証頻度のチューニングで、リフレッシュトークンの“放置”を抑制します。
    • 高リスク検出（異常なサインイン、Impossible Travel等）をトリガーに、対象ユーザーのセッション失効を自動化します。
  • デバイスコードの取り扱い
    • デバイスコードフローの業務必然性を洗い出し、利用を必要最小限に限定します。不要なら無効化やブロック条件を検討します（業務影響に注意し、段階的に導入します）。
  • アプリ・同意のガバナンス
    • Enterprise Apps/アプリ登録の棚卸しを定例化し、発行者検証の有無、要求スコープ、使用実績のない同意の取り消しを継続運用に落とし込みます。
    • 部門内での“影のSaaS同意”を可視化し、アプリ要求権限に対するレビュー会（セキュリティ/法務/業務）の仕組みを作ります。

• 検知・猟犬（Threat Hunting）の観点

  • 監視すべきシグナル
    • 「デバイスコード」でのサインインイベント増加、未知のアプリ表示名・未検証発行者の同意イベント、短時間での複数ユーザー同意発生。
    • API呼び出しの地理・時間帯の偏り、ユーザー不在時の連続Graph/Exchangeアクセス。
  • 可視化と相関
    • サインインログ、ディレクトリアクティビティ（同意・アプリ作成/更新）、アプリ使用テレメトリを横串で相関し、ユーザー単位・アプリ単位のタイムラインを即座に描ける環境を用意します。

• 人とプロセス

  • 教育の再設計
    • 「MFAを通った＝安全」ではないこと、「同意は組織データへの委任」であることを具体例で教育します。
    • デバイスコード入力の業務手順が本当に正当か、社内“申請・案内経路”を通っているかを本人が確認する“二段階確認”の文化を作ります。
  • 事前合意された“赤旗”
    • 「社外からのデバイスコード入力依頼」「同意要求の急なエスカレーション」「発行者不明アプリの承認」は即時SOC連絡の赤旗として明文化します。

最後に、今回の事案が突きつけるのは「同意とトークン運用が新しい境界（Perimeter）になる」という現実です。入口に寄せた防御は効きづらくなり、同意ポリシー、トークン寿命・失効、アプリ・権限のガバナンス、そしてログの相関運用が“入口そのもの”に格上げされました。PhaaSが手口の再現性を高めるほど、私たちが求められるのは“構造で勝つ”ことです。今日の設定変更と運用設計が、明日の無用なインシデント対応を減らす最短ルートになります。