Microsoft 365のOAuthデバイスコード悪用、正規画面を踏み台にするフィッシングの波

今日の深掘りポイント

• 攻撃はMicrosoftの正規ドメイン上の「デバイスコード」入力フローを悪用するため、URLや証明書の確認といった従来の教育では見抜きにくいです。
• 技術的な本質はパスワード窃取ではなく「同意の乗っ取り（consent phishing）」で、攻撃者アプリに対するOAuthトークン（とくにrefresh token）付与が核心です。
• ユーザー同意の抑制・権限分類・Publisher検証・管理者同意ワークフローの運用が第一優先の防御で、併せて「デバイスコードフロー」をConditional Accessで制御することが即効性のある抑止策です。
• 監視の要は「grant_type=device_code」と「Consent to application」監査イベント、および新規Service Principalの生成監視です。証跡はEntra Audit/Sign-inログとGraphでのoauth2PermissionGrantsに残ります。
• 本件は国家・犯罪双方の関与が示唆され、政府・学術領域への情報流出やBEC（ビジネスメール詐欺）連鎖に直結しやすいです。緊急度と実現可能性がともに高い脅威と見ます。
• 現場判断では「一律ブロック」より「最小許可・例外ホワイトリスト・短期的なトークン抑制」の組み合わせが運用負荷と事業影響のバランスを取りやすいです。

はじめに

Microsoft 365アカウントに対し、OAuthのデバイスコード認可（Device Authorization Grant）を悪用するフィッシングが増勢です。攻撃者は自前のマルチテナントアプリを用意し、ユーザーに正規のMicrosoftデバイスログインページでコードを入力・同意させ、アプリに委譲された権限でGraphやExchange Onlineへアクセスします。Proofpointは9月以降の攻撃増加と、金銭目的の犯罪アクターに加えて国家関与の可能性があるクラスタ（例：TA2723）の活動を指摘しています。政府や学術機関への狙いも観測されており、組織的インパクトの大きさが懸念されます。Proofpointの発表を一次ソースとして本稿を編みます。

この攻撃は新規のゼロデイではなく、既存の正規仕様を社会工学と組み合わせて悪用する点が本質です。Device Authorization GrantはIETFの標準であり（RFC 8628）、Microsoftも正規のフローとして提供しています（Microsoft identity platform のデバイスコードフロー）。ゆえに「脆弱性修正」型の対応より、同意とフローの制御、ログ監視、インシデント初動の整備が決定打になります。

深掘り詳細

事実（一次情報で確認できる点）

• 攻撃は、ユーザーに「Microsoftのデバイスログインページでコードを入力する」ことを求め、正規の同意画面で攻撃者アプリに権限委譲を行わせます。Proofpoint
• 標的はMicrosoft 365（Entra ID）で、攻撃者はアプリに付与されたスコープ（例：Mail.Read、Files.Read、offline_accessなど推測）を用い、Graph/Exchange OnlineなどのAPIへアクセスします。デバイスコードフロー自体は標準仕様で、ユーザーの別デバイスからのログインや画面のないデバイスを支援するために設計されています（RFC 8628、Microsoftの実装）。
• 企業側が制御可能な主要リスク面は「ユーザー同意の許容範囲」「Publisher検証の要否」「権限分類（高リスク権限は管理者同意のみ）」「Conditional Accessによる認可フロー（device code等）の制御」です。Microsoftはこれらの運用ガードレールを提供しています（ユーザー同意設定、管理者同意ワークフロー、権限分類、Publisher検証、Conditional Accessでの認証フロー制御）。
• 監査面では、「Consent to application」イベントがEntra監査ログに、サインインログでは認証詳細に認可フローの痕跡（grant_typeなど）が残ります（Azure AD Audit/Sign-inログ、サインインログのスキーマ、Microsoft 365 統合監査ログのAzure ADアクティビティ）。付与済み同意の列挙はGraphのoauth2PermissionGrantsで取得できます（Graph: oauth2PermissionGrant）。

インサイト（構造的な弱点と運用の肝）

