M365のデバイスコード認可を悪用するフィッシングが拡大—正規サイトで「同意」を誘導しMFAも形骸化します

今日の深掘りポイント

• 攻撃はパスワード窃取ではなく、OAuth 2.0のデバイスコード認可（RFC 8628）を悪用し、ユーザーの「同意」を起点にトークンを取得する同意型フィッシングに軸足を移しています。
• 被害者はaka.ms/deviceloginなど正規のMicrosoftページに誘導され、ユーザーコード入力→同意の手順を踏むため、従来のURL判定やMFA運用の前提が崩れます。
• トークンには長期利用可能なrefresh token（offline_access）が含まれる場合があり、検出困難な持続性とビジネスメール妨害（BEC）や横展開の土台になります。
• 守りの主戦場は「パスワード」から「アプリ同意・スコープ管理・OAuthアプリの可視化/制御」に移行します。ユーザー同意の制限、CA強化、OAuth監視（新規サービスプリンシパル/権限付与の監査）が当面の肝です。
• メール経由で拡散し、業界横断で再現性が高い手口です。即応の運用対策（同意フローの統制・ログ検知・教育）と、構造対策（同意ポリシー・アプリガバナンス）が同時に必要です。

はじめに

Proofpointが、Microsoft 365環境でOAuth 2.0のデバイスコード認可を悪用したフィッシングの拡大を警告しています。被害者はメールの誘導に従って正規のMicrosoftデバイス認証ページにアクセスし、提示されたデバイスコードを入力・同意するだけで、攻撃者のアプリに対して自分のアカウントスコープのアクセス権を与えてしまいます。国家関与・金銭目的の双方で観測され、SquarephishやGraphishといったツールが用いられていると報じられています。MFAやリンク審査に依存した従来の防御ではすり抜けられるため、アプリ同意の統制と検知の強化が急務です。Help Net Securityの報道がこの点を整理しています。

深掘り詳細

事実整理：デバイスコード認可の悪用パターン

• 攻撃者は自らが管理するAzure ADアプリ（マルチテナント）で「デバイスコード認可（Device Authorization Grant）」を開始し、ユーザーコードを生成します。被害者にメールで「業務継続のためコードを入力してください」といった文言で、aka.ms/deviceloginなどの正規サイトへのアクセスとコード入力を促します。
• 被害者が正規サイトでコードを入力すると、Microsoft側は攻撃者アプリへのアクセス許可画面（要求スコープの同意）を提示します。被害者が同意すれば、攻撃者側のアプリは被害者のトークン（場合によってはrefresh tokenを含む）を取得し、GraphやExchange Online等のAPIへ被害者権限でアクセス可能になります。
• このフローはIETFのRFC 8628で規定され、Microsoft Identity Platformでも正式にサポートされています。正規の認可フローを悪用するため、フィッシングサイトでの資格情報入力やリバースプロキシによるAiTMを伴わずとも成立します。RFC 8628、Microsoft Identity Platform: Device Authorization Grant
• Proofpointは、国家関与および金銭目的の脅威アクターがこの手口を採用し、ツールキット（Squarephish/Graphish）でキャンペーンを運用していると指摘しています。報道

インサイト：境界は「ID」からさらに「同意」へ

