MFAを完了させてからセッションを丸ごと奪う——OAuthデバイスコードフィッシングの手口と対策


概要

多要素認証(MFA)を突破する新しいフィッシング手法が確認された。Trend Microが2026年7月に公開したレポートによると、攻撃者はMicrosoftが提供するOAuthデバイスコードフローを悪用し、被害者にMicrosoftの正規サインインページでMFAを完了させた上で、その認証済みセッションを丸ごと奪い取る。偽サイトへの誘導はなく、被害者は「正常にサインインした」と思い込んだまま被害に遭う点が特徴的だ。


目次

  1. 何が起きたか——攻撃の概要
  2. 従来のMFAバイパスとの違い
  3. 攻撃のステップバイステップ
  4. 侵害後の動き
  5. 組織が今すぐ取るべき対策
  6. 侵害指標(IoC)
  7. まとめ
  8. 出典

1. 何が起きたか——攻撃の概要

Trend Microの調査によると、攻撃者はOAuthデバイスコードフローという正規のMicrosoft機能を悪用している。このフローは本来、スマートテレビや会議室用デバイスなど、ブラウザを持たないデバイスでMicrosoft 365にサインインするために設計されたものだ。

通常のデバイスコードフローでは:

  1. デバイスが短期間有効な認証コードを要求する
  2. ユーザーが別の画面でMicrosoftのサインインページを開き、コードを入力してMFAを完了する
  3. Microsoftはそのデバイスにアクセストークンとリフレッシュトークンを発行する

攻撃者はこの流れを悪用する。攻撃者自身がコードを要求し、そのコードを「ドキュメント確認」や「アカウント認証」を装ったフィッシングメッセージで被害者に送る。被害者がMicrosoftの正規サインインページでコードを入力してMFAを完了すると、セッショントークンは攻撃者のシステムに届く。

重要: この攻撃はMFAの脆弱性を突くのではなく、正規の認証フローの仕組みを悪用する。被害者は「問題なくサインインした」と感じるが、実際には攻撃者にセッション全体を渡してしまっている。


2. 従来のMFAバイパスとの違い

項目 従来のAiTMフィッシング OAuthデバイスコードフィッシング
経由するサイト 偽サイト(本物に見せかけたプロキシ) 正規のMicrosoftサインインページ
盗むもの セッションクッキー アクセストークン+リフレッシュトークン
被害者の体験 「変なサイトに飛んだかも」と気づく可能性あり 本物のMicrosoftで認証したため気づきにくい
トークン有効期間 セッションクッキーの有効期限次第 リフレッシュトークンは長期間有効
フィッシングURLの必要性 必要(偽サインインページ) 不要(正規Microsoftページを使う)

特にリフレッシュトークンを入手することで、攻撃者は被害者がブラウザを閉じた後も長期間アクセスを維持できる点が深刻だ。


3. 攻撃のステップバイステップ

Trend Microが観測した攻撃では、法律事務所のパートナーを装った攻撃者が段階的に被害者との信頼関係を構築してから攻撃を実行していた。

Step 1: ラポート構築

攻撃者は最初から悪意あるリンクを送らない。法律事務所の担当者を装い、ビジネス上の会話を装った友好的なメールを数回交わして信頼を築く。

Step 2: 不正リンクの送付

信頼構築後、攻撃者は「ドキュメントを確認してください」という体裁のリンクを送付する。リンクのテキストは見覚えのあるものだが、実際の経路は以下を経由する:

  1. Google Sites(信頼されたホストのルアーページ)
  2. 侵害済みのオープンリダイレクター
  3. フェイク人間確認プロンプト(自動分析を遅延させる)
  4. フィッシングランディングページ

Step 3: デバイスコードの提示

ランディングページに「確認コード」が表示され、「Microsoftの公式サインインページでこのコードを入力してください」という指示が出る。

Step 4: 被害者が正規Microsoftページで認証

被害者はMicrosoftの正規サインインページ(login.microsoftonline.com)にアクセスし、パスワードとMFAを問題なく完了する。

Step 5: セッショントークンが攻撃者へ

被害者の認証が完了した瞬間、Microsoftはそのセッションのアクセストークンとリフレッシュトークンをコードを最初に要求した攻撃者のシステムに発行する。


4. 侵害後の動き

