デバイスコードフィッシングは、正規のMicrosoftログイン画面を使うフィッシングです。偽サイトもAitMプロキシも要りません。被害者は本物の microsoft.com/devicelogin でログインし、自分の手でMFAを完了させる——にもかかわらず、発行されたトークンは攻撃者の手に渡ります。多要素認証は、この攻撃に対してほとんど無力です。
Microsoft が Storm-2372 と名付けたロシア系の攻撃グループは、この手口で政府・NGO・各種業界を狙ってきました。2026年初頭にかけて攻撃は37倍に急増し、PhaaS（Phishing-as-a-Service）プラットフォーム EvilTokens の登場で「誰でも使える攻撃」へと商品化。5か国340以上のMicrosoft 365組織が標的になったと報告されています。本記事は、なぜMFAが効かないのか、その仕組みと対策を整理します。
そもそもデバイスコードフローとは
デバイスコードフロー（OAuth 2.0 Device Authorization Grant, RFC 8628）は、キーボードのない・入力しづらい機器のための正規の認証方式です。スマートTV、CLIツール、IoT機器などが対象で、流れはこうです。
- 機器が認証サーバに要求し、短いコード（例: ABCD-EFGH）と認証用URLを受け取る。
- 利用者は別の端末（スマホやPC）でそのURLを開き、コードを入力してログイン・MFAを済ませる。
- その間、機器はサーバをポーリングし続け、認証が完了するとアクセストークンとリフレッシュトークンを受け取る。
仕組み自体は OAuth / OpenID Connect の正規仕様です。問題は、「コードを入力する人」と「トークンを受け取る機器」が別物でよいという設計を、攻撃者が悪用できる点にあります。
攻撃の仕組み：なぜMFAが効かないのか
攻撃者は、この正規フローに自分が「機器」として割り込みます。
- 攻撃者が、標的のテナント向けにデバイスコードフローを開始し、有効なコードを取得する（コードの寿命は通常15分程度）。
- そのコードを、フィッシングのエサとして被害者に送る。「Teams会議に参加するにはこのコードを入力してください」「共有ファイルを開くには認証が必要です」など、ITサポートや同僚を装う。
- 被害者は本物のMicrosoftのURLを開き、コードを入力し、自分でID・パスワード・MFAを完了する。画面は正規なので違和感がない。
- 認証が成立した瞬間、ポーリングしていた攻撃者のもとにアクセストークンとリフレッシュトークンが届く。攻撃者は本人として侵入する。
ここが核心です。MFAのチャレンジは、攻撃者の代わりに被害者本人がクリアしている——だからOTPもSMSも、多くの場合 Passkey すら障害になりません。さらに、得られたリフレッシュトークンはパスワードをリセットしても生き残るため、対応が後手に回りやすいのも厄介な点です。
図解案：正規フローと攻撃の違い
【正規】
自分の機器 →コード発行→ 自分がURLでコード入力＋MFA → 自分の機器にトークン
【攻撃（デバイスコードフィッシング）】
攻撃者の端末 →コード発行→ ┐
│ コードをフィッシングで送付
▼
被害者が本物のMS画面でコード入力＋MFA（本人が完了）
│ 認証成立
▼
★攻撃者の端末にトークンが届く（IDもPWもMFAも本人が通した）
要点：偽サイト不要。本物の認証画面のまま、トークンの“受け取り先”だけが攻撃者Storm-2372 の進化：デバイス登録から PRT へ
Storm-2372 は単なるトークン窃取に留まりませんでした。Microsoft Authentication Broker のクライアントIDを悪用してリフレッシュトークンを取得し、攻撃者が管理するデバイスを Entra ID に登録。これにより Primary Refresh Token（PRT） を得て、組織リソースへの深く永続的なアクセスを確立しました。
2026年4月には Microsoft がAIを使って自動化・大規模化されたデバイスコードフィッシングキャンペーンを報告しています。文面生成からコード配布、トークン回収までが自動化され、攻撃の規模とスピードが一段上がりました。前述の EvilTokens のようなPhaaSが、この敷居をさらに下げています。
対策
1. デバイスコードフローを「止める」（最優先）
最も効くのは、使っていないなら、そもそもフローを無効化することです。Microsoft は、過去25日間デバイスコードフローを使っていないテナントにはブロックを推奨しています。条件付きアクセス（Conditional Access）の「認証フロー」条件で Device Code Flow をブロックするポリシーを作成し、まずレポート専用モードで正規利用を洗い出してから本適用します。スマートTVやCLIなど正規の用途がある場合は、特定ユーザー・信頼できる場所に限定して許可します。
2. 検知と監視
- Entra IDサインインログを「認証プロトコル＝Device Code」で絞り込み、過去90日分の利用を棚卸しする。正規利用がほぼ無いはずなら、出現自体が異常シグナル。
- デバイスコード認証の直後48時間以内の新規デバイス登録を要警戒イベントとして検知。
Dsreg/10.0やDeviceRegistrationClientといったUser-Agentは自動登録ツールの痕跡。 - Entra ID Protection の異常なデバイスコード認証アラート、Defender for Office 365 の配信前ブロックを活用する。
3. 侵害時の封じ込め
- パスワードリセットだけでは不十分。リフレッシュトークンを失効（revoke sign-in sessions）させ、生きているトークンを無効化する（ トークン窃取への対応 と同じ考え方）。
- 不審に登録されたデバイスを Entra ID から削除し、PRTを失効させる。
- 継続的アクセス評価（CAE）やトークン保護で、失効が即時に効くようにする。
4. 利用者教育
合言葉はシンプルです——「人から送られてきたコードを認証画面に入力しない」。正規のデバイスコードは、自分が、自分の機器で開始したときにだけ入力するものです。メールやチャットで「このコードを入れて」と促されたら、それは攻撃を疑うべきサインです。
まとめ
デバイスコードフィッシングは、正規の認証フローと本物のログイン画面を使うため、偽サイトを見破る訓練やMFAだけでは防げません。被害者本人がMFAを通してしまう以上、守りの主役は「条件付きアクセスでフローを止める」「異常なデバイスコード認証と新規デバイス登録を検知する」「侵害時はトークンとデバイスごと失効させる」という設定・運用側にあります。
この攻撃は Quishing や インフォスティーラー と同じく、最終ゴールは「認証済みトークンの奪取＝MFA回避」です。フローの土台は OAuth / OIDC、認証方式の比較は MFA・FIDO2・Passkeyの違い も合わせてご覧ください。
※ 本記事の攻撃者名・統計値・推奨設定は、Microsoft／Okta／各セキュリティベンダーの公表内容および報道に基づきます。製品仕様や推奨は更新されるため、設定時は最新の公式ドキュメントをご確認ください。