ロシア系アクターがMicrosoft 365の「デバイスコード」認証を悪用――MFAを“迂回”する実用攻撃が長期化しています

今日の深掘りポイント

• 攻撃の肝は「偽ページ」ではなく、Microsoft純正のデバイスコード認証を使わせる点にあります。ユーザーは本物のmicrosoft.comで操作し、結果として攻撃者にトークンを渡してしまいます。
• これは「MFAバイパス」というより「MFAの社会工学的悪用」です。MFAは作動しますが、ユーザーが自ら正当化するため、検知・教育・ポリシーの三位一体が必要です。
• 抑止の近道は「デバイスコードフローを本当に必要としているか」を見極め、不要ならブロック／条件付きで制限することです。可視化・監査・トークン失効の運用も並走が必要です。
• 既存のフィッシング対策（URLブロック、スキャナ）は効きにくいです。サインインログで「OAuthデバイスコード」流の使用と、通常と異なるアプリID・地理・IPとの組み合わせ検知が実務上のカギになります。
• 直近性・実効性が高く、対象セクターは政府・教育・輸送・シンクタンクに及び横断的です。SOCはハンティング・即応プレイブックを準備すべき局面です。

はじめに

報道によれば、ロシアに関連するアクターが2025年9月以降、Microsoft 365のOAuth 2.0「デバイスコード」認証フローを用いたフィッシングを継続しています。軍・政府の送信元に見せかけたスピアフィッシングで文書リンクを提示し、実際にはMicrosoftのデバイスコード用ログインに誘導。ユーザーが表示されたコードを正規サイトに入力してMFAを完了すると、攻撃者側のデバイスでアクセストークン／リフレッシュトークンが得られ、メールやファイルへのアクセスが成立します。米欧の政府、シンクタンク、高等教育、交通機関などが標的になっているとされています。The Hacker Newsの報道が複数アクターの関与を示唆しており、Proofpointも同手法の横展開を観測したと伝えています。

このスコアは全体として「すぐ動ける現実的脅威」であることを物語っており、技術対策の適用余地が大きい反面、被害の顕在化も早いタイプだと読めます。CISO・SOCにとっては、ポリシーでの制御と運用での監視・失効の両輪が問われる案件です。

深掘り詳細

事実関係（報道と仕様の整理）

• 攻撃の流れ（要旨）
  • 攻撃メール（偽の会議招集・取材依頼など）に埋め込んだリンクから、Microsoftのデバイスコード入力ページへ誘導。
  • 攻撃者は事前にOAuth「デバイスコード」フローでコードを生成済み。被害者が正規サイトでコード入力・サインイン（必要ならMFA）を完了すると、攻撃者端末がトークンを取得。
  • 取得したトークン（多くはoffline_accessを含む）でメールやクラウドデータに長期アクセスが可能に。
• デバイスコード認証フローの性質
  • ブラウザを使いにくいデバイスでもログインできるよう設計されたOAuth 2.0の拡張です。ユーザーは別デバイスの正規サイトにコードを入力して認証します（IETF RFC 8628に規定）RFC 8628。
  • Microsoft Entra ID（旧Azure AD）でもこのフローはサポートされ、Microsoft純正ページで実行されます。実装の概要はMicrosoftの開発者向けドキュメントに記載があります（v2 OAuth 2.0 device code flow）Microsoft Docs: OAuth 2.0 device code flow。
• 可視化・検知の入口
  • サインイン監査ログにはクライアント種別やプロトコルに関する情報が記録されます。監査スキーマの参考はMicrosoftのログスキーマ解説を参照ください（環境により表記差あり）Azure AD サインイン ログ スキーマ。

出典は主に前掲の報道記事とプロトコル／実装の一次資料に依っています。具体的なアクター名や件数などの定量は公開報道の範囲に留まるため、本稿では憶測を避けています。

インサイト（なぜ効くのか／どこで止めるか）

