デバイスコードフィッシングは、正規のログイン画面を使って攻撃者のセッションを承認させる。Microsoft 365で見るべきログ、初動、条件付きアクセスの考え方を整理する。
デバイスコードフィッシングは「本物のログイン」を悪用する
Microsoft 365を使う組織で、MFAやパスキーを導入していても見落としやすい認証フローがある。デバイスコードフローだ。これは、スマートTV、プリンター、共有端末のように入力しづらい機器で、別のブラウザから短いコードを入力してサインインするための正規機能として用意されている。
問題は、この仕組みがフィッシングに転用されると、ユーザーが本物の Microsoft サインイン画面でコードを入力してしまう点にある。偽ログイン画面にパスワードを入れるのではなく、攻撃者が開始したセッションをユーザー自身が承認してしまう。Microsoft は、2026年4月に公開した調査で、AIを使った文面生成や動的なコード生成を組み合わせたデバイスコードフィッシングキャンペーンを観測したと説明している。
この記事では、攻撃の再現手順ではなく、情シス、SOC、CSIRTが確認すべき兆候と初動、平時の設定方針に絞って整理する。デバイスコードフローを業務で使っている組織ほど、禁止か許可かを感覚で決めず、どの端末・場所・用途に限って許可するのかを明文化したい。
- Microsoft 365 / Microsoft Entra IDを中心に、デバイスコードフィッシングの防御と初動確認を扱う。
- OAuth 2.0の仕様解説や攻撃再現ではなく、ログ確認、条件付きアクセス、利用者教育、権限失効に焦点を置く。
- 実害につながる手順、コード、攻撃インフラの作り方は扱わない。
通常のフィッシングと何が違うのか
一般的なパスワードフィッシングは、偽サイトにIDとパスワードを入力させる。AiTM型のフィッシングは、ログインの途中に割り込み、セッションCookieやトークンを奪う。OAuth同意フィッシング は、ユーザーに悪意あるアプリへの権限付与を承認させる。
デバイスコードフィッシングは、これらと似ているが、利用者の見え方が少し違う。メールやチャットに「このコードを入力してください」と誘導され、ユーザーは正規のデバイスログイン画面にアクセスする。そこでコードを入力し、サインインやMFAを完了すると、攻撃者側で開始された認証セッションにトークンが発行される。
| 種類 | ユーザーが見るもの | 攻撃者が狙うもの | 実務上の注意点 |
|---|---|---|---|
| パスワードフィッシング | 偽ログイン画面 | ID / パスワード | パスワードマネージャーやFIDO2で抑止しやすい |
| AiTMフィッシング | 正規に似せた中継画面 | セッションCookie / トークン | フィッシング耐性MFAとセッション監視が必要 |
| OAuth同意フィッシング | 正規の同意画面 | SaaSアプリ権限 | アプリ同意とスコープを管理する |
| デバイスコードフィッシング | 正規のコード入力画面 | 攻撃者側セッションの承認 | デバイスコードフロー自体の利用可否を制御する |
ここで大事なのは、MFAが無意味になるという話ではない。MFAは必要だ。ただし、ユーザーが攻撃者のセッションを正規画面で承認してしまう場合、MFAは「本人が承認した」ことを確認するだけになりやすい。認証を強化した次に、どの認証フローを許可するのかを見直す必要がある。
利用者が気づくべき違和感
デバイスコードフロー自体は正規機能なので、画面だけで悪性かどうかを断定するのは難しい。だからこそ、利用者教育では「コード入力画面を見たら危険」ではなく、「自分がどの端末で、どのアプリにサインインしようとしているのか」を確認する習慣に落とす必要がある。
特に注意したいのは、次のような状況だ。
| 兆候 | なぜ危ないか |
|---|---|
| メール、PDF、Teams風メッセージからコード入力を求められる | 自分が開始していない認証フローの可能性がある |
| 「請求書」「署名」「録音」「規程確認」など急ぎの文脈で誘導される | 判断を急がせ、確認を省略させる狙いがある |
| 端末名、アプリ名、要求元が自分の操作と一致しない | 攻撃者側のセッションを承認している可能性がある |
| 公式ドメインに見えるため安心してしまう | 正規画面が使われる攻撃では、URLだけでは足りない |
| コードが自動コピーされた、または貼り付けを急かされる | 操作の意味を理解させずに承認させる誘導になりやすい |
利用者向けには、「自分がテレビ、プリンター、会議室端末、CLIなどへサインインしているとき以外は、突然出てきたデバイスコード入力に応じない」と伝える方が実務的だ。迷ったときは フィッシング確認チェックリスト に沿って、メール本文、リンク元、要求内容、報告経路を確認する。
デバイスコードフィッシングでは、ユーザーが正規のデバイスログイン画面へ誘導されることがある。URLだけで判断せず、自分が開始したサインインか、どのアプリへ認証しているかを確認する。
管理者がまず見るべきログ
疑わしい連絡や不審なサインインがあった場合、最初に見るべきは「パスワードが漏れたか」だけではない。デバイスコードフローが使われたか、どのユーザーがコード入力を完了したか、認証後にどのリソースへアクセスしたかを確認する。
Microsoft Learnでは、デバイスコードフローを制限・ブロックするポリシーを作る前に、レポート専用モードやサインインログの認証プロトコルフィルターを使って、組織内でどのように使われているか把握する考え方が示されている。いきなり全遮断すると、会議室端末や一部業務端末に影響する場合があるためだ。
| 確認対象 | 見る理由 |
|---|---|
| サインインログの認証プロトコル | Device code flowの利用有無を確認する |
| ユーザー、時刻、IP、場所 | 本人の通常利用と合うかを見る |
| 対象アプリ / リソース | どのアプリの認証として扱われたかを見る |
| 条件付きアクセスの結果 | 許可、ブロック、レポート専用の判定を確認する |
| 直後のメール操作やファイルアクセス | トークン取得後の不審操作を探す |
| 受信トレイルールや転送設定 | 継続的な情報流出や隠蔽を確認する |
疑わしい場合は、ユーザーのパスワード変更だけで終わらせない。セッションの失効、トークンの無効化、メール転送ルールの確認、SaaS連携アプリの棚卸し、端末登録や新規デバイスの確認まで行う。これは インシデント対応 と SaaS権限棚卸しチェックリスト を合わせて使う場面だ。
条件付きアクセスでは「必要な場所だけ許可する」
Microsoft は、デバイスコードフローについて「必要な場合だけ許可し、可能な限りブロックする」方針を推奨している。これは、すべての組織で即時全面禁止すべきという意味ではない。業務で必要な用途を洗い出し、許可範囲を小さくするという意味だ。
現実的には、次の順で進める。
| 段階 | やること | 目的 |
|---|---|---|
| 1 | サインインログで現在の利用状況を確認する | 正常利用を壊さないため |
| 2 | 会議室端末、共有端末、CLIなど正当な用途を洗い出す | 例外条件を明確にするため |
| 3 | レポート専用モードで条件付きアクセスを試す | 影響範囲を見てから有効化するため |
| 4 | 不要な範囲でデバイスコードフローをブロックする | 攻撃面を減らすため |
| 5 | 例外の所有者、期限、レビュー周期を決める | 例外が恒久化しないようにするため |
例外を作るときは、アプリ名だけではなく、ネットワーク場所、端末種別、管理状態、対象ユーザー、業務オーナーをセットで見る。例外の理由が説明できない場合、その例外は将来の侵入口になりやすい。
ゼロトラストアーキテクチャ の観点では、「一度許可した認証フローを恒久的に信頼する」のではなく、認証方法、端末、場所、ユーザー、アプリ、リスクを組み合わせて判断する。デバイスコードフローは便利な例外機能として扱い、通常のサインイン手段として広く開放しない方がよい。
初動対応で確認すること
デバイスコードフィッシングが疑われるときは、通常のフィッシング報告よりも「認証後に何ができたか」を早く見る。ユーザーがコードを入力した、サインインした、MFAを承認した、という情報がある場合は、アカウント侵害の可能性として扱う。
| 順序 | 確認すること | 目的 |
|---|---|---|
| 1 | 該当メール、チャット、添付、URLを保全する | 誘導経路を後から追う |
| 2 | サインインログでDevice code flowを確認する | 認証フローを特定する |
| 3 | ユーザーのセッションとトークンを失効する | 継続アクセスを止める |
| 4 | メール、ファイル、Teams、SharePointのアクセスを確認する | 影響範囲を把握する |
| 5 | 受信トレイルール、転送、外部共有を確認する | 隠蔽や二次流出を探す |
| 6 | 条件付きアクセスと例外設定を確認する | 再発防止につなげる |
ユーザーへの聞き取りでは、「どのURLを開いたか」「どのコードを入力したか」を細かく責めるより、時刻、媒体、操作、表示されたアプリ名、MFA承認の有無を正確に聞く方がよい。報告文は フィッシング報告テンプレート を使うと、原本保全と時系列整理を崩しにくい。
不審メールやPDFを削除すると、送信元、URL、添付、ヘッダー、時刻の確認が難しくなる。社内の報告経路に沿って保全し、必要に応じてSOCやCSIRTへ渡す。
平時に決めておく運用ルール
デバイスコードフィッシング対策は、検知ルールだけでは完結しない。利用者、ヘルプデスク、SaaS管理者、SOCが同じ判断基準を持っている必要がある。
平時には、次のルールを決めておく。
| 項目 | 決めること |
|---|---|
| 利用許可 | デバイスコードフローを使ってよい端末、アプリ、場所 |
| 例外申請 | 誰が申請し、誰が承認し、いつ見直すか |
| 利用者教育 | 突然のコード入力依頼に応じない、報告する、削除しない |
| 監査 | 月次または四半期でサインインログと例外を確認する |
| 初動 | 報告先、ログ確認者、トークン失効担当、復旧判断者 |
ここで重要なのは、禁止だけで終わらせないことだ。会議室端末や一部の業務ツールで正当な利用があるなら、許可範囲を小さく明文化する。逆に、利用実態がないなら、レポート専用モードで影響を見たうえでブロックへ進む。
退職者アカウント確認チェックリスト と同じく、認証フローの例外も放置すると棚卸し漏れになる。例外には所有者と期限を付け、異動や退職で責任者が不明にならないようにする。
まとめ：デバイスコードフローは「例外」として管理する
デバイスコードフィッシングは、偽ログイン画面を見抜く訓練だけでは防ぎにくい。ユーザーが正規のログイン画面で操作するため、URLや画面の見た目だけでは判断できないからだ。防御の中心は、利用者教育、サインインログの確認、条件付きアクセスによる制御、トークン失効を含む初動対応にある。
最初にやるべきことは、組織内でデバイスコードフローが本当に必要かを確認することだ。必要な場合でも、端末、場所、アプリ、ユーザーを限定し、例外に所有者と期限を付ける。不要なら、Microsoft Entra IDの条件付きアクセスでブロックする方針を検討する。
次に読むなら、近い攻撃面として OAuth同意フィッシング、ユーザー報告の整備として フィッシング確認チェックリスト、インシデント時の進め方として フィッシング報告テンプレート を確認すると、認証まわりの防御を実務へ落とし込みやすい。
