Azureにおけるデバイスコード攻撃：悪用から検出まで

TL; DR

それは何ですか： デバイスコードフィッシングは、攻撃者がマイクロソフトに対して正当なデバイスコード認証フローを開始するOAuth悪用手法です。 Entra IDそして、ユーザーをだまして、生成されたコードを実際の login.microsoft.com/devicelogin ページに入力させ、パスワードを一切取得することなく、攻撃者に有効なアクセス トークンを渡します。 

なぜ重要なのか： 国家主導の諜報活動（ロシア関連のSTORM-2372、2024年8月から活動中）から、わずか1年足らずで汎用的な攻撃ツールへと変貌を遂げた。2026年4月にマイクロソフトが公開したEvilTokens PhaaSツールキットは、攻撃の全フローをエンドツーエンドで自動化し、15分間のコード有効期限を回避して、24時間ごとに10～15件のパーソナライズされたキャンペーンを実行する。 

検出が難しい理由： 偽のログインページも、タイプミスを利用したドメインも、認証情報の窃盗も、スキャン対象となる悪意のあるペイロードもありません。関係するURLはlogin.microsoft.com/deviceloginのみです。MFAは被害者の実機で正常に完了するため、メールゲートウェイ、EDR、またはID保護製品が監視するように設定されているすべてのシグナルはクリーンなままです。 

AiTMとの違い： 中間者攻撃は、偽のログインページをプロキシ経由で表示してセッションクッキーを盗み出します。一方、デバイスコードフィッシングはプロキシを完全に回避します。被害者は実際のマイクロソフトのページで認証を行うため、検出、ブロック、または停止させるべき中間者攻撃のインフラストラクチャは存在しません。 

コア検出信号: 認証方法がデバイスコードであり、アクセス対象のリソースがマイクロソフトのファーストパーティクライアント（Azure CLI、Microsoft Officeなど）であり、かつ、通常とは異なる場所から、またはデバイスコードを使用して認証を行わないエンティティによってサインインが成功した場合。正当なエンドユーザーのワークフローでは、このようなパターンはほとんど発生しません。多くの組織にとって、このようなケースはすべて調査の対象となります。 

検出された場合は即座に対応します。 ユーザーのアクセス権を直ちに取り消します（参照： Microsoftのドキュメント侵害されたユーザーを無効化し、そのユーザーの役割割り当てを削除します。リフレッシュトークンを取り消しても、既に発行されたアクセストークンは無効にならないことに注意してください。それらは有効期限が切れるまで有効です。疑わしいセッションから発生した悪意のあるアクティビティを探します。トークンの取り消しだけでは不十分です。攻撃者は既に永続的なアクセスを確立している可能性があります。

主要な政策措置： 業務上の必要性が文書化されていないユーザーに対しては、条件付きアクセスによるデバイスコードフローをブロックしてください。マイクロソフトのガイダンスでも、この方法が推奨されています。ほとんどの企業ユーザー（開発者を含む）は、この方法で正当な認証を行うことはほとんどありません。デバイスコード認証が真に必要とされる場合は、ジオフェンシングを使用して信頼できる場所のみに制限してください。 

セキュリティチームがデバイスコードフィッシングについて知っておくべきこと

国家主導の脅威アクター（STORM-2372、ロシアの国家利益と関連）は、2024年8月から、世界中の政府機関、防衛関連企業、NGO、通信会社、エネルギー企業、医療機関を標的としたデバイスコードフィッシングキャンペーンを展開している。 

これはマイクロソフトがパッチを適用できる脆弱性ではなく、主要なIDプロバイダーすべてがサポートするOAuth 2.0デバイスコードプロトコルの設計上の特性です。この攻撃は、 MFA （被害者は自発的に完了する）、セキュリティツールがフラグを立てるような疑わしいインフラストラクチャは残さない（唯一のURLはmicrosoft.com）、そして結果として得られるトークンはパスワードリセット後も残る。従来のメールゲートウェイ、CASB、およびURLスキャナーは、この攻撃リンクを安全と評価する。 is 安全です。マイクロソフト自身のログインページに誘導されます。 

