フィッシング
デバイスコードフィッシング：便利な認証機能を悪用した多要素認証（MFA）回避の手口
デバイスコードフィッシングとは、入力操作などに制約のあるデバイス向けに設計された正規の認証機能を悪用する攻撃手法のことです。本記事では、この攻撃手法の仕組みを解説するとともに、最近確認された事例の分析結果を基に、企業組織が実施すべき多層的な防御策についてお伝えします。
- デバイスコードフィッシングとは、通常のサインイン画面を表示できないデバイス向けに設計されたOAuth 2.0の認可フロー「デバイス認可グラント」を悪用する攻撃手法のことです。
- 被害者となったユーザは、Microsoftの正規サインインページで認証を行い、アクセス要求を承認していたため、パスワードなどの入力情報が窃取されることはなく、多要素認証も正常に完了していました。しかし、認証によって発行されたアクセストークンは、ユーザではなく攻撃者のセッションに紐付けられていたため、攻撃者はそのトークンを悪用してユーザになりすまし、不正アクセスを行うことが可能となっていました。
- 攻撃者がMicrosoft Authentication Brokerを標的とした場合、一度の承認をきっかけに攻撃者のデバイスが不正に登録されたり、有効期限の長いリフレッシュトークンが取得されたりすることで、単発の不正アクセスにとどまらず、長期間にわたってアカウントへのアクセス権を維持できる可能性があります。
- 有効な対策としては、デバイスコードフィッシングの手口についてユーザや従業員の認識を高めることに加え、不要なデバイスコード認可フローを無効化・制限することが重要です。また、この攻撃特有の挙動や関連イベントを継続的に検知・監視できる仕組みを導入することが推奨されます。
はじめに
長きにわたり、ユーザに対するセキュリティ対策の基本的なアドバイスは、「多要素認証を有効化すれば、アカウント乗っ取りの多くを防ぐことができる」というものでした。この考え方は現在も有効であり、多要素認証はパスワードを悪用する攻撃の多くを防いでいます。しかし、攻撃者は防御策の変化に適応します。企業組織が単一の防御策に過度に依存するほど、その防御策は攻撃者にとって格好の標的となります。
最初の大きな変化は、中間者攻撃（AiTM：Adversary-in-the-Middle）型フィッシングの登場でした。攻撃者は、自身の用意したリバースプロキシサイトをユーザとMicrosoftなどの正規認証サービスとの間に介在させ、サインイン処理をリアルタイムで中継させることで、認証済みのセッションクッキーを窃取します。デバイスコードフィッシングは、その次の段階に位置付けられる攻撃手法であり、攻撃者にとってはより効率的な攻撃手法と言えます。中間者攻撃のように偽のサインインページやリバースプロキシを用意する必要がないため、フィッシング基盤が検知・遮断されるリスクを低減できるためです。また、ユーザがパスワードを入力する画面は、Microsoftが提供する正規のサインインページであるため、URLや画面デザインに不自然な点はほとんどありません。唯一の違いは、攻撃者から提示された短いデバイスコードを入力し、その操作が正当な認証手続きであると信じて承認する点にあります。
デバイスコード認証の仕組み
デバイス認可グラントは、明確な目的を持って設計された認可フローです。スマートテレビや会議室のシステムなど、一部のデバイスでは通常のサインイン画面を表示できなかったり、キーボードを備えていなかったりします。そのようなデバイスでは、パスワードを直接入力する代わりに短いデバイスコードを表示させ、スマートフォンやパソコンなど別のデバイスを用いてサインインを完了させる仕組みが採用されています。
通常の認可フローでは、ユーザが対象デバイスを介してMicrosoft Entra IDにデバイスコードを要求すると、それに紐づくコードがデバイス上に表示されます（図1）。次にユーザはスマートフォンやノートパソコンなどからmicrosoft.comにアクセスし、表示されたデバイスコードを入力してアクセス要求を承認します。その後Microsoft Entra IDは、デバイスコードを要求したデバイスに対してアクセストークンを発行します。この認可フローでは、アクセスを要求したデバイスと、その要求を承認するユーザが同一人物であり、同じ場所で認証操作を行っていることが前提となっています。
- 攻撃者は、自身の制御するシステム（サーバなど）からMicrosoftに対してデバイスコード認証を要求し、有効期限の短い正規のデバイスコードを受信します。
- 攻撃者は、共有ドキュメントの閲覧やアカウント確認など、もっともらしい理由を添えてデバイスコードを標的ユーザに提示し、入力するよう誘導します。
- 標的ユーザは、Microsoftの正規認証ページにアクセスし、提示されたデバイスコードを入力してサインインおよび多要素認証を完了させます。
- 攻撃者側で保留状態となっている認証要求を標的ユーザが承認し、多要素認証の要件を満たした場合、Microsoftは、攻撃者の制御するシステムに対してアクセストークンを発行します。
- 攻撃者は、Microsoftから発行されたアクセストークンを悪用し、デバイスの不正登録、Microsoft 365 Outlookへのサインイン、メールボックスルールの作成などを実行します。これにより、不正アクセスを長期間維持し、発覚を遅らせることを可能にしています。
不正リンク自体も、セキュリティ機能による検知を回避するよう巧妙に設計されていました。画面上には見慣れた企業ドメインが表示されていましたが、実際の接続先はGoogle Sites上に構築された不正ページでした。Google Sitesは正規かつ広く利用されているサービスであり、攻撃者はそのドメインの信頼性を悪用することで、メールセキュリティ製品などによる検知やブロックを回避しようとしていました。標的となったユーザは、Google Sites上の不正ページに誘導された後、侵害された正規Webサイト上のオープンリダイレクトを経由して、最終的な不正ページに誘導されていました。表示上は安全なURLに見える一方で、実際の遷移先はURLパラメータ内に隠されていました。最終的な不正ページは、ボット対策用の確認画面を装った偽のポップアップを経由した先に配置されており、自動スキャナによる解析や検知を回避する仕組みが採用されていました。
最終的な不正ページは、ドキュメント共有サイトに偽装されていました。攻撃者は、このページ上にデバイスコードを表示し、標的ユーザに対して、対象コードをMicrosoftのサインイン画面に入力するよう誘導していました。
今回調査した事例の一つで攻撃者は、ユーザが認証要求を承認した数時間後に海外のIPアドレスからサインインを実行していました。その後、侵害したアカウントに複数のデバイスを登録し、返信メールやエラーメールを隠蔽するための非表示の受信トレイルールを作成していました。さらに、同メールボックスを悪用して数百人の外部宛先に対してフィッシングメールを送信し、攻撃範囲を拡大させていました。なお、被害者の端末（エンドポイント）自体へのアクセスは一切確認されませんでした。すべての操作は被害者の端末上ではなく、クラウド環境内で実行されていました。本事例は、エンドポイントのみを対象としたセキュリティ対策だけでは、クラウド環境内で完結する攻撃を検知することが困難であることを示しています。
デバイスコードフィッシングを検出する方法
この攻撃はアイデンティティ層で発生するため、関連する兆候も同じ層で検知できます。注視すべき点を以下に示します。
- デバイスコード認証を用いるサインイン方式：デバイスコード認証プロトコルを用いるサインインが発生しているか確認しましょう。この認証方式は、多くの環境で利用頻度が低いため、発生した場合には正当な利用であることを確認する必要があります。
- Microsoft Authentication Brokerにおけるアクティビティ：Microsoft Authentication Brokerを介したサインインについて、従業員が通常利用していない国や地域、ネットワーク、または管理対象外のデバイスから実行されていないか確認しましょう。
- 意図しないデバイス登録の増加：新規デバイスの登録、特に短時間のうちに多数のデバイスが追加されている場合や、見慣れないIPアドレスから登録が行われている場合は注意が必要です。
- 意図しないメールボックスルールの変更：受信トレイに新たなルールが追加され、メールが目立たないフォルダ内へ移動されている、未読メールが既読として処理されている、または削除されているなどの変更がないか確認しましょう。これらは、アカウント侵害後に攻撃者が活動の痕跡を隠蔽するために用いる典型的な手法です。
- 通常とは異なる場所からのアクセス：ユーザが通常利用している地域とは異なる場所からサインインが行われ、さらに上記のようなイベントと関連している場合、不正アクセスの兆候である可能性があります。
- ユーザや従業員のセキュリティ意識を高めましょう。 予期しない状況でデバイスコードの入力や読み上げを求められた場合、それは危険な兆候であることを周知させましょう。また、不審な認証要求をすぐに報告できる環境を整えることで、技術的な保護対策が機能する前に攻撃を阻止できる可能性が高まります。
- デバイスコード認可フローを無効化・制限しましょう。 デバイスコード認可フローを利用しない場合は、条件付きアクセスポリシーを用いてOAuth 2.0の認可フロー「デバイス認可グラント」を無効化しましょう。多くの企業組織では、原則としてこの認可フローを無効化し、必要な場合に限って例外的に有効化する運用が推奨されます。
- デバイス登録を制限・監視しましょう。 デバイス登録を許可する従業員を限定するとともに、メールやデータへのアクセスには、管理下にありコンプライアンスに準拠したデバイスのみを利用するよう制御しましょう。また、従業員（ユーザ）ごとのデバイス登録可能数の上限を引き下げることで、不正デバイスが大量に登録されるリスクを低減できます。
- アイデンティティ管理体制を強化しましょう。 条件付きアクセスポリシー（Named Locationsなど）を適用するとともに、継続的アクセス評価（CAE）やトークン保護を有効化しましょう。また、リスク上昇時にセッションを自動的に取り消す設定を有効化することで、不正アクセスの継続を防止できます。
まとめ
デバイスコードフィッシングの手口は、攻撃者が個々の機能そのものでなく、機能間の連携に存在するセキュリティ上の弱点を悪用していることを示しています。この攻撃で悪用されるのは、ソフトウェアの脆弱性ではありません。攻撃者は、正規の認可フロー、信頼性の高いドメイン上に構築された偽のサインイン画面、巧妙な誘導手口を組み合わせることで、多くの企業組織が導入している多要素認証による保護を回避し、不正アクセスを実現しています。幸いにも、この攻撃は適切な保護対策を講じることで十分にリスクを低減できます。不要な認可フローの無効化、フィッシング耐性の高い多要素認証の導入、そして予期しない状況でデバイスコードの入力や読み上げを求められた場合に応じないよう従業員やユーザに周知させることで、大部分のリスクを軽減できます。
TrendAI Vision One™による検出対応
ウェブ層では、この攻撃で用いられたフィッシングURLがTrendAI Vision One™のWebレピュテーションサービスによって危険なURLとして検出されます。さらに認証情報の窃取に用いられる不正ページは、検出名「HTML.Phish.Microsoft」として識別されます。これらの不正URLをブロックすることで、ユーザがデバイスコードの偽入力画面に誘導される前に攻撃を阻止できます。WebレピュテーションサービスやURLフィルタリング機能は、ユーザのセキュリティ意識向上と組み合わせることで、有効な防御策として機能します。
TrendAI Vision One™ スレットインテリジェンス
TrendAI Vision One™ Threat Intelligenceでは、新たな脅威や攻撃者集団に関する最新の知見、TrendAI™ Researchによる限定公開の戦略レポートをご確認いただけます。さらにTrendAI Vision One™プラットフォーム内では、TrendAI Vision One™ Threat Intelligence Feedをご活用いただけます。
新たな脅威: Device Code Phishing Bypasses MFA Protections
TrendAI Vision One™のアプリ「Intelligence Report」（IoC Sweeping）
Device Code Phishing Bypasses MFA Protections
TrendAI Vision One™のアプリ「XDR Data Explorer App」
TrendAI Vision One™をご利用中のお客様は、XDR Data Explorerアプリを用いることで、本ブログ記事で取り上げた悪意ある指標を自組織のIT環境内のデータと照合し、脅威ハンティングを実施いただけます。
Microsoft Entra IDをTrendAI Vision One™と連携させている場合、以下のXDR Data Explorerアプリのクエリを実行することで、この攻撃において特に重要となる2つのイベントを抽出いただけます。1つ目のクエリは、デバイスコードフローによる承認が完了したイベントを抽出します。この種のイベントは、多くの環境では発生頻度が低いため、検出された場合は正当な利用であるかを確認する必要があります。
pname: "Microsoft Entra ID" AND authenticationProtocol: deviceCode AND eventName: IDENTITY_IAM_SIGN_INS AND status: 0
2つ目のクエリは、新たに登録されたデバイスを抽出します。攻撃者が一度の承認を長期間維持可能なアクセス権へと変える際に利用される重要なイベントです。
pname: "Microsoft Entra ID" AND eventName: IDENTITY_AAD_DIR_AUDIT AND eventCategory: Device AND actionName: Add device AND initiatedByAppDisplayName: Device Registration Service AND result: success
なお、上記フィルタを用いた場合、デバイス登録イベントを検出できる一方で、正当な利用によるイベントも多数含まれることが想定されます。より精度の高い検出を行うには、Device Registration Serviceリソースに対する認証イベントを追跡し、元の認証転送がデバイスコードフローであるセッションを特定します。これにより、デバイスコードフローで取得されたアクセストークンがDevice Registration Serviceへのサインインに用いられた可能性を検知いただけます。検出ロジックを以下に示します。
pname: "Microsoft Entra ID" AND eventName: IDENTITY_IAM_SIGN_INS AND status: 0 AND rawDataStr: "\OriginalTransferMethod":"deviceCodeFlow"" AND targetResourceDisplayName: "Device Registration Service"
これらの挙動は、TrendAI Vision One™に標準搭載されている「Observed Attack Techniques」や「Workbenchの検出ルール」でも検出されます。
- Potential Device Code Token Generation（潜在的なデバイスコードトークンの生成）
- Device Registration Resource Access via Device Code Token（デバイスコードトークンによるデバイス登録リソースへのアクセス）
本ブログ記事の内容は、セキュリティ管理者が本攻撃手法を把握し、早期の検知・阻止につなげられるよう支援することを目的としています。対応を実施する前に、すべての指標について自組織の環境への影響をご確認ください。
参考記事
Device Code Phishing: Turning a Convenience Feature Into an MFA Bypass
By: Ahmed Elsayed, Ahmed Hussein, Ahmed Kamal, Mahmoud Soheem
翻訳：益見 和宏（Platform Marketing, TrendAI Research™）