• 同意の社会工学化という転換点です。ユーザーは「正規ドメイン」「正規UI」「MFA実施」の三点セットを確認したつもりでも、実態は攻撃者アプリへの権限委譲です。ユーザー教育はURL確認や添付ファイルの是非から、「どのアプリに何を同意しているのか」を読解させるレベルに引き上げる必要があります。
• 「offline_access」スコープの同意が含まれると、refresh tokenによる長期的な再認証が可能になり、パスワードリセットやデバイス初期化では遮断できない持続性が生じます。検知の主役はサインイン失敗ではなく、「新規サービスプリンシパル作成」「OAuth2PermissionGrant（同意）」「Graph/Exchangeへのアプリアクセス」などの監査イベントへ移ります。
• MFA強化だけでは難しい理由は、認証自体が正規ページで生じる点と、同意対象がユーザーの業務権限である点です。したがって制御点は「誰が、どのアプリに、どのスコープを、どの条件で同意できるか」に移ります。組織はユーザー同意を原則禁止（もしくは制限的許可）とし、承認済みアプリ・検証済みパブリッシャー・低リスクスコープに限定する「同意ポリシー」を当たり前にする段階に来ています。
• 現場運用の観点では、SIEM/UEBAでの異常検知を「サインイン」中心から「アプリ同意・トークン利用プロファイル」中心に再設計する必要があります。特に「勤務時間外・新国からの短時間での大量Graphアクセス」「新規に現れたアプリIDによるMail/Filesスコープの連続呼び出し」などは高感度にアラート化すべきです。

脅威シナリオと影響

以下は想定シナリオであり、MITRE ATT&CKとの対応は仮説に基づくマッピングです。

• シナリオA：メール箱奪取とBEC

  • 手口: フィッシングメールでデバイスコード入力を促し、Mail.ReadやMail.ReadWrite、offline_accessを同意させる。攻撃者はGraph APIでメールを収集・ルール改竄・スレッド乗っ取り。
  • 影響: 取引先への偽請求、内部の承認ワークフロー攪乱、監査ログに気づきにくい長期潜伏。
  • MITRE:
    • Initial Access: T1566.002（スピアフィッシングリンク）
    • Defense Evasion/Credential Access: T1550（代替認証素材の悪用：OAuth/セッショントークン）
    • Persistence: T1098.003（追加クラウド認証情報／不正な同意の維持）
    • Collection: T1114（メール収集）
    • Exfiltration: T1567.002（Webサービス経由の持ち出し）

• シナリオB：SharePoint/OneDriveからの静かな情報抜き取り

  • 手口: Files.Read.All等の権限を要求し、部門単位で設計情報・契約書を継続取得。
  • 影響: 知的財産流出、コンプライアンス違反、取引先への二次被害。
  • MITRE:
    • Initial Access: T1566.002
    • Privilege/Defense Evasion: T1550（トークン悪用）
    • Discovery/Collection: T1087/T1039相当（クラウド内資産・ファイル列挙と収集）
    • Exfiltration: T1041/T1567.002

• シナリオC：サプライチェーン踏み台化

  • 手口: 役員や営業のアカウントでアドレス帳・メールスレッドを把握し、外部に対する高精度な二次フィッシングを展開。
  • 影響: 取引先横断のBEC連鎖、広域な信用失墜。
  • MITRE:
    • Initial Access: T1566.002
    • Lateral Movement（対外）: T1566.002（再フィッシング）/ T1078.004（クラウド有効アカウントの悪用）
    • Impact: T1499系（業務中断の誘発は間接的）

総じて、この攻撃は短期の現実的リスクが高く、実装容易性が高いゆえに広範な業務継続に影響しやすいです。MFA普及後の「次の一手」として、攻撃者側のコスト対効果が極めて良いのが難点です。

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

優先順位と実装難易度を踏まえ、当面の現実解と中期の構造対策に分けて提案します。環境差分が大きいため、導入前に業務影響の検証を行ってください。