侵害後、攻撃者は10分以内に永続的なデバイスを登録し、Microsoft Graphを介して組織構造をマッピングし、価値の高いターゲット（財務、経営幹部、管理職など）をフィルタリングし、隠し受信トレイルールを作成し、送金の詳細や経営幹部の通信内容など、ビジネスメール詐欺や金融詐欺の材料となる情報を抜き取っていることが確認されている。 

直ちに組織的に行うべきこと: 明示的に必要としないすべてのユーザーに対して条件付きアクセスによるデバイスコード認証フローをブロックし、 インシデント対応 プレイブックには、OAuthトークンの失効（パスワードのリセットだけでなく）と、高額アカウントへのトークンバインディングの導入が含まれています。意思決定フレームワークの詳細は、下記の戦略的推奨事項をご覧ください。

フィッシングサイトのURLがmicrosoft.comだったらどうなるでしょうか？

デバイスコードフィッシングは、MicrosoftのOAuthデバイスコードフローの実装を悪用するトークン窃盗の手法です。一般的なフィッシングキャンペーンとは異なり、攻撃者は被害者を偽ドメインやリバースプロキシ、タイポスクワッティングではなく、実際のMicrosoftのURLに誘導します。被害者は本物のMicrosoftログインページにサインインし、正規のMFAを完了して、通常の成功画面が表示されます。しかし、被害者に権限を付与する追加の認証方法である認証トークンは、全く別のマシン上の攻撃者に密かに送信されます。認証情報の窃盗も、セッションハイジャックも、検出や停止が必要な攻撃者のインフラストラクチャもありません。ただ、正当なOAuthフローが、本来の目的どおりに、間違った相手に渡ってしまうだけです。 

これは今日大規模に悪用されており、根本的な欠陥はOAuth標準自体にあるものの、 Entra IDの実装が、それを兵器化することを容易にしている。マイクロソフトは、 STORM-2372に対する進行中のキャンペーンロシアの国家利益に合致していると中程度の確信度で評価された脅威アクター。この作戦は、少なくとも2024年8月以降、複数の大陸にわたる政府機関、防衛関連企業、NGO、通信事業者、エネルギー企業、医療機関を標的としている。2026年4月、マイクロソフトは、この作戦の著しいエスカレーションを記録した。 EvilTokensの登場は、デバイスコードの悪用をエンドツーエンドで自動化する、AI対応のフィッシング・アズ・ア・サービス（PhaaS）ツールキットである。15分間の有効期限を回避するためにオンデマンドでライブコードを生成し、生成AIを使用して超パーソナライズされた誘い文句を作成し、24時間ごとに10～15種類の異なるキャンペーンを実行する。この技術は、わずか1年足らずで国家レベルの諜報活動から、誰もが利用できる攻撃ツールへと変化した。  

このブログ記事では、この攻撃がプロトコルレベルでどのように機能するかを詳細に解説し、実際のデータを使った実践的なシミュレーションを行います。 Entra ID ログキャプチャを提供し、今日から自分の環境で実行できるKQLハントクエリを提供するとともに、攻撃によって生成されたログから導き出された検出ロジックを拡張します。 

デバイスコードの流れとは何ですか？

RFC 8628で定義され、2019年8月に公開されたOAuth 2.0デバイス認証グラントは、ブラウザを搭載していない、または入力機能が限られているデバイス（スマートテレビ、ゲーム機、IoTセンサー、デジタルサイネージ、会議室用ハードウェア、Azure CLIやAWS CloudShellなどのCLIツールなど）向けに設計された認証フローです。デバイス上で直接サインインする代わりに、ユーザーには短い英数字コードとURLが表示されます。ユーザーは別のデバイス（通常はスマートフォンやノートパソコン）でそのURLを開き、コードを入力して、MFAプロンプトを含む認証を完了します。一方、元のデバイスはバックグラウンドで認証サーバーにポーリングを行い、ユーザーが承認するとアクセストークンを受け取ります。 