• なぜ効くのか
  • フィッシング耐性の高い「URL検査」「偽ページ検知」をすり抜ける構造にあります。ユーザーはmicrosoft.comで操作し、MFAも求められるため「安全だ」と思い込みやすいです。
  • 攻撃者は正規アプリ（Microsoft製のクライアントIDなど）を使う場合があり、「未知の三者アプリ同意」監視だけでは死角が生まれます。
• 本質は「ユーザーが攻撃者のセッションに正当性を付与する」問題
  • これはMFAの破綻ではなく、MFAが攻撃者のセッションに適用される点が特徴です。したがって、ユーザー教育とサインイン・フロー単位の制御（必要性の低いフローの抑止）が有効です。
• 止め方の層
  • 政策（ポリシー）層：デバイスコードフローを無効化または対象・条件を絞る。代替手段がある業務は切替える。
  • 監視層：サインインログで「デバイスコード」フローの使用を恒常監視。通常使われないアプリIDや国・ASN・IP評判との相関でアラート。
  • 失効・復旧層：オフラインアクセス（リフレッシュトークン）を前提に、インシデント時は広範なトークン失効を即時実行する運用を整備。

脅威シナリオと影響

以下は公開情報に基づくシナリオ仮説で、MITRE ATT&CKの観点に沿って整理します（アクター特定や数値は仮定せず、技術的連鎖に焦点を当てます）。

• シナリオA：政策研究機関（シンクタンク）のメール・OneDrive窃取

  • 連鎖（仮説）
    • 初期アクセス：スピアフィッシングで正規デバイスコードページに誘導（T1566.002 Spearphishing Link）。
    • 認証悪用：ユーザーがコード入力・MFAを通過し、攻撃者がOAuthトークンを取得（T1528 Steal Application Access Token, T1550.004 Use Alternate Authentication Material: Web Tokens）。
    • コレクション：メールボックス/ファイルアクセス（T1114 Email Collection、T1119 Automated Collection）。
    • 持続化：offline_accessによる長期トークン更新（T1078 Valid Accounts（クラウド）相当の利用）。
    • 送出：クラウド経由またはC2を介した外送（T1041 Exfiltration Over C2 Channel）。
  • 影響：対外発信文書の先読み、関係者情報の特定、さらなるスピアフィッシングの素材化。

• シナリオB：政府機関の業務メールに対する長期潜伏

  • 連鎖（仮説）
    • 初期アクセス～トークン取得は同上。
    • 防御回避：インボックスルールで隠蔽／自動転送（T1114.003 Email Forwarding Rule）。
    • 横展開：共有メールボックス・チームサイトへの権限範囲での探索（T1087 Account Discovery、T1069 Permission Group Discovery）。
  • 影響：政策形成過程や連絡網の観測、サプライチェーンへの波及。

• シナリオC：大学研究部局の共同研究データへのアクセス

  • 連鎖（仮説）
    • 初期アクセス～トークン取得は同上。
    • コレクション：SharePoint/OneDriveの研究データ取得（T1213 Data from Information Repositories）。
  • 影響：未発表研究の流出、産学連携先への波及、特許戦略の毀損。

共通特徴として、「偽ページを踏ませる」のではなく「正規の認証フローを踏ませる」ため、メール・Webゲートウェイや単純なURLブロックに依存した防御は効果が限定的です。ログに残る痕跡（デバイスコードフローの使用、アプリID、地理・ASN、MFAの満たされ方）は、SOCのハンティングと相関に依拠します。

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

実務での優先順位と到達可能性を意識したアクションプランです。環境・ライセンスによって実装可否が異なるため、Microsoftの一次ドキュメントで自組織の前提を確認しながら進めてください。

• ポリシー・アーキテクチャ

  • デバイスコードフローの必要性を評価し、不要なら全体で無効化／ブロックを検討します。業務要件で必要な場合は、対象ユーザー／条件（拠点IP、デバイス状態、リスクシグナルなど）を狭める設計を優先します。
  • ユーザー同意（consent）の既定を最小化に設定し、アプリ同意はワークフロー経由に限定します。Microsoftの同意設定ガイダンスを参照し、不要なユーザー同意を抑制しますMicrosoft Docs: ユーザーの同意とアプリの登録の構成。
  • 重要リソース（Exchange Online、SharePoint Onlineなど）には条件付きアクセスで「信頼済み／準拠デバイス」を必須化し、デバイスコードフロー経由のトークンが実効アクセスを得にくい構成にします（業務影響評価の上で段階導入）。
  • 継続的アクセス評価（CAE）やサインインリスクのリアルタイム適用を有効化し、リスク検出をトリガにトークンの即時無効化を促しますMicrosoft Docs: Continuous Access Evaluation。

