多要素認証をすり抜けるデバイスコードフィッシングを防ぐ｜Microsoft Entra IDの条件付きアクセスでデバイス コード フローを止める

デバイスコードフィッシングは、条件付きアクセスでデバイス コード フローを止めるだけで、大きく防げます。

デバイスコードフィッシングでは、利用者は本物の Microsoft のサインイン画面で、いつもどおり多要素認証を済ませます。そのため多要素認証だけでは止めきれず、サインインの結果のトークンが攻撃者に渡ります。Microsoft も、デバイス コード フローは可能な限りブロックするよう勧めています。

2026年には、生成 AI で文面を作り、攻撃の仕組みをサービスとして売る手口が広がり、Microsoft は1万を超える組織で被害を確認したと公表しました。多要素認証を整えた組織でも、次の点は見落とされがちです。

• 利用者が見ているのは本物の画面なので、偽サイトを見分ける教育だけでは気づけない
• 攻撃者は手に入れたトークンで自分の端末を Microsoft Entra ID に登録し、居座ることがある
• 被害に気づいてパスワードを変えても、多要素認証を経て発行されたトークンは失効しない

この記事では、攻撃の流れと、多要素認証で防げない理由から始めて、利用状況の確かめ方、条件付きアクセスでの止め方と例外の付け方、端末の登録の絞り方、被害が出たときの対応までを、Microsoft Learn と Microsoft Security ブログの公開情報をもとに解説します。

株式会社ロクシアシステムズは、福岡と東京を拠点に、全国のお客様へ Microsoft 365・Azure の導入支援と、AIの業務活用（AIプライベート）の支援を提供しているIT企業です。

デバイスコードフィッシングの手口｜本物のサインイン画面で、トークンが攻撃者に渡る

デバイス コード フローは、スマート TV や会議室の機器のように、文字の入力がしにくい機器でサインインするための仕組みです。機器の画面にコードが表示され、利用者は手元のパソコンやスマートフォンで Microsoft のページを開いてコードを入力し、そこでサインインします。コードの有効期限は、既定で15分です。

デバイスコードフィッシングは、この「別の機器でサインインを済ませる」仕組みを悪用します。流れは次の4段階です。

1. コードを作る：攻撃者が自分の側でデバイス コード フローを始め、コードを手に入れる。組織のアカウントやパスワードは要らない
2. 送る：Teams の会議の招待や、見積もりの依頼・請求書を装ったメールで、利用者にコードを入力させる
3. 利用者がサインインする：利用者は本物の Microsoft のページでコードを入力し、パスワードと多要素認証を済ませる
4. トークンが渡る：サインインの結果のトークンは、コードを作った攻撃者の側に発行される。攻撃者はそれでメールやファイルにアクセスする

攻撃者がコードを作れる理由

攻撃者がコードを作るのに、狙う組織のアカウントやパスワードは要りません。デバイス コード フローの仕組みが、次のようになっているためです。

• 要求に含めるのはアプリの ID と権限だけ：コードを求めるときに送るのは、どのアプリとしてサインインさせるかと、どの権限を求めるかだけで、利用者のパスワードなどは含まない
• 既にあるアプリの ID を使える：Storm-2372 は、Microsoft 自身のアプリ（Microsoft Authentication Broker）の ID を使っていた
• 組織を決めずに要求できる：宛先には、どの組織の利用者でもサインインできる共通の窓口を指定できる。コードは、利用者が入力してサインインするまで、特定の人に結び付かない

つまり、コードの発行そのものは、こちらの組織では止められません。止められるのは、自社の利用者がそのコードでサインインするときです。後の章で説明する条件付きアクセスは、この時点で効きます。

2025年から2026年に Microsoft が公表した攻撃

Microsoft Security ブログは、この手口を使う攻撃を続けて公表しています。

公表	内容
2025年2月	Storm-2372 と名付けた攻撃者が、メッセージアプリで相手と信頼関係を作ったうえで、Teams の会議の招待を装ってコードを入力させていた。その後、手に入れたトークンで攻撃者の端末を Entra ID に登録する手口に移った
2026年4月	生成 AI で、相手の役職に合わせた見積もりの依頼や請求書のメールを作っていた。利用者がリンクを開いた瞬間にコードを作り、15分の有効期限の制約をかわしていた
2026年9月	攻撃の仕組みを売るサービス「EvilTokens」が、1万2千を超えるメールボックス、1万を超える組織で被害を出していたと公表。AI で、侵害したメールボックスから次に狙う相手を選んでいた

