はじめに
皆さん、こんにちは。
NTTセキュリティ・ジャパン株式会社 プロフェッショナルサービス部の戸祭 隆行と北村 優真です。業務としてはインシデントレスポンスおよび、それに必要となる調査（デジタルフォレンジック）を行っています。
今回は、Microsoft Entra IDのデバイスコードフローを悪用したフィッシング攻撃を受けた際の、「攻撃成否を調査するポイント」や、「成功と誤認してしまいやすい痕跡」を取り上げます。
※ご注意： Entra ID を含む SaaS 環境では一般に、ログの仕様や挙動が予告なく変更され得ます。ログの見え方や判断観点は、特定の時点・環境での検証に基づくものであり、同一の挙動が保証されるものではありません。 実際の調査では、対象の環境でどのようにログが出力されているかを確認したうえで、参考情報として本記事を活用してください。
前提： フィッシング攻撃でのデバイスコードフローの悪用
デバイスコードフローとは：
デバイスコードフローは、キーボードが無い等の理由で対話的なサインイン操作が難しいIoT機器等の端末に対し、認可を行うためのフローです。 Entra IDに限らず使用される概念ですが、本記事ではEntra IDに関してのみ取り扱います。
正規利用の場合、下記画像のフローとなります。デバイスが認可要求を行い、ユーザはその要求に固有のコード（デバイスコード）を用いて認証・認可を行います。 [1]
デバイスコードフローの悪用方法：
昨今、このデバイスコードフローは、フィッシング攻撃（=デバイスコードフィッシング攻撃）によく悪用されています。
悪用されやすい理由は以下2点が考えられます。
- ユーザがフローに慣れておらず騙しやすい
- ユーザが操作する認証・認可の画面がMicrosoft公式のもので、攻撃者インフラを経由しないため、認証・認可画面の真正性だけに注意しているユーザにはフィッシング攻撃と気づかれにくい
デバイスコードフィッシング攻撃では、典型的には下記画像のフローとなります。 [2]
フローの内容としては、初めに攻撃者が認可要求を行い、その認可要求に固有のデバイスコードと検証用URLを得て、被害者となる正規ユーザにメールなどを用いて送ります。被害者はそのデバイスコードを用いて、認証（ID・パスワード入力およびMFA）と認可を行います。
その結果、攻撃者は被害者のアカウントを利用してMicrosoft365等を操作することが可能になります。典型的には、ファイルやメールの窃取や、攻撃メール送信の踏み台、その他いろいろな悪事に利用される可能性があります。Microsoft365はメールやファイル管理といった業務上重要な役割を担うため、業務への影響も甚大になり得ます。よってこの攻撃の防御、発生後の検知・被害内容特定は非常に重要です。
調査方法： Entra IDサインインログを用いた、デバイスコードフローによる侵害アカウント特定
デバイスコードフィッシング攻撃の恐れがある場合の調査は、下記2-stepで行います。②は一般的な調査となるため、本記事では、①の「侵害アカウントの特定」についてのみご説明します。
- ①侵害されたアカウントの特定
- ②侵害されたアカウントでの操作内容の特定
侵害成功したアカウントの特定方法：
侵害成功（=デバイスコードフローの成功）の際に残る痕跡は、以下の特徴を持ちます。
- 特徴1: Entra ID 対話型サインインログ・非対話型サインインログ、両方について「成功」ログが出る
- 特徴2: 上記ログは「元の転送方法(Original Transfer Method)」が 「Device Code Flow」となる
- 特徴3: 上記ログは「クライアントIPアドレス（Client IP Address）」が、攻撃者のIPアドレスとなる
もっとも特筆すべきは、直感に反する特徴3です。サインイン操作（認証・認可操作）を行うのはフィッシング被害者であるため、クライアントIPアドレスとして被害者のIPアドレスが記録されることを期待してしまいますが、実際には（最初に認可を要求した）攻撃者のIPアドレスが記録されます。
つまり、デバイスコードフローによる侵害有無の特定の1番のカギは、「攻撃者IPアドレスをクライアントIPアドレスとした、デバイスコードフローによる、対話型サインインの成功ログが出ているかどうか」です。
これを用いて、デバイスコードフィッシング攻撃により侵害されたアカウント（認証・認可操作をしてしまった被害者アカウント）を以下のように特定することが可能です。
- 調査方法： 「認証プロトコル」がDevice codeとなっていて、「状態」が成功、そして「接続元IPアドレス」が普段被害者が使わないIPアドレス（=攻撃者のIPアドレス）となっているEntra ID 対話型サインインログをもつアカウントを探せばよいです
- ※さらに、攻撃者がトークンを得たかどうかまで確認する場合、上記の対話型サインイン成功ログと同じ「相関ID」を持つ非対話型サインイン成功ログが有ることを確認します（ただし、被害者がデバイスコードフィッシングにより認証・認可操作を完了したものの、攻撃者がトークンを得なかったというケースは攻撃者側のスキル不足やトラブルを除き珍しいと考えます）
また、デバイスコードフィッシングにより、認証・認可操作を途中まで行ったが、最終的に成功はしていないアカウント（=侵害はされていないが、ひっかかりかけた）の特定方法としては以下のようになります。
- 調査方法： 「元の転送方法」がDevice code flowとなっていて、「状態」が中断または失敗となっている対話型サインインログを持つアカウントを特定します。それらログの「相関ID」と同じIDを持つ、対話型サインイン成功ログが無いことが確認できれば、それらが「ひっかかりかけたアカウント」です。（もし対話型サインイン成功ログがあれば、前述の「侵害されたアカウント」に該当します）
侵害成功したアカウントだと誤認しやすいケース：
上述の通り、デバイスコードフローは比較的分かりやすい痕跡が残りますが、成功と誤認しやすい痕跡に注意が必要です。
以下のケースでは、デバイスコードフローによる認証・認可は本来成功していませんが、成功しているものと誤認しやすいです。
- 攻撃者IPアドレスをクライアントIPアドレスとした、対話型サインイン成功ログが無い
- （にもかかわらず）攻撃者IPアドレスをクライアントIPアドレスとした、非対話型サインイン成功ログは有る
つまり、攻撃者IPアドレスに関連した非対話型サインイン成功ログだけを見て「デバイスコードフローによる認証・認可が成功し、攻撃者のデバイスが認可されている」と誤認してしまわないよう注意が必要です。
あくまで「対話型サインイン成功ログがある」ことを必須条件として、侵害成功を判断する必要があります。
具体的ログ解説： 典型的なデバイスコードフロー成功/失敗の痕跡、成功と誤認しやすい痕跡
ここではデバイスコードフローの成功/失敗時におけるログの痕跡と、成功と誤認しやすいログの痕跡について具体的な説明をしています。
成功の痕跡:
前述のデバイスコードフィッシング攻撃によるデバイスコードフローが成功した場合、以下のログが発生します。
表1：成功の痕跡例
番号 | サインインの種類 | 状態（Status） | 相関ID（Correlation ID) | クライアントIPアドレス（ClientIP) | 認証プロトコル(Authentication Protocol) | 元の転送方法(Original Transfer Method) | アプリケーション | リソース（Resource） |
|---|---|---|---|---|---|---|---|---|
① | 対話型 | 失敗: エラーコード50199 | 一連のサインインログと同一 | 攻撃者のIPアドレス(*1) | None | Device code flow | 攻撃者が要求したもの（*2） | 攻撃者が要求したもの（*3） |
② | 対話型 | 成功 | 一連のサインインログと同一 | 攻撃者のIPアドレス(*1) | Device code | Device code flow | 攻撃者が要求したもの（*2） | 攻撃者が要求したもの（*3） |
③ | 非対話型 | 成功 | 一連のサインインログと同一 | 攻撃者のIPアドレス(*1) | None | Device code flow | 攻撃者が要求したもの（*2） | 攻撃者が要求したもの（*3） |
(*1) デバイスコードフローを開始した攻撃者端末のIPアドレス
(*2) 典型的には Microsoft Office など
(*3) 典型的には Microsoft Graph など
注意すべきポイントは、最初に①のエラーコード50199による対話型サインイン失敗ログが出る点です。（※このエラーコードはセキュリティ上の理由からユーザの操作が必要であったことを示すものです。理由の詳細は不明ですが、被害者によるデバイスコードの入力だけではデバイス認可は不可能で、ユーザによる明示的な認証や認可の操作が必要だったということを示すものと推測します。）
失敗というログに惑わされず、同じ相関IDを持つ成功ログが無いか調査する必要があります。
②の対話型サインインの成功があれば、被害者による認証・認可操作は成功しています。ここがもっとも重要なポイントです。
③は、攻撃者がトークンを受け取った場合に発生します。通常、攻撃者はトークン入手用APIをポーリングしているため、②のあと比較的早期に③が発生します。
失敗の痕跡:
デバイスコードフローに失敗したケース（※被害者がデバイスコードを入力し、ID等を入れ認証操作を開始したものの、途中で離脱した等で認証に失敗した、または認証したものの認可をキャンセル等）では、以下のようなログが発生します。
表2：失敗の痕跡例
サインインの種類 | 状態（Status） | 相関ID（Correlation ID) | クライアントIPアドレス（ClientIP) | 認証プロトコル(Authentication Protocol) | 元の転送方法(Original Transfer Method) | アプリケーション | リソース（Resource） |
|---|---|---|---|---|---|---|---|
対話型 | 中断/失敗 | 独自（他に同じIDを持つログ無し） | 攻撃者のIPアドレス(*1) | None | Device code flow | 攻撃者が要求したもの（*2） | 攻撃者が要求したもの（*3） |
(*1) デバイスコードフローを開始した攻撃者端末のIPアドレス
(*2) 典型的には Microsoft Office など
(*3) 典型的には Microsoft Graph など
このログと同じ相関IDを持つ別な対話型サインイン成功ログが無いことが確認できれば、失敗と判断します。
成功と誤認しやすい痕跡:
成功と誤認しやすい痕跡として、前述の「対話型サインイン成功」はないが「非対話型サインイン成功」だけはある、といったものが挙げられます。具体的なログ例は下表のとおりです。
表3：成功と誤認しやすい痕跡例
サインインの種類 | 状態（Status） | 相関ID（Correlation ID) | クライアントIPアドレス（ClientIP) | 認証プロトコル(Authentication Protocol) | 元の転送方法(Original Transfer Method) | アプリケーション | リソース（Resource） |
|---|---|---|---|---|---|---|---|
対話型 | 中断/失敗 | 独自（他に同じIDを持つログ無し） | 攻撃者のIPアドレス(*1) | None | Device code flow | 攻撃者が要求したもの（*2） | 攻撃者が要求したもの（*3） |
非対話型 | 成功 | 独自（他に同じIDを持つログ無し） | 攻撃者のIPアドレス(*1) | None | Device code flow | Microsoft App Access Panel | Windows Azure Active Directory |
非対話型 | 成功 | 独自（他に同じIDを持つログ無し） | 攻撃者のIPアドレス(*1) | None | Device code flow | Microsoft App Access Panel | Microsoft App Access Panel |
非対話型 | 成功 | 独自（他に同じIDを持つログ無し） | 攻撃者のIPアドレス(*1) | None | Device code flow | Microsoft App Access Panel | My Signins |
非対話型 | 成功 | 独自（他に同じIDを持つログ無し） | 攻撃者のIPアドレス(*1) | None | Device code flow | Microsoft App Access Panel | Microsot Password reset service |
非対話型 | 成功 | 独自（他に同じIDを持つログ無し） | 攻撃者のIPアドレス(*1) | None | Device code flow | Microsoft App Access Panel | Graph |
(*1) デバイスコードフローを開始した攻撃者端末のIPアドレス
(*2) 典型的には Microsoft Office など
(*3) 典型的には Microsoft Graph など
このような誤認を引き起こす痕跡は、以下の特別な認証フローが発生した際に記録されることが検証から判明しています。
- MFA新規登録: ID・パスワード入力後、ユーザがMFAを1つも登録しておらず、MFAの新規登録画面になったとき
- MFA更新確認: ID・パスワード入力、MFA操作後に、MFAの状態を確認する画面（「アカウントをセキュリティ保護しましょう」→「情報のレビュー」）となったとき
これらのフローで、対話型サインインの完了前にも関わらず、非対話型サインインの成功ログが出る原因を考察しました。主に、（サインイン操作の完了前に）MFA情報等の参照のためEntra ID ディレクトリ情報へのアクセスが発生することにより、システム間連携によるサインインが発生するためと推測します。
ログ上はクライアントIPアドレスとして攻撃者IPアドレスが記録されますが、これに惑わされてはいけません。攻撃者の認可要求に端を発する認証・認可フローの中で発生したものであるため、ログ上はクライアントIPアドレスとして（実際に認証・認可操作をしている被害者のIPアドレスではなく）攻撃者のIPアドレスが記録されると考えられます。
ご紹介した「攻撃者IPアドレスに関する、非対話型サインイン成功ログの発生」だけで、「攻撃者がトークンを入手してMicrosoft 365に接続できている」ように見えてしまいますが、対話型サインインの成功ログの有無がまず重要ですので、そちらを必ずご確認ください。
まとめ
今回はデバイスコードフローに関するログの見え方を整理しました。ポイントは以下の通りです。
- デバイスコードフィッシングの調査で大事な1st stepは、デバイスコードフローによる認証・認可が行われたアカウント（=侵害アカウント）の特定です
- 侵害アカウントの特定には、（デバイスコードに関わる）Entra ID対話型サインイン成功ログを探すことが最も大事です
- 具体的には「認証プロトコル」がDevice codeとなっていて、「状態」が成功、そして「接続元IPアドレス」が普段被害者が使わないIPアドレスとなっているEntra ID 対話型サインインログをもつアカウントを特定すればよいです
- 侵害成功と誤認しやすいケース「（攻撃者のIPアドレスをクライアントIPアドレスとした）対話型サインイン成功ログが無いが、非対話型サインイン成功ログが有る」に注意が必要です。あくまで対話型サインイン成功がキーポイントです
対話型サインインが成功せずとも、非対話型サインインの成功ログが出るケースがあることは、他の認証・認可方式や攻撃パターンを調査する際にも重要な観点になり得ると感じています。
Microsoft 365は機能が豊富で仕様も複雑です。今後も、判断に役立つ・判断を誤りやすいポイント等を発見したら、今後とも検証、整理していきたいと考えています。
Microsoft 365関連の調査でお困りの際は、弊社までご相談いただければと思います。
参考文献
- [1] “Microsoft ID プラットフォームと OAuth 2.0 デバイス承認付与フロー”,Microsoft Learn,2025/04/02,https://learn.microsoft.com/ja-jp/entra/identity-platform/v2-oauth2-device-code (参照日：2026-04-27)
- [2] ”Storm-2372 conducts device code phishing campaign”,Microsoft Security Blog,2025/02/24,Storm-2372 conducts device code phishing campaign | Microsoft Security Blog (参照日：2026-05-07)
.png)