このフローは広くサポートされています: マイクロソフト Entra IDGoogle、GitHub、Okta、およびほとんどの主要なIDプロバイダーがこれを実装しており、Azure CLI（`az login`）のデフォルトのサインイン方法となっています。日常的なWebアプリケーションで最も一般的なOAuthフローではありませんが、ヘッドレス環境や入力制約のある環境における標準的なメカニズムであり、エンタープライズツール、DevOpsパイプライン、および消費者向けストリーミングプラットフォームで広く使用されています。 

設計上のリスクは規格に内在するものですが、 Entra IDの実装はこれらの問題を増幅させるため、実際に出回っているフィッシングキットはすべてマイクロソフトを標的にしています。マイクロソフト自身も現在、明示的に必要でない限り、条件付きアクセスを使用してトラフィックの流れをブロックすることを推奨しています。 

重大な設計上の欠陥： device_codeは、ポーリングデバイスと認証ユーザーを結びつける唯一のリンクです。Microsoftは、ポーリングデバイスがユーザーが認証しようとしたデバイスであるかどうかを検証しません。デバイスの識別情報、ネットワーク上の位置情報、信頼関係の有無などは一切確認しません。コードを持っていて、そのコードをポーリングしているユーザーは誰でもトークンを取得できます。 

攻撃分析

デバイスコードフローの利便性こそが、悪用される原因でもある。このプロトコルはポーリングデバイスと認証ユーザーを直接結びつけないため、有効なデバイスコードを入手した攻撃者は、結果として得られるアクセス情報を密かに収集し、被害者がサインインを完了した瞬間にトークンを更新できる。フィッシングインフラも、認証情報の傍受も、多要素認証のバイパスも必要ない。ただ、本来の設計どおりに動作する正規のMicrosoftログインページが、悪意のある第三者のために利用されているだけなのだ。 

攻撃者がこの流れをどのように武器化するか

マイクロソフトのデバイスコードエンドポイントは、設計上オープンです。クライアントシークレットも、デバイス登録も、所有権の証明も必要ありません。

攻撃者は、よく知られた Microsoft クライアント ID (Azure CLI、Microsoft Office、またはその他の公式公開クライアントなど。これらの ID は公開されており、簡単に列挙でき、Microsoft がそれらに依存する正規のツールを壊さずに取り消すことは不可能です) を使用して、認証なしの POST リクエストを 1 回送信するだけで、有効なデバイス コードを即座に取得できます。これらの公式クライアント ID は、デフォルトで信頼され、広範囲のスコープに事前同意されており、永続的に利用可能なため、攻撃者にとって非常に有利です。攻撃者は、標的となる被害者ドメインを特定すれば、テナント ID を容易に取得できます。 

curl -X POST https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/devicecode \ 
  -d "client_id=04b07795-8ddb-461a-bbee-02f9e1bf7b46&scope=https://management.azure.com/.default" 

攻撃者は、検証用URLとユーザーコードを、Teams会議の招待、ドキュメント共有通知、ITセキュリティ警告など、巧妙な偽装メールに仕立て上げ、メール、Teams、WhatsApp、Signalなどの手段で送信します。STORM-2372では、特にTeams会議の通知やWhatsAppグループの招待メールを偽装する事例が確認されています。被害者がメールを読んでいる間に、攻撃者のスクリプトは既にポーリングを開始しています。被害者が認証を完了した瞬間に、ポーリングループはトークンペア全体を受信します。 

既存のセキュリティ対策が失敗する理由

デバイスコードフィッシングが特に危険なのは、それが同時に無効化する従来の防御策の数が多い点にある。 

マイクロソフトのIDプラットフォームの観点から言えば、これは完全に正当なサインインだった。 