• なぜ効くのか：ユーザーは「正規のMicrosoft画面」上で操作し、URLや証明書も正しいため、従来のリンク検査・ドメイン判定の教育では回避しにくいです。防御の重心はユーザー行動ではなく「同意のガバナンス」に置くべきです。
• 技術的なポイント：攻撃者が狙うのは資格情報ではなく「同意により得られるトークン」と「付与された権限面の持続性」です。offline_accessが付与されれば長寿命のリフレッシュトークンを介し持続アクセスが可能になり、ユーザーのパスワード変更やMFA強化だけでは遮断できない場合があります。発見時は「トークン失効」と「同意の取り消し（Service Principalの無効化/削除含む）」が初動の必須手順になります（Graph: 全リフレッシュトークンの失効）。
• 条件付きアクセスの射程：近年、Conditional Accessで「認証フロー（device code、ROPC等）」を条件として制御できるようになりました。業務でデバイスコードが不要な部門では原則ブロックし、必要部署のみグループ例外で許可するのが実務的です（Authentication flows 条件）。ただし、デバイスコードを完全禁止できない場合も少なくないため、最終的な決め手はやはり「同意の統制」です。
• 「Publisher検証」と「権限分類」の効用：Verified Publisherかつ低リスク権限に限定してユーザー同意を許容し、高リスク権限（offline_access、Mail.ReadWrite、Files.ReadWrite.All、Directory.Read.All等を自組織で定義）は管理者同意のみとする運用は、攻撃の大半を事前に遮断します（ユーザー同意設定、権限分類）。
• 痕跡の起点は「同意」：メールやWebプロキシのIOCに寄りかかるより、EntraのAudit/Sign-inログで「Consent to application」を軸に逆引きするほうが当たりが取れやすいです。あわせて新規Service Principal生成のスパイク監視と、oauth2PermissionGrantsの差分監視を自動化すると、運用負担と検知遅延を下げられます。

メトリクス観点の総合所感としては、即応性と実現確度が高い一方で、技術的新規性は中程度でも被害の広がりやすさが高い典型のケースです。緊急度が高いと判断し、まずは「同意の面（ポリシー・検知・失効）」に人的・技術的リソースを集中すべきです。

脅威シナリオと影響

以下は公開情報からの事実に基づきつつ、攻撃者の常套手口を踏まえた仮説シナリオです（仮説であることに留意ください）。

• シナリオA：BEC収益化

  1. スピアフィッシングで「デバイスコード」を入力させ、攻撃者アプリにMail.Read/Send、offline_accessの同意を取得
  2. Graph経由でメールボックスを遠隔収集、支払いスレッドの把握
  3. ルール作成で痕跡隠蔽、請求書差し替えで送金転送
  4. 維持はrefresh token更新で継続
  • 推定ATT&CK: T1566.002（Spearphishing Link）、T1550.001（Use Alternate Authentication Material: Application Access Token）、T1114.002（Email Collection: Remote Email Collection）、T1078.004（Valid Accounts: Cloud Accounts、トークンを用いた正規アクセスの濫用）

• シナリオB：研究・政策情報の窃取（政府・学術）

  1. Drive/SharePointの読み取り権限を含む同意を取得
  2. Graph/SharePoint APIで機微文書を段階的に収集
  3. 組織図・委員会文書・外部連携窓口を把握し、さらなる対人攻撃へ展開
  • 推定ATT&CK: T1566.002、T1550.001、T1530（Data from Cloud Storage Object）、T1591（Gather Victim Org Info）等

• シナリオC：クラウドID横展開の足場化

  1. Directory.Read.Allなど中権限の同意を獲得
  2. 組織内のアプリ・役割・ユーザーを列挙、弱い設定のエンタープライズアプリを特定
  3. 「ユーザー割り当て必須」未設定のアプリに対しユーザー招待・権限付与を悪用し持続性を強化（仮説）
  • 推定ATT&CK: T1087（Account Discovery）、T1069.003（Permission Group Discovery: Cloud Groups）、T1098（Account Manipulation）等

影響面では、メール・ファイル・ディレクトリの各API面で「スコープの広さ＝攻撃回復の難易度」に直結します。offline_accessが付いた場合は、検知後の初動でrefresh tokenの即時失効（全刷新）を必ず含めるべきです。また、国家系クラスタが政府・学術を狙うとき、外部共同研究や委託先のアカウントを踏み台にするサプライチェーン型の窃取が連動しやすい点にも注意が必要です。

参考（一次情報）

• Proofpointの発表（攻撃増加とアクター像）: https://www.proofpoint.com/us/newsroom/news/microsoft-365-accounts-targeted-wave-oauth-phishing-attacks
• 標準仕様：OAuth 2.0 Device Authorization Grant（RFC 8628）: https://datatracker.ietf.org/doc/html/rfc8628
• Microsoft identity platform: Device codeフロー: https://learn.microsoft.com/azure/active-directory/develop/v2-oauth2-device-code
• Entraの同意ガバナンス（ユーザー同意・管理者同意WF・権限分類・Publisher検証）:
  • https://learn.microsoft.com/azure/active-directory/manage-apps/configure-user-consent
  • https://learn.microsoft.com/azure/active-directory/manage-apps/configure-admin-consent-workflow
  • https://learn.microsoft.com/azure/active-directory/manage-apps/configure-permission-classifications
  • https://learn.microsoft.com/azure/active-directory/develop/publisher-verification-overview