15分の期限は、もはや攻撃を止める壁になっていません。手口が商品として出回っている以上、狙われるのは特定の大企業に限りません。

なぜ多要素認証を入れても防げないのか

フィッシングに強い多要素認証は、偽のサイトにパスワードやコードを入力させる攻撃に強い仕組みです。偽のサイトでは認証が成り立たないので、入力させても使えません。

デバイスコードフィッシングでは、利用者が開くのは本物の Microsoft のページです。認証そのものは正しく行われ、問題は、その結果のトークンが誰に発行されるかにあります。Microsoft は、この手口を「サインインを、それを始めた機器から切り離すことで、従来の多要素認証の保護をかわす」と説明しています。

一方で、Microsoft は同じ記事の中で、フィッシングに強い多要素認証を引き続き勧めています。多要素認証が要らなくなるわけではありません。多要素認証は別の攻撃を防ぐために必要で、この手口はデバイス コード フローそのものを止めて防ぐ、という分担です。多要素認証の方式の選び方はMicrosoft 365の多要素認証を見直すで解説しています。

中間者型のフィッシング（AiTM）との違い

多要素認証をすり抜ける手口としてよく知られているのが、中間者型のフィッシング（AiTM：Adversary-in-the-Middle）です。攻撃者は、利用者と本物のサイトの間に偽のサイトを置いて通信を中継し、パスワードと、サインインしたあとのセッションの Cookie を奪います。見た目は本物と同じで、URL だけが違います。

AiTM には、パスキーなどフィッシングに強い多要素認証が効きます。偽のドメインでは認証が成り立たないためです。一方、デバイスコードフィッシングは通信に割り込まず、利用者は本物のページで認証します。どちらも「多要素認証のあとの結果」を奪いますが、奪い方が違うため、効く対策も違います。AiTM の防ぎ方は多要素認証を突破する中間者型フィッシング（AiTM攻撃）を防ぐで解説しています。

まず、デバイス コード フローを使っているかを確かめる

Microsoft は、デバイス コード フローは利用者にはめったに使われず、攻撃者にはよく使われると説明しています。それでも、止める前に、自社で使っている機器や利用者が無いかを確かめます。

Microsoft Entra 管理センターのサインイン ログで、「認証プロトコル」のフィルターを「デバイス コード」にすると、デバイス コード フローを使ったサインインだけを見られます。使っているのが会議室の機器など決まった機器だけなら、その機器のアカウントや場所を例外にして止められます。

見覚えの無い利用者のサインインが見つかったら、すでに被害が出ている可能性があります。後の章の「被害が出たときの対応」に進みます。

条件付きアクセスでデバイス コード フローを止める

条件付きアクセスの「認証フロー」の条件で、デバイス コード フローを選んでブロックするポリシーを作ります。この条件は、Microsoft Learn ではプレビューと表記されています。条件付きアクセスには Microsoft Entra ID P1 が要り、Microsoft 365 E3 と Business Premium に含まれます。

設定	内容
対象のユーザー	すべてのユーザー。緊急用のアカウントは除外する
対象のリソース	すべてのリソース
条件	「認証フロー」で「デバイス コード フロー」を選ぶ
許可	アクセスをブロックする
ポリシーの状態	まず「レポート専用」で作り、影響を確かめてから「オン」にする

例外は、使う必要のある機器だけに絞る

Microsoft は、全面的なブロックにできるだけ近づけるよう勧めています。例外を作るなら、会議室の機器のアカウントや、決まった場所からのサインインだけにします。例外はアカウント単位でしか作れず、特定のアプリだけに絞ることはできません。そのため、例外にしたアカウントは、どのアプリでもデバイス コード フローを使えます。

Teams の会議室の機器のためにデバイス コード フローを残すときも、Microsoft は、例外を会議室の機器のアカウントに限ることを勧めています。

「すべてのリソース」を対象にすると、端末の登録にも効く