• MFAは回避されるのではなく、不正に利用されます。被害者は通常どおりMFAを完了します。結果として生成されるトークンにはmfaAuthenticated=trueが含まれます。
• 攻撃者のインフラストラクチャは検出されません。攻撃チェーンに含まれる唯一のURLはmicrosoft.comであり、あらゆる脅威インテリジェンスフィードで完璧な評価を得ており、有効なEV証明書も取得しています。メールゲートウェイ、CASB、URLサンドボックス、プロキシセーフリンク書き換え機能はすべてこのURLを検査し、安全であると返します。
• リフレッシュトークンはパスワードリセット後も有効です。セッションクッキー（AiTM攻撃で盗まれる）とは異なり、OAuthリフレッシュトークンは長期的なデバイス間アクセスを目的として設計されています。ユーザーの操作や多要素認証の再要求なしに、新しいアクセストークンと自動的に交換できます。被害者のパスワードをリセットしてもトークンは失効しないため、攻撃者はトークンを明示的に失効させない限りアクセスを維持できます。
• フォレンジック調査の痕跡は最小限です。サインインログには、リスクレベル＝なし、MFA＝成功というログイン成功の記録があります。複数回のログイン失敗、認証情報の変更、不審なオブジェクトの作成はありません。唯一考えられる兆候は、予期しないIPアドレスからの非対話型トークン更新ですが、これも特に監視している場合に限ります。 

重要：これは中間者攻撃（AiTM）ではありません。EvilProxyなどのAiTMツールは、リバースプロキシを介してセッションを傍受し、多要素認証（MFA）後にCookieをキャプチャします。これには、攻撃者が制御するインフラストラクチャ（ドメイン、証明書、アクティブなサーバーなど）が必要であり、それらはすべてフォレンジックの痕跡を残します。デバイスコードフィッシングは、単一のHTTP POSTと説得力のあるメールだけで済みます。生成されるトークンはセッションCookieよりも有効期間が長く、適用範囲も広く、調査や停止の対象となる攻撃者のインフラストラクチャは存在しません。

攻撃者の視点：段階的な流れ

攻撃チェーン全体を実証するために、専用の研究テナント (glich.net) を使用して、制御されたラボ環境でそれを再現しました。シミュレーションでは、helpdesk@glich.net として動作する攻撃者が、デバイスコードフィッシングの誘いを偽装してユーザー roni@glich.net を標的にする様子をモデル化しています。 認証情報確認リクエスト. 

フェーズ1：デバイスコードの生成

攻撃者はPOSTを送信します Entra IDAzure CLI のパブリック クライアント ID を使用してデバイス認証エンドポイントにアクセスし、デバイス コードとユーザー コードを受け取り、トークン エンドポイントへのポーリングを直ちに開始します。 

フェーズ2：フィッシング詐欺の誘い文句の作成と配信

攻撃者は、デバイスコードとlogin.microsoft.com/deviceloginのURLを、Teams会議の招待状、認証情報の確認要求、またはITセキュリティ警告を装った緊急性を装ったメールに紛れ込ませます。 

フェーズ3：ユーザー承認

ユーザーはメールを受信し、攻撃者にアクセス権を付与する。 

被害者がブラウザでコードと認証情報を入力すると、ポーリングループがトークンを取得します。 

フェーズ4：搾取後

有効なアクセストークンと有効期限の長いリフレッシュトークンを入手した攻撃者は、被害者の Microsoft 365 環境への認証アクセスに成功し、時間は刻々と過ぎていきます。 2026月XNUMX日の分析 AIを活用したデバイスコードフィッシングキャンペーン（2025年2月に初めて報告されたSTORM-2372活動の直接的な進化形）に関する調査では、脅威アクターが実際に実行している侵害後のプレイブックが文書化されている。その進行は一貫したパターンに従っている。 

永続性のためのデバイス登録 

場合によっては、最初の侵害から10分以内に、攻撃者は侵害されたアカウントで新しいデバイスを登録し、プライマリリフレッシュトークン（PRT）を生成しました。PRTは、個々のトークンが失効しても有効な、長期的なシングルサインオン（SSO）対応のアクセスを提供します。これにより、攻撃者は、盗まれたリフレッシュトークン単独の場合よりもはるかに検出や対策が困難な、永続的な足がかりを得ることができます。 

マイクロソフトグラフ偵察 

盗まれたトークンを使用して、攻撃者はMicrosoft Graph APIにクエリを実行し、内部組織構造、ユーザーロール、および権限割り当てをプログラムでマッピングしました。この自動化された偵察により、侵害されたアカウントが機密リソースにアクセスでき、その場所がどこであるかを迅速に特定することができました。 特権昇格 可能でした。 

高価値ターゲットのフィルタリング 