セッショントークンを入手した攻撃者は、数時間以内に海外から被害者のMicrosoft 365環境にサインインした。その後の行動として以下が確認されている:

  • 不正デバイスの登録: 攻撃者は自身のデバイスをEntra IDに登録し、永続的なアクセスを確保する
  • 隠しメールボックスルールの作成: 被害者の受信トレイに、特定の返信や通知を自動的にアーカイブ・既読にするルールを設定し、攻撃の痕跡を隠す
  • さらなるフィッシングの展開: 侵害したメールボックスから外部の連絡先に対して同様のフィッシングを送付し、攻撃を拡大する

この一連の活動は、エンドポイント中心のセキュリティツールだけでは検知が困難であり、クラウドアクティビティログの監視が不可欠であることを示している。


5. 組織が今すぐ取るべき対策

1. OAuthデバイスコードフローを無効化する(最優先)

組織がスマートテレビや会議室システムでのデバイスコード認証を必要としない場合、Entra ID の条件付きアクセスポリシーでデバイスコードフローをブロックする。本当に必要なデバイスのみに限定した例外を設定する。

設定手順: Azure ポータル → Microsoft Entra ID → セキュリティ → 条件付きアクセス → 新しいポリシー → クラウドアプリ: すべてのアプリ → 条件: クライアントアプリ = モバイルアプリとデスクトップクライアント(デバイスコード) → ブロック

2. デバイス登録を制限する

Entra IDのデバイス登録設定で、管理対象デバイス以外からの新規デバイス登録を禁止するか、承認フローを要求する。

3. 以下の異常を監視する

監視すべき事象 意味
Authentication Broker からの通常外の国・地域でのサインイン デバイスコードフィッシングによるセッション使用の可能性
新規デバイスの急速な登録 侵害後の永続化
想定外のメールボックスルール作成 侵害痕跡の隠蔽
不可能な移動(Impossible Travel)アラート 攻撃者の海外からのアクセス

4. フィッシング耐性のあるMFA方式に移行する

FIDO2セキュリティキーやWindows Helloなど、デバイスに紐づいた認証方式はデバイスコードフィッシングの影響を受けない。可能な範囲でこれらへの移行を検討する。

5. ユーザー教育

被害者はMicrosoftの正規ページでMFAを完了しているため、「怪しいサイトに誘導された」という感覚がない。予期しないコード入力要求は即座に報告することを組織全体に徹底する。


6. 侵害指標(IoC)

Trend Microが公開したIoCを以下に掲載する。SIEM や脅威インテリジェンスプラットフォームで活用できる。

カテゴリ
送信者偽装ドメインrlcounsel[.]com
送信者偽装ドメインcholaw-kr[.]co
ルアーページ(Google Sites)sites.google[.]com/view/businessprofileoverview
ルアーページ(Google Sites)sites.google[.]com/corporateprofiledetails
ルアーページ(Google Sites)sites.google[.]com/profileportfoliodetailsdata
オープンリダイレクターeusei[.]com/dir/redirects.php
オープンリダイレクターcineuropa[.]org/nll.aspx
オープンリダイレクターzrdesignlabo[.]com/st-manager/click/track
フィッシングエンドポイントup88qope1z[.]hlpadditives[.]com
フィッシングエンドポイントzr6dgshpvf[.]flosli[.]com
フィッシングエンドポイントprofileupdate-collaboration[.]stefan-dufva[.]workers[.]dev
攻撃者IPアドレス104.219.238[.]253
攻撃者IPアドレス43.165.1[.]42
攻撃者IPアドレス40.124.130[.]50
攻撃者IPアドレス18.118.111[.]82
攻撃者IPアドレス83.136.210[.]246

※ IPアドレス・ドメインは誤クリック防止のため defang 表記([.])。MISP・VirusTotalなど管理された環境でのみ refang すること。


まとめ

OAuthデバイスコードフィッシングは、MFAを「回避」するのではなく「利用する」手口であり、被害者が正規のMicrosoftページで認証を完了するため従来のフィッシング教育では防ぎにくい。エンドポイントセキュリティだけでは検知が難しく、クラウドアクティビティの監視と、デバイスコードフロー自体の無効化が最も効果的な対策となる。情シス担当者は自組織でデバイスコードフローが本当に必要かどうかを今すぐ確認し、不要であれば条件付きアクセスでブロックすることを強く推奨する。


出典

ニュース一覧に戻る