2024年9月から、対象を「すべてのリソース」にした認証フローのポリシーは、デバイス登録サービスにも効くようになりました。攻撃者がトークンで端末を登録する経路も止められる一方、自社の端末の登録にデバイス コード フローを使っている場合は、その登録も止まります。その場合は、デバイス登録サービスを除外するかを検討します。

一度使ったセッションは、後の更新でも止まる

条件付きアクセスは、セッションが最初にどの方法で始まったかを覚えています。一度デバイス コード フローで始まったセッションは、その後のトークンの更新でもポリシーの対象になります。サインイン ログでは「元の転送方法」の欄で確かめられます。

認証の転送も、あわせて検討する

同じ「認証フロー」の条件では、認証の転送も選べます。パソコンの Outlook に表示した QR コードをスマートフォンで読み取り、サインインした状態をスマートフォンに移す機能です。Learn ではプレビューと表記され、既定ですべての利用者に有効です。Microsoft のゼロトラストのガイダンスは、これもブロックするよう勧めています。

Microsoft が管理するポリシー「デバイス コード フローをブロックする」

2025年3月に、Microsoft が管理する条件付きアクセスのポリシーとして、デバイス コード フローを制限するポリシーが一般提供になりました。テナントに自動で作られ、次のように進みます。

1. 「レポート専用」の状態で作られる
2. 有効になる2週間前に、メールとメッセージ センターで通知される
3. レポート専用のまま放っておくと、作られてから30日以上たったあとに、Microsoft が有効にする

Learn の前提条件には「Microsoft Entra ID P2 または Microsoft 365 Business Premium」と書かれています。条件付きアクセスの一覧でこのポリシーがあるかを確かめ、無ければ前の章のとおり自分で作ります。あれば、レポート専用の結果を見て、例外を足してから有効にします。

ほかのポリシーと矛盾なく組み立てる方法は条件付きアクセスをポリシープランで整理するで、緊急用のアカウントの持ち方はMicrosoft 365・Azureの特権ID管理で解説しています。

攻撃者に端末を登録させない

Microsoft が公表した攻撃では、トークンを手に入れた攻撃者が、自分の端末を Entra ID に登録していました。登録された端末は組織の端末として扱われるため、居座りに使われます。2026年4月の記事では、10分以内に登録まで進んだ例もありました。

端末の登録は、次の2か所で絞れます。

• 条件付きアクセスのユーザー操作「デバイスの登録または参加」：登録や参加のときに多要素認証を求める。Microsoft はこの方法を勧めている。使う場合は、Entra 管理センターのデバイスの設定にある「多要素認証を必須にする」を「いいえ」にしておく（そうしないとポリシーが正しく効かない）
• デバイスの設定：端末を Entra ID に参加させられる利用者を、必要な人だけに絞る。なお、Intune を構成していると、端末の登録の設定は「すべて」に固定され、絞れない

これらは端末の登録の入口を固める設定で、デバイス コード フローのブロックの代わりにはなりません。両方をあわせて設定します。

被害が出たときの対応｜パスワードの変更だけでは足りない

利用者がパスワードを変えても、多要素認証などパスワード以外の方法を経て発行された更新トークンは失効しません。デバイスコードフィッシングで渡るのは、まさにこのトークンです。対応は、次の順で進めます。

1. アカウントを一時的に無効にする：セッションを取り消しても、発行済みのアクセストークンは最長1時間使えるため、その間の操作を止める
2. サインイン セッションを取り消す：その利用者の更新トークンをすべて失効させる
3. 登録された端末を確かめる：見覚えの無い端末は無効にする。端末を無効にすると、その端末のトークンも失効する。削除は元に戻せないので、調べ終えてから行う
4. メールボックスを確かめる：攻撃者が作った受信トレイのルール（転送や削除）が無いかを見る

検知は Microsoft Defender XDR で

Microsoft Defender XDR には、デバイスコードフィッシングによるアカウントの侵害や、その後の端末の登録を知らせるアラートがあります。Microsoft Entra ID Protection には、この手口だけを名前にした検出はありませんが、匿名の IP アドレスからのサインインなどの検出が手がかりになります。サインインのリスクに応じたポリシーもあわせて設定します。

なお、Teams のチャットや会議を使った誘い出しと、Teams の外部アクセスの設定は別の記事（Teamsの外部チャットを使ったなりすましを防ぐ）で扱います。AI エージェントを乗っ取る攻撃はプロンプトインジェクション対策で解説しています。