• 監視・ハンティング

  • 監査ログで「OAuth 2.0 Device Code」相当のフロー使用を可視化するダッシュボードを常設します。基準線（通常利用の有無、利用ユーザー、アプリID、地理）を確立し、逸脱検知を有効化します。参考：サインインログスキーマAzure AD サインイン ログ スキーマ。
  • 相関の鍵となる観点
    • 初めて観測されるアプリケーションIDによるデバイスコードフロー
    • 既存ユーザーの通常居住地域外からのフロー開始
    • MFAを満たしたにも関わらず新規デバイス・新規ASNでのトークン使用
    • ユーザーが直後に体験する不可解なメール動作（自動転送ルールの作成など）
  • クラウドアプリ許可（OAuth permission grants）の棚卸しを定期実施し、不要なoffline_accessや広範なGraph権限が付与された委任を洗い出します（Microsoft Graphのリソース参照に基づく運用が有効です）。

• インシデント対応（プレイブック）

  • 兆候検知時の即応
    • 当該ユーザーのサインインセッション無効化・リフレッシュトークン失効を即時実施（Microsoft GraphのrevokeSignInSessionsを参照）Microsoft Graph: revokeSignInSessions.
    • 当該ユーザーのOAuth同意（permission grants）とメールボックスルールの確認・不審エントリの撤去。
    • 関連セッション（同IP/ASN/UA）と関連アカウントの横展開調査。
  • 根本対策
    • 当該ユーザーの教育・事後レビュー（どの誘導で操作したか、どの表現が効いたか）をフィードバックし、組織全体の模擬演習に反映。
    • ビジネス上デバイスコードが必要なユースケースの代替（標準ブラウザフロー、プラットフォームネイティブアプリ）を検討し、将来の再発防止を設計。

• 人的対策（教育・演習）

  • 「正規サイトでコード入力＝安全」の思い込みを崩すため、デバイスコード流を題材にした模擬演習を設計します。メール本文に「コードを入力して共同編集を開始」「インタビュー資料へのアクセス」など、今回のパターンに即したシナリオを取り入れます。
  • 合わせて、「MFA通知が来たら盲目的に承認しない」「業務外アプリケーションによるアクセス要求はヘルプデスク確認」という行動規範を再周知します。

最後に、本件は単一のマルウェアやゼロデイではなく、正規の認証フローを突く社会工学の進化形です。ゆえに、単発のシグネチャでの完封は期待できません。ポリシー（使わないなら止める）・観測（どのフローがいつ使われたかを可視化）・運用（即時失効と回復）の三層で、地に足の着いた対策を今日から回し始めるのが現実的です。

参考情報

• The Hacker News: Russia-Linked Hackers Use Microsoft 365 Device Code Phishing to Hijack Accounts（2025-12報道）: https://thehackernews.com/2025/12/russia-linked-hackers-use-microsoft-365.html
• IETF RFC 8628: OAuth 2.0 Device Authorization Grant: https://datatracker.ietf.org/doc/html/rfc8628
• Microsoft Docs: OAuth 2.0 device code flow（Microsoft Identity Platform 実装）: https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-device-code
• Microsoft Docs: Azure AD サインイン ログ スキーマ（監視の参考）: https://learn.microsoft.com/en-us/entra/identity/monitoring-health/reference-azure-ad-sign-ins-log-schema
• Microsoft Docs: ユーザー同意とアプリの登録の構成（同意制御の基本）: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-user-consent
• Microsoft Graph API: revokeSignInSessions（セッション失効）: https://learn.microsoft.com/en-us/graph/api/user-revokesigninsessions