デバイスコードフィッシングは、正規の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. 利用者教育
合言葉はシンプルです——「人から送られてきたコードを認証画面に入力しない」。正規のデバイスコードは、自分が、自分の機器で開始したときにだけ入力するものです。メールやチャットで「このコードを入れて」と促されたら、それは攻撃を疑うべきサインです。
実体験：デバイスコードフローを実際に使ったことがあります
デバイスコードフロー自体は、CLI ツールやスマート TV などで実際に使ったことがあります。ブラウザでログインして、その後に表示されたコードを入力すると端末側でもログインが完了するという仕組みで、パスワードを直接入力しなくても認証できるので、最初はかなり便利だと感じました。
ただ、デバイスコードフィッシングについて調べてからは、この仕組みを悪用して、攻撃者が用意したコードをユーザーに入力させることで、攻撃者側のデバイスをユーザーのアカウントに認証させる手法があることを知りました。そのため、最近は「コードを入力してください」と表示されたときも、単純に指示に従うのではなく、どのサービスの認証なのか、どこから要求されているコードなのかを確認するようになりました。便利な認証方式でも、ユーザーが「表示されたコードを入力すればいい」とだけ理解してしまうと、フィッシングに利用される可能性があるというのが印象に残っています。
まとめ
デバイスコードフィッシングは、正規の認証フローと本物のログイン画面を使うため、偽サイトを見破る訓練やMFAだけでは防げません。被害者本人がMFAを通してしまう以上、守りの主役は「条件付きアクセスでフローを止める」「異常なデバイスコード認証と新規デバイス登録を検知する」「侵害時はトークンとデバイスごと失効させる」という設定・運用側にあります。
この攻撃は Quishing や インフォスティーラー と同じく、最終ゴールは「認証済みトークンの奪取＝MFA回避」です。フローの土台は OAuth / OIDC、認証方式の比較は MFA・FIDO2・Passkeyの違い も合わせてご覧ください。
※ 本記事の攻撃者名・統計値・推奨設定は、Microsoft／Okta／各セキュリティベンダーの公表内容および報道に基づきます。製品仕様や推奨は更新されるため、設定時は最新の公式ドキュメントをご確認ください。