攻撃者は、侵害したアカウントを無差別に悪用するのではなく、被害者の中から価​​値の高い人物、具体的には金融、経営、管理職などの立場にある人物を選別した。この選択的なアプローチにより、侵害後の最も攻撃的な活動は、最も大きな利益が見込めるアカウントに集中した。 

悪意のある受信トレイルールによる永続化 

攻撃者は、特定の標的に対して、Microsoft Officeアプリケーションを使用して受信メールの転送、非表示、または削除を行う受信メールルールを作成しました。これらのルールは、繰り返しログインすることなくメール通信への永続的なアクセスを維持することと、被害者から侵害の証拠を隠蔽すること（例えば、セキュリティ警告やパスワードリセット通知の自動削除）という2つの目的を果たしていました。 

標的型メール流出 

最も悪質な攻撃は、財務権限を持つユーザーに対して行われた。攻撃者は電子メールの通信内容を徹底的に調査し、特に送金明細、未払い請求書、役員間のやり取りなどを標的とした。これらは、ビジネスメール詐欺（BEC）や金融詐欺の格好の材料となる。 

検出を回避するための実行遅延 

すべての攻撃者が即座に行動を起こしたわけではありません。いくつかの事例では、攻撃者は最初の侵害から数時間後に事後的な対策を講じるまで待機していました。これは、疑わしい認証イベントとログ内の悪意のあるアクティビティを分離し、防御側が時間的な相関関係を特定することを困難にするための意図的な回避手法です。悪意のあるアクティビティが開始される頃には、それを可能にした認証イベントは、短期的なトリアージキューやリアルタイムのアラートウィンドウから既に外れています。防御側は、T+0 で疑わしいサインインをレビューしても、後続のアクティビティが見つからず、無害なものとして処理を終了する可能性があります。しかし、攻撃者は数時間後にデータ流出を開始し、その時点では元のアラートは誰の画面にも表示されなくなります。アクセスとアクションの間に意図的に時間差を設けることで、デバイスコードフィッシングは時間ベースの検出に対して特に耐性を持つようになります。防御側が長期間にわたって明示的に相関関係を特定しない限り、侵害と影響が同じ調査ウィンドウに表示されることはありません。 

ディフェンダーの視点：ログで注目すべき点

脅威ハンターやSOCアナリストにとって、 Entra ID ログキャプチャには、探すべき内容が正確に示されています。 

我々は捕らえた Entra ID このフローによって生成されるサインインログエントリ。攻撃者のポーリング要求（繰り返される authorization_pending 応答）は一切ログに記録されません。トークンの発行が成功した場合のみエントリが生成され、2 つのタブに分かれて記録されます。 

エントリー1：インタラクティブ（ブラウザ／被害者側）

被害者はmicrosoft.com/deviceloginにアクセスし、コードを承認した。MFAは以前のセッションの認証情報によって満たされたため、被害者は「承認」をクリックする以外に何の手間も感じなかった。 

エントリー2：非対話型（ポーリングクライアント／攻撃者側）

並べて比較

検出の基本要素は明確です。両方のエントリは相関IDを共有していますが、ユーザーエージェントと場合によってはIPアドレスが異なります。ブラウザ側のログはMac上のChromeを示し、ポーリング側のログはcurlを示しています。実際の攻撃では、このような違いを持つログのペア、特に地理的な差異は、あり得ない移動や疑わしい送信元を示唆しており、アラートシステムを構築する上で重要なシグナルとなります。 

ポーリング側のIPアドレスを脅威インテリジェンスフィード、IPレピュテーションリスト、疑わしいユーザーエージェント値（ログ内の「curl」の例など）、およびASNメタデータと照合することで、検出精度がさらに向上します。攻撃者のインフラストラクチャは、ホスティングプロバイダー、商用VPN、またはユーザー集団に正当な存在が見られないASNから発生することが多いためです。既知の悪質なASNに解決される、またはブラックリストに掲載されているポーリングIPは、レッグ間でIPアドレスの不一致がなくても、高い信頼性を示す指標となります。

環境内でのデバイスコードフィッシングの検出

脅威ハンター向け：Azure Monitor、Microsoft Sentinel、またはKQL互換のSIEM用のKQLクエリをコピー＆ペーストしてください。 