• Conditional Accessの認証フロー条件: https://learn.microsoft.com/entra/identity/conditional-access/concept-conditional-access-conditions#authentication-flows
• 監査・サインインログとスキーマ:
  • https://learn.microsoft.com/azure/active-directory/reports-monitoring/concept-audit-logs
  • https://learn.microsoft.com/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema
  • https://learn.microsoft.com/microsoft-365/compliance/audit-log-activities#azure-ad-activity
• Graphでの同意・トークン関連:
  • oauth2PermissionGrant: https://learn.microsoft.com/graph/api/resources/oauth2permissiongrant
  • ユーザーの全refresh token失効: https://learn.microsoft.com/graph/api/user-invalidateallrefreshtokens

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

優先度順に、即時対処から構成変更・継続運用までを整理します。

• 0〜24時間（初動）

  • 監査ログで「Consent to application」を横断確認し、過去30〜60日で新規同意の急増・不審アプリ（未知のPublisher、過大スコープ、offline_access要求）を抽出します。
    • 例：Log Analytics（AuditLogs）
      • AuditLogs | where Category == "ApplicationManagement" | where OperationName contains "Consent to application" | project TimeGenerated, OperationName, ResultDescription, TargetResources, InitiatedBy
  • サインインログでdevice codeフローの痕跡を探索します（環境によりフィールド名が異なる点に注意してください）。
    • 例：SignInLogs
      • SigninLogs | where tostring(AdditionalDetails) has "device_code" or ClientAppUsed == "Other clients" | project TimeGenerated, UserPrincipalName, AppDisplayName, ClientAppUsed, IPAddress, ConditionalAccessStatus
  • Graphで付与済み同意の横断棚卸し（scopeにoffline_accessやMail/Filesの書込権限が含まれるものを優先調査）:
    • GET https://graph.microsoft.com/v1.0/oauth2PermissionGrants
  • 侵害疑いユーザーにはrefresh tokenの失効を即時実施します（セッション再確立を伴うため影響調整に留意）:
    • POST https://graph.microsoft.com/v1.0/users/{id}/invalidateAllRefreshTokens
  • 攻撃者アプリのService Principalをテナントから無効化/削除し、同意を取り消します（影響調整のため事前に対象ユーザーとスコープを把握）:
    • DELETE https://graph.microsoft.com/v1.0/servicePrincipals/{id}

• 1〜7日（抑止設定の導入）

  • ユーザー同意を「Verified Publisherかつ低リスク権限のみ許可」へ縮小し、高リスク権限は管理者同意ワークフローに強制します（権限分類を運用に合わせて作成）。
    • 参考: ユーザー同意設定／権限分類／管理者同意WF（上記リンク）
  • Conditional AccessでAuthentication flowsの「Device code」を原則ブロックし、必要部門（開発者・特定のIoT運用等）のみグループ例外で許可します。
  • エンタープライズアプリで「ユーザー割り当て必須」をデフォルトにし、無差別なユーザーサインインを抑止します（許可対象の割当のみ可）。
  • メールボックスの「隠蔽ルール」検出（差出人や件名での自動移動・削除、外部への自動転送）のハンティングを実施し、BEC連鎖の芽を摘みます。

• 2〜4週間（検知の定常化とレジリエンス強化）

  • SIEMにて以下の常時検知ルールを実装します。
    • 新規Service Principalの生成スパイク（Tenant全体・ユーザー単位）
    • oauth2PermissionGrantsの差分監視（高リスク権限・offline_access）
    • Sign-inログでgrant_type=device_code相当のイベントと地理・ネットワーク異常の相関
  • インシデントプレイブック化：
    • 1. 不審同意の特定 → 2) 対象ユーザーのrefresh token失効 → 3) Service Principal無効化/削除 → 4) 影響資産の調査（メール・ファイル） → 5) 強制パスワード変更・再登録（必要時） → 6) 教育・通達
  • App Governanceの評価・導入（SaaSへの過剰許可検出、データ持ち出しの監視強化）を検討します（App governance）。

• 継続（運用の癖付け）

  • キャンペーン反復に備え、フィッシング教育の重点を「怪しいリンク検知」から「過剰な同意の拒否」へシフトします。特に「offline_access」「メール/ファイルへの広範アクセス」を伴う同意要求は原則拒否の行動規範を周知します。
  • 年次・四半期で同意台帳（どのユーザーがどのアプリに何のスコープを許したか）を棚卸し、不要な同意を整理します。
  • 重要部門では「管理者承認済みアプリのみ利用可」のモデル化を段階的に広げます。

最後に補足です。本脅威は、たとえ強固なMFAを敷いていても「正規の画面で同意」してしまえば突破される点が厄介です。よって、認証強化だけでは十分ではなく、「同意のガバナンス」と「認可フローの制御」を合わせ技で運用に落とし込むことが、被害の裾野を最小化する最短ルートになります。Proofpointが指摘するように攻撃の勢いは強く、実現容易性も高いため、猶予をおかず上記の即時アクションから着手すべきです。