• すぐに着手（1–2週間）

  • ユーザー同意の統制強化
    • 原則として「ユーザーによるアプリ同意」を禁止、もしくは「検証済みパブリッシャー＋低リスクスコープのみ許可」に制限します。管理者承認ワークフローを有効化し、事前承認リスト（許可アプリ・許可スコープ）を整備します。
    • 新規サービスプリンシパル作成とOAuth2PermissionGrant（同意付与）イベントのアラート化を行います。特にoffline_access、Mail.、Files.、Directory.*などの広域スコープを高リスクとして扱います。
  • SIEM/UEBAでの検知パターン増強
    • 監査ログ: 「Consent to application」「Add service principal」「Update application」「Add OAuth2PermissionGrant」などのイベントを収集・相関します。
    • サインインログ: 「デバイスコード認可」や「パブリッククライアント」由来のサインインを可視化し、未知のアプリID・新規パブリッシャー・勤務時間外・新国からの急増をアラートにします。
    • アクセスプロファイル: 新出アプリIDによるGraph/Exchange/SharePointへの連続アクセス（特にMailItemsAccessed相当の大量発生やFiles APIのスキャン）を異常検知対象にします。
  • メール防御・教育
    • メール本文中のキーワードや誘導文（「デバイスコード」「devicelogin」「コードを入力」）と4–8桁×2のパターン（例: XXXX-XXXX）を組み合わせた検知を導入します。正規ドメインへの誘導であっても審査を強化します。
    • 研修では「同意画面の読解」を重点化します。求められているスコープ、発行者（パブリッシャー）、アプリ名を確認し、不明なアプリは承認依頼に回す運用を徹底します。

• 近々（今月中）

  • 条件付きアクセス（CA）の強化
    • 高感度データ（Exchange Online、SharePoint/OneDrive、Graphの高権限）に対し、信頼済み・準拠デバイスやネットワーク条件を要求するセグメント化を検討します。アプリのトークンだけでは満たせないコンテキスト制約（デバイス準拠、ロケーション、評点）を強化し、トークンの使い回し価値を下げます。
    • サインイン頻度・セッション制御（短期化）でrefresh token悪用の滞留時間を短縮します。業務影響とバランスを取りつつ対象ユーザー/アプリを限定して適用します。
  • アプリガバナンスの整備
    • 既存のEnterprise Appsを棚卸しし、不要アプリの同意撤回・無効化・スコープ縮小を実施します。パブリッシャー検証状態、権限の広さ、利用実績でリスク評価を行います。
    • 新規に現れたアプリIDは隔離評価フローへ自動ルーティングし、最小権限での期間限定承認をデフォルトにします。

• 中期（四半期スパン）

  • 設計原則の転換
    • 「同意は例外」「既知アプリ・最小権限・最短期間」の三原則を各部門SaaS導入プロセスに組み込みます。調達・法務・ITの三者連携でガバナンスを制度化します。
    • フィッシング耐性MFA（FIDO2/パスキー/証明書）や信号連動型のリスクベース制御を広げ、既存セッションの安易な再利用を抑制します。ただし本手口は正規UIで進むため、同意統制と併用が必須です。
  • インシデント対応の標準化
    • 検知→封じ込めの標準手順に「アプリ同意撤回」「サービスプリンシパル削除/無効化」「Refresh token一括失効（サインインセッションの取り消し）」「影響スコープ（メール/ファイル）の遡及評価」を追加します。
    • 取引先への二次被害連絡（BEC連鎖）とレピュテーション回復のプレイブックを準備します。

リスクは短期的に顕在化しやすく、攻撃ツールにより再現性が高い点が厄介です。逆に言えば、組織側の統制ポイント（同意、アプリ、監査）は明確です。パスワードとMFAの上に「同意ガバナンス」という第三のレイヤーを実装することが、当面の最適解になります。

参考情報

• Help Net Security: Microsoft 365 device code phishing attacks expand（2025-12-18）: https://www.helpnetsecurity.com/2025/12/18/microsoft-365-device-code-phishing/
• IETF RFC 8628: OAuth 2.0 Device Authorization Grant: https://www.rfc-editor.org/rfc/rfc8628
• Microsoft Identity Platform: OAuth 2.0 device authorization grant（Device code flow）: https://learn.microsoft.com/azure/active-directory/develop/v2-oauth2-device-code

注記

• 本稿でのMITRE ATT&CKマッピングと一部シナリオは、報道で示された手口を前提に、一般的なMicrosoft 365/Graphの実装に照らして整理した仮説です。実際のログ・テレメトリでの裏取りと自組織のポリシー差分を加味して運用に落とし込むことを推奨します。