この記事の要点
- デバイスコードフロー攻撃は、認証情報ではなく別デバイスで発行された正規トークンを盗む手口のため、パスキーやMFAを設定していても防げません。
- Entra ID（旧Azure AD）のサインインログでは「認証プロトコル」列がdevice codeになっているログインを確認することで、この攻撃の痕跡を検証できます。
- Entra IDの条件付きアクセスにある「認証フロー」の条件を使うと、デバイスコードフローそのものをテナント単位でブロックできます（参考: Microsoft Learn）。
パスキーを導入すればフィッシングは防げる、と思っていないでしょうか。デバイスコードフロー攻撃は、その前提を崩す手口です。認証画面自体を偽装せず、正規のログイン画面にユーザー自身を誘導する点が特徴です。この記事では仕組みと、Entra IDでの検証・防御方法を整理します。
デバイスコードフローとは何か
デバイスコードフローは、キーボード入力がしにくい機器向けにOAuth 2.0が用意した認証方式です。テレビやIoT端末、CLIツールなどで使われます。
流れは次の通りです。
- 端末がAPI経由でデバイスコードとユーザーコードを取得する
- ユーザーは別のPCやスマホでmicrosoft.com/devicelogin を開く
- ユーザーコードを入力し、通常通りサインインする
- 端末側が裏でポーリングし、認証完了後にアクセストークンを受け取る
仕様の詳細はMicrosoft LearnのOAuth 2.0 device authorization grant flowにまとまっています。ここまでは正規の便利機能です。
なぜパスキーやMFAをすり抜けるのか
攻撃者は自分の端末で正規のデバイスコード発行リクエストを送り、表示されたユーザーコードをフィッシングメールやチャットでターゲットに送りつけます。「会議に参加するにはこのコードを入力してください」といった文面です。
被害者は本物のMicrosoftログイン画面でパスキーやMFAを使い、正しく認証します。ところが受け取ったトークンは、攻撃者が用意した端末に渡ります。認証自体は正規のプロセスなので、パスキーの耐フィッシング性は発揮のしようがありません。盗まれるのはパスワードではなく、認証後のセッショントークンだからです。
Microsoft Threat Intelligenceは2025年2月、Storm-2372という攻撃グループがこの手口を使ったフィッシングキャンペーンを行っていたと公表しています（Microsoft Security Blog）。TeamsやWhatsAppなど、メール以外の経路で誘導していた点が報告されています。
攻撃シナリオを整理する
典型的な流れをまとめると、次のようになります。
| 段階 | 攻撃者の行動 | 被害者の行動 |
|---|---|---|
| 1 | デバイスコードを発行し保存 | 特になし |
| 2 | チャットやメールでコード入力を依頼 | 依頼を受け取る |
| 3 | 反応を待つ | 正規画面でコードを入力・認証 |
| 4 | ポーリングでトークンを取得 | 何も異常を感じない |
被害者側の画面には偽サイトが一切登場しません。これが従来のフィッシング対策研修が効きにくい理由です。URLを確認する習慣も、証明書を見る癖も無力です。
Entra IDのサインインログで検証する方法
自組織が既に狙われていないかは、サインインログで確認できます。Entra管理センターの「サインインログ」で、列の表示設定から「認証プロトコル」を追加してください。
確認手順は以下の通りです。
- Entra管理センターにアクセスし、監視と正常性からサインインログを開く
- 列のカスタマイズで「認証プロトコル」を表示項目に追加する
- 値が device code のログを抽出する
- 発生元IPアドレスや場所が、利用者の普段の環境と一致するか確認する
CLIツールなど正規利用がある組織では、業務での利用と攻撃を区別する必要があります。判断が難しい場合は、対象ユーザーに直接確認するのが確実です。サインインログの項目定義はMicrosoft Learnのサインインログ概要に説明があります。
筆者も検証用のEntra IDテナントで、サインインログの認証プロトコル列を実際に表示してみました。通常のブラウザログインとdevice codeのログでは表示される認証方式の情報が異なり、フィルタ一つで分離できることを確認できました。本番環境での大量ログ調査は、この列だけでは負荷が高いため、後述の防御策と併用するのが現実的だと感じました。
Entra IDでの防御策：認証フローを条件付きアクセスで制限する
もっとも直接的な対策は、業務でデバイスコードフローを使わない組織であれば、条件付きアクセスでフロー自体をブロックすることです。
設定の要点は次の通りです。
- 条件付きアクセスポリシーを新規作成する
- 「条件」の「認証フロー」で、対象に device code flow を選択する
- 対象ユーザーとアプリケーションのスコープを決める
- アクセス制御で「ブロック」を選択する
- まずはレポート専用モードで影響を確認してから本番適用する
手順とライセンス要件はMicrosoft Learnの認証フローに関する条件付きアクセスポリシーに記載されています。全ユーザーに一律適用する前に、CLIツールや自動化スクリプトでの正規利用がないかの棚卸しが欠かせません。
デメリット・向いていない人・うまくいかないケース
条件付きアクセスでの一律ブロックには限界もあります。
- Azure CLIやGitHub Actionsなど、device code flowを正規に使うCI/CD基盤がある組織では、ブロックにより業務が止まる可能性があります
- Conditional Accessの利用にはEntra ID P1以上のライセンスが必要で、無償プランのテナントでは同等の制御ができません
- サインインログの目視確認だけでは、業務利用と攻撃を機械的に区別しづらく、運用負荷が高くなります
- 従業員教育だけに頼る対策は、前述の通りURL確認が効かない攻撃のため、単独では不十分です
小規模組織やCLIツールを多用する開発チームでは、いきなり全面ブロックせず、対象アプリやグループを絞った段階的な適用が現実的です。
よくある質問
Q. デバイスコードフロー攻撃はパスキーを設定していても防げませんか。
A. 防げません。攻撃対象は認証情報ではなく認証後のトークンで、パスキーによる本人確認自体は正規に完了してしまうためです。
Q. どのサービスがデバイスコードフローの標的になりますか。
A. Microsoft 365やAzureなど、Microsoft Entra IDと連携する認証を持つサービス全般が対象になり得ます。
Q. 自社が既に攻撃を受けていないか、すぐ確認する方法はありますか。
A. Entra管理センターのサインインログで「認証プロトコル」列にdevice codeが記録されたログを抽出して確認します。
Q. Conditional Accessでブロックすると業務に影響しませんか。
A. CLIツールなどで正規利用している場合は影響します。適用前にレポート専用モードで対象を洗い出す必要があります。
Q. 無償のMicrosoft Entra IDでも対策できますか。
A. 条件付きアクセスによるフロー制限にはP1以上のライセンスが必要です。無償プランでは主にログ監視での検知が中心になります。
Q. パスキー以外に有効な追加対策はありますか。
A. 従業員向けに、身に覚えのないコード入力依頼には応じないという運用ルールの周知が補助的に有効です。
Q. この攻撃はMicrosoft Entra ID以外でも起こり得ますか。
A. OAuth 2.0のデバイス認可グラントを実装するIDプロバイダー全般で構造上は起こり得ます。
導入済みの認証フローの棚卸しと、サインインログでの認証プロトコル確認を、まず今週のタスクに入れてみてはどうでしょうか。