以下の KQL クエリを使用して、デバイス コード フィッシング アクティビティを検索できます。 Entra ID サインインログ。これらは、Azure Monitor、Microsoft Sentinel、またはKQL互換のSIEMにコピー＆ペーストできるように設計されています。 

目標は、デバイスコードの不正使用をT+0のできるだけ早い段階で検出することです。以下の各クエリは、それぞれ異なるシグナルを対象としています。異常なデバイスコードの使用パターン、インタラクティブレッグとポーリングレッグ間のIPアドレスまたはユーザーエージェントの不一致、およびアクティブなキャンペーンを示唆する可能性のある大量のコード生成などです。 

1. 相関分析のために、すべてのデバイスコードフローイベントを明らかにする

このクエリは、すべてのデバイスコードフローの双方向（対話型と非対話型）を取得します。CorrelationIdでソートまたは結合して、それらを並べて比較し、IPアドレスまたはユーザーエージェントの不一致（コアとなる検出シグナル）を探します。 

SigninLogs 
| where AuthenticationProtocol == "deviceCode" 
    or OriginalTransferMethod == "deviceCodeFlow" 
| project CorrelationId, UserPrincipalName, IPAddress, UserAgent, 
          IsInteractive, TimeGenerated, AppDisplayName, 
          AuthenticationProtocol 
| order by CorrelationId, TimeGenerated asc

2. レッグ間でIPアドレスの不一致があるデバイスコードフローを検出する

このクエリは、各デバイスコードフローの対話型エントリと非対話型エントリをCorrelationIdで結合し、IPアドレスが異なるフローにフラグを立てます。これは、ポーリングクライアントが認証ブラウザと同じデバイスまたは場所ではないことを示す強力な指標です。より精度の高いアラートを実現するには、ポーリングIPにASNルックアップと脅威インテリジェンスフィードを追加して、ポーリングIPがホスティングプロバイダ、商用VPN、またはブラックリストに登録された範囲に属している場合、IPアドレスが同じ国にある場合でも、フローにフラグを立てます。 

let interactive = SigninLogs 
| where AuthenticationProtocol == "deviceCode" 
    and IsInteractive == true 
| project CorrelationId, UserPrincipalName, BrowserIP = IPAddress, 
          BrowserUA = UserAgent, TimeGenerated; 
let polling = AADNonInteractiveUserSignInLogs 
| join kind=inner interactive on CorrelationId 
| project CorrelationId, PollingIP = IPAddress, PollingUA = UserAgent; 
interactive 
| join kind=inner polling on CorrelationId 
//| where BrowserIP != PollingIP 
| project TimeGenerated, UserPrincipalName, BrowserIP, BrowserUA, 
          PollingIP, PollingUA, CorrelationId 

3. 単一のアプリケーションからの大量のデバイスコード生成を監視する

デバイスコードフィッシングキャンペーンを実行する攻撃者は、短時間のうちに多数のコードを生成します。このクエリは、過去24時間以内に異なるユーザー間で異常に多くのデバイスコードがやり取りされたアプリケーションを表示します。 

SigninLogs 
| where TimeGenerated > ago(24h) 
| where AuthenticationProtocol == "deviceCode" 
    or OriginalTransferMethod == "deviceCodeFlow" 
| summarize DistinctUsers = dcount(UserPrincipalName), 
            FlowCount = count() 
    by AppDisplayName, AppId 
| where DistinctUsers > 3  // adjust threshold to your environment 
| order by DistinctUsers desc

しきい値と時間枠を、ご使用の環境のベースラインに合わせて調整してください。デバイスコードフローを正当に使用している組織（Azure CLIやIoTデバイスのオンボーディングなど）は、既知の有効なクライアントIDのリストを作成し、それらを除外する必要があります。 

不審なログペアが発見された――さて、どうしたらいいだろうか？