弊社の支援

弊社は、Microsoft 365 と Azure の導入とセキュリティ設定を支援しています。デバイス コード フローを止める設定は短時間で作れますが、どの機器が使っているかを洗い出し、例外の範囲を決める作業に時間がかかります。

サインイン ログの確認から、条件付きアクセスのポリシーの設計、端末の登録の絞り込み、被害が出たときの手順づくりまでをご一緒に進めます。メールで届く攻撃への備えはMicrosoft 365のメールセキュリティ対策（Defender for Office 365編）で、セキュリティ対策の全体像はゼロトラストとはで解説しています。

よくあるご質問

こちらをクリックして「よくある質問」を表示

パスキーを入れていれば、デバイスコードフィッシングは防げますか？

パスキーなどフィッシングに強い多要素認証は、偽のサイトに入力させる攻撃に強い仕組みです。デバイスコードフィッシングでは、利用者は本物の Microsoft のページでサインインするため、多要素認証だけでは止めきれません。条件付きアクセスでデバイス コード フローそのものを止めます。

デバイス コード フローを止めると、業務に影響しますか？

Microsoft は、デバイス コード フローは利用者にはめったに使われないと説明しています。会議室の機器などで使っている場合があるため、サインイン ログで使っている機器を確かめ、ポリシーをレポート専用で動かしてから有効にします。

Microsoft 365 E3 でも設定できますか？

できます。条件付きアクセスには Microsoft Entra ID P1 が要り、Microsoft 365 E3 と Business Premium に含まれています。認証フローの条件は、Microsoft Learn ではプレビューと表記されています。

Microsoft が管理するポリシーがあれば、自分で作らなくてよいですか？

テナントにそのポリシーがあれば、それを使えます。レポート専用で作られ、放っておくと30日以上たってから Microsoft が有効にするので、その前に結果を確かめて例外を決めておきます。ポリシーが無ければ、自分で作ります。

コードを入力してしまったら、パスワードを変えれば大丈夫ですか？

パスワードの変更だけでは、多要素認証を経て発行されたトークンは失効しません。アカウントを一時的に無効にし、サインイン セッションを取り消して、登録された端末に見覚えの無いものが無いかを確かめます。

利用者への教育で防げますか？

「身に覚えの無いコードを入力しない」と伝えることは Microsoft も勧めています。ただ、利用者が見るのは本物の画面で、文面も AI で作り込まれています。教育だけに頼らず、デバイス コード フローを止める設定とあわせて行います。

デバイスコードフィッシングは、本物の画面と本物の多要素認証を通るため、利用者も管理者も気づきにくい攻撃です。使っていないデバイス コード フローを止めておけば、この入口は閉じられます。お使いの環境のサインインの状況をお聞かせいただければ、設定の進め方をご提案します。お問い合わせよりお気軽にご相談ください。

関連サービス・関連コラム

• セキュリティ強化支援（ゼロトラスト）
• クラウド導入支援（Microsoft 365）｜安全で生産性の高い働き方の基盤を構築
• Microsoft 365の多要素認証を見直す｜SMS・音声の廃止に備えた、パスキーへの移行手順
• 条件付きアクセスをポリシープランで整理する｜共有条件で除外漏れとポリシーの乱立を防ぐ
• Microsoft 365・Azureの特権ID管理｜PIMで管理者権限を必要なときだけ有効にする
• Microsoft 365のメールセキュリティ対策（Defender for Office 365編）｜標準の保護とPlan 1・Plan 2の違いと、なりすまし対策の設定
• 多要素認証を突破する中間者型フィッシング（AiTM攻撃）を防ぐ｜Microsoft Entra IDでフィッシングに強い認証と準拠端末を必須にする
• Teamsの外部チャットを使ったなりすましを防ぐ｜外部アクセスを許可ドメインに絞り、ゲストと会議の設定を見直す
• ゼロトラストとは｜中小企業がMicrosoft 365で始めるセキュリティ

まずは無料トライアルで、効果をご確認ください

「AIプライベート」は短期・低コストで試せます。帳票入力（AI-OCR）・電話対応（AI-Voice）・計画づくり（AI-Enhance）の自動化から、クラウド（Azure・Microsoft 365）・DXのご相談まで、お気軽にどうぞ。