多くの人が「フィッシング」と聞いて思い浮かべるのは、ユーザーを騙して資格情報を開示させたり、マルウェアをダウンロードさせたりする手口でしょう。
しかし、現在最も急速に拡大している攻撃手法の1つは、そのどちらでもありません。この手法では、標的となったユーザーが騙されて「攻撃者が制御するクライアント」を認可させられてしまいます。このような攻撃は、あるアプリから別のアプリのデータへのアクセス権を付与する際に使用される、「OAuthベースの認可フロー」に対するユーザーの信頼を悪用したものです。
2026年初頭、「デバイスコードフィッシング」が急増しています。この攻撃は、ユーザーがあるデバイス上のクライアントを、別のデバイスからサインインして認可する手法である「デバイスコード認証グラント」の既知の弱点を突いたものです。本来、このグラント（認可方式）は、パスワードの入力が困難な「入力制限のある」デバイスへのサインインを容易にするために設計されました。しかし現在では、従業員向けの業務用途など、他の多くのユースケースでも使用されています。攻撃者たちは今やこのフローを巧みに悪用し、ユーザーを騙して悪意のあるアプリケーションを認可させる手口で大きな成功を収めています。
Push Securityの脅威リサーチャーは、今年に入ってからMicrosoft 365ユーザーを標的としたデバイスコードフィッシング攻撃が15倍に増加していることを観測しました。さらに、Okta Threat IntelligenceおよびProofpointのリサーチャーたちは現在、一部の脅威アクターがAitM（Adversary-in-the-Middle：中間者）フィッシング攻撃から、デバイスコードフィッシング攻撃へと手法をシフトさせている兆候を確認しています。
デバイスコードフィッシングがこれほど中心的な脅威となっている背景には、「EvilTokens」のような「Phishing-as-a-Service（サービスとしてのフィッシング）」事業を通じて、攻撃が産業化されていることが挙げられます。
EvilTokensは、スキルの低いサイバー犯罪者に対して、Microsoftの顧客へ大規模なデバイスコードフィッシング攻撃を仕掛けるために必要なインフラ、ルアー（おとりとなるコンテンツ）、防御回避ツール、アラート・メッセージング機能を提供しており、サービスを利用する攻撃者は最小限の労力で攻撃を実行できるようになっています。
本記事では、デバイスコードフローの本来の用途や、それが悪用される仕組み、そしてこの攻撃形態を「phishing with dynamite（ダイナマイト漁のようにターゲットを一網打尽にするフィッシング）」たらしめている要因について解説します。
デバイスコード認可グラント
デバイスコードフィッシングは、入力制限のあるデバイス向けに設計された特定のOAuth 2.0認可フローである「OAuth 2.0 デバイスコード認可グラント（RFC 8628）」を悪用します。
入力制限のあるデバイスの例としては、テレビ上のストリーミングアプリ、家電製品を操作するアプリ、自動車のエンターテインメントシステムなどが挙げられます。長く複雑なパスワードの入力が面倒なシステムでは、デバイスコードフローを使用することで、ユーザーはスマートフォンやノートPCなどの別デバイス（帯域外）でサインインを行い、クライアントによる自身のアカウントデータへのアクセスを認可（同意）できるようになります。
動画ストリーミングアプリを例に図式化すると、以下のようになります。
ユーザー：テレビ上のストリーミングアプリにサインインしようとしている。
ユーザーのスマートフォンのブラウザ：帯域外認証を行うデバイスとして機能する。
認証サーバーは、ストリーミングサービスのバックエンドサーバーへのアクセスを仲介します。
正当なデバイスコード認可フローでは、以下のような手順で処理が進みます。
- ユーザーがテレビからストリーミングサービスのアカウントにサインインしようとします。
- テレビ上のアプリが、指定されたエンドポイントへのリクエストにクライアントIDを含めて送信し、認可サーバーにアクセスを要求します。認可サーバーは、デバイスコード、ユーザーコード、検証URIを返します。
- アプリはユーザーに対し、検証URI（テレビ画面上にウェブアドレスまたはQRコードとして表示）へアクセスするよう促し、同時にアプリを認可するためにスマートフォン側で入力する8文字のユーザーコードを提示します。
- 提示されたWebアドレスにアクセスすると、ユーザーはユーザーコードの入力を求められ、本人確認（アイデンティティの検証）が行われます。また、必要に応じて、サーバー上にホストされているリソース（ストリーミングサービス内のアカウントデータ）へのアクセス権をアプリに付与することへの同意を求められます。
- バックグラウンドで、アプリはクライアントIDとデバイスコードを含むリクエストを認可サーバーに継続的にポーリングします。クライアントアプリは、ユーザーがそのアプリを認可したかどうかを、事実上、認可サーバーに問い合わせています。ユーザーが同意すると、認可サーバーはポーリングリクエストに応答してアクセストークンを返します。そのアクセストークンを使用して、ストリーミングサービスへのAPIコールを実行できます。
こうしたやり取りはすべて、わずか数秒で完了します。このフローは利便性が高いだけでなく、より強力な認証方法の利用を促進します（特に、短いパスワードやOTPを入力制約付きデバイスに入力する場合と比較して）。
残念ながら、デバイスコードフローはソーシャルエンジニアリング攻撃で悪用されやすいという側面もあります。
デバイスコードフィッシング
これに対し、デバイスコードフィッシング攻撃では、攻撃者がクライアントアプリを制御します。
- 攻撃者は、自らが制御するテナント内に新しいアプリを登録するか、標的ユーザーの認可サーバーから信頼されている既知のクライアントIDを使用します。デバイスコード認可フローでは、クライアントアプリが認証されていることや、認可サーバーに事前登録されていることすら求められないため、認可サーバーへのリクエストは有効なものとして処理されてしまいます。攻撃者が既知のクライアントIDを悪用することを防ぐ手立てはなく、クライアントID自体も通常はシークレットとして保護されていません。
- 攻撃者は、フィッシングサイトやソーシャルエンジニアリングによる電話を介して、標的ユーザーにユーザーコードと検証URIを提供します。認証済みのユーザーがこのWebアドレスにアクセスしてユーザーコードを入力すると、事実上、攻撃者のアプリに自分のリソースへのアクセス権を付与したことになります。あとは攻撃者が認可サーバーを定期的にポーリングするだけで、レスポンスとしてアクセストークンを受け取ることができます。
ダイナマイト漁のようなフィッシング
これまでに観測された攻撃において、攻撃者は以下のような条件を満たすクライアントになりすますことに強い関心を示しています。
単一の共通認可サーバーによって認可されている
新規テナント（無料・トライアルテナントを含む）の全ユーザーにデフォルトで割り当てられている
すべてのテナントで共通かつ既知のクライアントIDを持っている
残念ながら、Microsoftのアプリは複数の面でこれらの条件に該当しています。
EvilTokensの利用者は、すべてのMicrosoft顧客に適用される単一の共通エンドポイント（/common/oauth2/devicecode）にPOSTリクエストを送信することで、デバイスコードフローを開始できます。
このPOSTリクエストには、正当なクライアントIDを含める必要があります。Microsoftテナントでデフォルトで利用可能なファーストパーティアプリのクライアントIDは、定期的に一覧や表として公開されており、それらの間の複雑な関係についても公然と議論されています。脅威リサーチャーの指摘によると、EvilTokensはデフォルトでMicrosoft Officeの既知のクライアントIDを悪用しますが、他のリサーチャーはその他のMicrosoftアプリの悪用も観測しています。
これはつまり、地球上のほぼすべてのMicrosoft顧客を攻撃するのに単一のツールが通用することを意味します。Xboxでアプリを認可しようとしている中学生であろうと、Fortune 500企業のアプリを認可しようとしているIT管理者であろうと関係ありません。
すべてのユーザーが単一のドメイン（login.microsoft.com）を介して認証を行うことは、攻撃者にとって大規模な攻撃を非常に容易にするという利点があります。Microsoft顧客を標的としたデバイスコードフィッシング攻撃では、攻撃者は標的となるユーザーを共通のエンドポイント（login.microsoft.com/common/oauth2/v2.0/devicecode）に誘導します。そのエンドポイントでは、特に多くのユーザーまたは全ユーザーに割り当てられている可能性が高いクライアントIDを使用する場合、Microsoftサービスのあらゆるユーザーが有効なユーザーとして扱われます。
これに対し、Okta Platformは、各組織が独自の独立した分散型認可サーバーを持つという原則に基づいて設計されています。異なる組織のユーザーが1つの場所でアイデンティティを検証するような「共通」エンドポイントという概念は存在しません。
これは、Okta上で作成されたクライアントにデバイスコードフィッシング攻撃が効かないというわけではないものの、Oktaのアーキテクチャでは、攻撃者は標的ごとに相当な事前調査を強いられることになります。
リソース
記事全文を読む
デバイスコードフローの悪用に対するOktaの防御アプローチについては、本記事の完全版にて詳しく解説しています。Oktaをご利用のお客様のセキュリティ担当者様は、security.okta.comにサインインすることでアクセスいただけます。
推奨事項
- デバイスコードフローの使用は例外的にのみ許可するようにしてください。Microsoftをご利用のお客様は、デバイスコードフローを使用するすべてのアクセスをブロックする条件付きアクセスポリシーを導入することを強く推奨します。
Oktaで作成されたクライアントアプリケーションにデバイスコードフローが最も適していると見なされる場合：
トークン発行を許可するIP範囲を許可リストに登録する：対象のクライアントごとに、［Applications（アプリケーション）］ > ［General（一般）］ > ［Network IP（ネットワークIP）］で設定できます。これを設定することにより、許可リストで指定されたIP範囲外に存在する攻撃者が制御するクライアントからのアクセストークン要求はすべて拒否されます。
異常なトークンリクエストやユーザー権限付与を監視します。