ユーザーエージェントの不一致を伴うデバイスコードフローが成功した場合でも、必ずしも悪意のあるものではありません。正当なシナリオも存在します（例：開発者がリモートサーバーでaz loginを実行し、ラップトップから認証する場合）。エスカレーションする前に調査してください。ただし、ログペアに不正利用の兆候（見慣れないポーリングIP、ホスティングプロバイダーのASN、デバイスコードフローを開始していないユーザーなど）が見られる場合は、トークンの盗難が確認されたとみなし、直ちに以下の手順を実行してください。 

1. すべてのリフレッシュトークンを直ちに失効させる 

ユーザーのアクセス権を直ちに取り消します（参照： マイクロソフトのドキュメント侵害されたユーザーを無効化し、そのユーザーの役割割り当てを削除します。これにより、すべての有効なリフレッシュトークンが無効になり、攻撃者が新しいアクセストークンを密かに取得する能力が遮断されます。パスワードをリセットする前にこれを実行してください。パスワードのリセットだけでは、OAuth リフレッシュトークンは失効しません。 

2. アクティブなセッションを終了する 

リフレッシュトークンを取り消しても、既に発行されたアクセストークンは無効になりません。それらは有効期限が切れるまで有効です。テナントで継続的アクセス評価 (CAE) を使用している場合は、キャッシュされたトークンをフラッシュするために、ユーザーのすべてのアクティブなセッションの再評価を強制します。CAE 以外のワークロードの場合は、ユーザーのセッションを取り消します。 Entra ID （ユーザー → セッションの取り消し）を選択すると、Microsoft 365 サービス全体でキャッシュされたトークンが無効になります。 

3. 永続化メカニズムを確認する 

新規登録されたデバイス、受信トレイのルール、OAuthアプリの同意、および同じセッションで実行されたその他の操作をすべて確認してください。特に、デバイス登録（プライマリリフレッシュトークンが生成されます）、メールの転送、リダイレクト、または削除を行う受信トレイのルール、および認証方法の変更（MFAに追加された新しい電話番号など）に注意してください。トークンの失効だけでは不十分です。攻撃者は既に永続的なアクセスを確立している可能性があります。ユーザーが認識できないものはすべて削除してください。 

4. 含む 横移動 

侵害されたユーザーが特権ロール（グローバル管理者、Exchange管理者など）を保持している場合、または機密性の高いリソースへのアクセス権を持っている場合は、調査が進む間、条件付きアクセスを使用してアカウントを制限してください。攻撃者が盗んだトークンを使用してSharePoint、Teams、またはAzureリソースにアクセスしたかどうかを確認してください。統合監査ログとMicrosoft Graphアクティビティログには、アクセス範囲が表示されます。 

5. 証拠を保全し、SOCに連絡してください。 

関連するサインインログエントリ（インタラクティブな操作と非インタラクティブな操作の両方、相関IDでリンク）、ユーザーの最近の監査ログアクティビティ、および削除した受信トレイルールやデバイス登録をエクスポートしてください。これらのデータは、影響範囲の特定や、後続のインシデント報告要件を満たすために不可欠です。

推奨事項とベストプラクティス

戦略的推奨事項

経営幹部やセキュリティ責任者にとって、最も重要な政策決定事項。 

• デバイスコード認証を明示的に必要としないすべてのユーザーに対して、認証フローをブロックします。これは条件付きアクセスポリシーの変更であり、ほとんどの従業員に対する攻撃対象領域を完全に排除します。
• インシデント対応手順書を更新し、パスワードリセットに加えてOAuthトークンの失効を必須手順として追加してください。パスワードリセットだけではリフレッシュトークンは失効しません。トークンが明示的に失効されない限り、攻撃者は無期限にアクセス権限を保持します。
• 役員、財務担当者、管理者など、重要度の高いアカウントには、トークンバインディング（トークン保護）を優先的に適用してください。この機能はWindowsで一般提供されており（iOS/macOSではプレビュー版）、盗まれたデバイスコードフローによるトークンリプレイ攻撃に対する最も強力な多層防御策となります。
• テナント内のどのアプリケーションでデバイスコードフローが有効になっているかを監査してください。多くの組織では、意図的に設定した覚えのないデバイスコード権限を持つOAuthアプリが存在します。対象範囲を縮小することで、すぐに効果が得られます。
• セキュリティ運用チームが、対話型サインインログだけでなく、非対話型サインインログも監視していることを確認してください。攻撃者によるトークン更新アクティビティは非対話型ログにのみ記録されますが、多くのSOC（セキュリティオペレーションセンター）はこれらのログを日常的に確認していません。

戦術的な推奨事項

セキュリティエンジニアおよび管理者向け - 実装レベルのガイダンス： 

条件付きアクセスにより、デバイスコードの流れを制限またはブロックする

組織が正当な使用事例（CLIツール、IoTデバイス、会議室ハードウェアなど）でデバイスコード認証に依存していない場合は、条件付きアクセス ポリシーを使用してフローを完全にブロックします。 Entra IDすべてのユーザー → ターゲット リソース → すべてのリソース (旧クラウド アプリ) → 条件 → 認証フロー → デバイス コード フロー = ブロック を対象とするポリシーを作成します。一部のチームが必要とする場合は、許可ポリシーを特定のユーザーまたはグループと既知のデバイス プラットフォームのみにスコープし、 最小特権の原則. 

トークン盗難を軽減するための適切な手順を指示する

パスワードのリセットだけでは、OAuth リフレッシュトークンは失効しません。アカウントが侵害された場合の対応手順には、(1) ユーザーのアクセス権を取り消し、アカウントを無効にする、(2) すべてのアクティブな継続的アクセス評価 (CAE) セッションを再評価する、(3) ユーザーの OAuth アプリの同意を確認し、見慣れないサービスプリンシパルを削除する、といった手順を含める必要があります。これらの手順を実行しないと、攻撃者はリフレッシュトークンの有効期限が切れるまで (デフォルトでは最大 90 日) アクセスを維持します。 Entra ID 構成。 

非対話型サインインログを監視し、地理的な異常を検出する。

非対話型サインインタブ Entra ID トークン更新イベントが発生するのは、この場所です。盗まれた更新トークンを使用する攻撃者は、ユーザーのベースラインとは異なる可能性が高いIPアドレスとユーザーエージェントから、非対話型サインインを生成します。ソースIPがユーザーの最後の対話型ログインとは異なる国またはASNにある非対話型サインインに対してアラートを設定します。さらに、ソースIPを脅威インテリジェンスフィードやIPレピュテーションデータベースと相互参照します。ブラックリストに登録されたIP、既知の堅牢なホスティングプロバイダー、または住宅用プロキシネットワークからのポーリングまたは更新アクティビティは、地理的な場所に関係なく、高い信頼性の指標となります。この地理的な組み合わせ 異常検出 また、評判に基づくフィルタリングは、デバイスコードトークンの盗難を検知する最も早期かつ最も信頼性の高い指標となる。 

デバイスコードフィッシングから身を守る方法

デバイスコードフィッシングは、ID脅威の状況に根本的な変化をもたらしました。攻撃者はインフラストラクチャを必要とせず、多要素認証（MFA）は回避されるのではなく悪用され、パスワードのリセット後もアクセスが維持されます。この攻撃が成功するのは、まさに正当性があるからです。本物のMicrosoftログインページ、本物のMFAプロンプト、本物の成功画面が表示されます。トークンはただ、間違ったマシンに送られるだけなのです。 

戦略的な対応策はシンプルです。不要なデバイスコードの流れを遮断し、インシデント対応（IR）プレイブックにトークン失効処理を組み込み、多くの組織が見落としがちな非対話型サインインログを監視します。本記事では、プロトコル分析からログキャプチャ、KQLクエリに至るまで、技術的な詳細を解説し、セキュリティチームがこのアクティビティを迅速に検出するために必要な情報を提供します。 

OAuthベースのID攻撃が進化し続けるにつれて、従来の境界防御ツールで確認できる範囲とIDレイヤーで実際に起こっていることとの間のギャップはますます広がるでしょう。プロトコルレベルのセキュリティ対策に投資する組織は、 検出と応答エンドポイントやネットワークの監視だけでなく、こうした監視こそが、この技術が悪用後の段階に達する前に、その次の進化を捉えることができるだろう。 

Silverfortの研究チームは、OAuthベースの攻撃手法の進化を引き続き追跡している。