2026年6月26日

今回のブログでは、Microsoft Entra ID/Microsoft 365を対象とした同意フィッシング(Consent Phishing)という攻撃手法について紹介します。同意フィッシングは、多要素認証をバイパスすることが可能な強力な攻撃です。デモを交えながら紹介します。

注意事項

本ブログは、攻撃に対する脅威を知ることでセキュリティ対策の強化に繋げていただくことが目的です。
本ブログで紹介する内容を悪用しないでください。

目次

同意とは

同意は、OAuthやOpenID Connectの認可コードフロー[1]を利用して、アプリケーションが保護されたリソースにアクセスすることをユーザや管理者が許可するためのプロセスです。[2]
同意が必要なアプリケーションにユーザがアクセスしたタイミングで図1のような同意画面が表示されます。ユーザが同意をすることでアプリケーションに対して記載されたアクセスが許可され、アプリケーションがユーザのデータにアクセスできるようになります。

簡略化しますが、同意を利用してアプリケーションがデータにアクセスするために必要なアクセストークン[3]を発行するまでの一連の流れを図2に示します。ユーザの同意を通してアプリケーションに対してアクセスを許可し、それをもとにアプリケーションがアクセストークン、場合によってはリフレッシュトークン[4]、IDトークン[5]を取得し、Entra ID、Exchange Online等の情報にアクセスします。[6]

例として、Graph Explorer[7]への同意と関連するアクセス許可を紹介します。

Graph ExplorerはGraph API[8]を探索するための開発者ツールです。

Graph Explorerを利用するアカウントを選択すると同意画面が表示されます。「Sign you in and read your profile」、「Maintain access to data you have given it access to」というGraph Explorerにユーザ情報を使用したサインイン、ユーザのプロファイル読み込み、およびリフレッシュトークンの発行を可能にするアクセス許可に同意します。

アクセス許可に同意しましたが現状では権限が足りないため、「組織内のすべてのユーザー」は取得できません。

「組織内のすべてのユーザー」を取得するため、「User.ReadBasic.All」[9]のアクセス許可に同意します。

同意画面には、新たに「User.ReadBasic.All」に対応した「Read all user’s basic profiles」が追加されています。アクセス許可に同意します。

Graph Explorerは同意したユーザの代理として、Graph APIを使用し、「組織内のすべてのユーザー」を取得できます。

ここで、Entra IDポータル上でGraph Explorerへ付与されたアクセス許可を確認します。エンタープライズアプリケーション内のGraph Explorerのアクセス許可画面に遷移します。Graph APIの複数のアクセス許可がGraph Explorerに付与されています。

アクセス許可には、「委任されたアクセス許可」と「アプリケーションのアクセス許可」の2種類があります。[10] 今回付与された「委任されたアクセス許可」の場合、アプリケーションが同意をしたユーザの代理として権限を使用することができます。一方、「アプリケーションのアクセス許可」はユーザの代理としてではなく、アプリケーション自身として権限を使用することができます。例えば、「Mail.Read」[11]のアクセス許可が付与された場合、「アプリケーションのアクセス許可」であれば全てのユーザのメールデータの読み込みが可能ですが、「委任されたアクセス許可」では同意したユーザのメールデータのみを読み込み可能です。「アプリケーションのアクセス許可」は影響が大きいためユーザでは同意できず、管理者が同意することが必要です。

同意フィッシングとは

前述の同意の仕組みを悪用した攻撃が同意フィッシングです。攻撃者が管理するEntra IDテナントでアプリケーションを登録し、そのアプリケーションに対して特定の権限を被害者に同意させることで、同意済み権限に基づいた情報に攻撃者がアクセスすることができます。
攻撃者が管理するアプリケーションへ被害者を同意させるためのURLに着目します。Microsoft社の正規ドメインであるlogin.microsoftonline.comが使用されるので、ドメインを確認しただけではフィッシングの判断が困難です。また、ログインした被害者自身が攻撃者管理のアプリケーションに権限を渡す仕組みとなるため、被害者がMFAを設定していても防ぐことができない攻撃となります。

同意フィッシングのデモ

Entra IDにおける同意フィッシングの手法について、一般ユーザへの同意フィッシングに加え、高権限のアカウントを狙ったケースをデモ仕立てで紹介します。

攻撃者視点1

細かな手順は割愛させていただきますが、同意フィッシングのための攻撃者の環境準備を含めて紹介します。

同意フィッシングのために攻撃者が管理可能なEntra IDの環境が必要です。
攻撃者は、Entra ID上で同意フィッシングに悪用するアプリケーションを登録します。リダイレクトURLには攻撃者が管理するWebサーバのURLを指定します。

次に作成したアプリケーションのアクセス許可を設定します。今回はEntra IDテナントのデフォルト設定である「Microsoftによる同意設定の管理を許可する」の場合に一般ユーザが同意可能な委任されたアクセス許可である「User.ReadBasic.All」を指定します。[12]

続いて、アプリケーションのパスワードであるクライアントシークレットを作成します。

同意フィッシングのツールとしてAltered Security社の365-Stealer[13]を使用します。

攻撃者が365-Stealer上で必要項目を設定完了後、365-StealerのCLIにフィッシング用URLが表示されます。フィッシング用URLには、client_idパラメータに「SecurityCheck」のアプリケーションID、redirect_uriパラメータにリダイレクト先URLが含まれます。

フィッシング用URLを含むメールをターゲットに対して送付します。

被害者視点1

攻撃者から被害者に同意フィッシングメールが届きます。

メール文面には正規のMicrosoft社のドメインであるlogin.microsoftonline.comが記載されているため、被害者が不審に思わずにアクセスします。攻撃者が作成したアプリケーションである「SecurityCheck」の同意画面が表示されます。被害者は不審に思わずに「承諾」を選択します。

「承諾」選択後、フィッシング用URLのパラメータに指定されたリダイレクト先に遷移します。リダイレクト時のURL中に認可コードが含まれることから、遷移時に攻撃者に認可コードが渡されます。その後、被害者の画面にはMicrosoft社を装った攻撃者が作成したWebサイトが表示されます。

攻撃者視点2

攻撃者の視点に移ります。

被害者がアプリケーションに同意した後の攻撃者の画面を表示します。
被害者による同意が成功し、被害者のリダイレクトにより、365-Stealerに認可コードの情報が渡されます。認可コードと攻撃者が入手済みの情報を用いてアクセストークンを入手することができます。[14]

365-StealerのGUIを更新すると新たなユーザが追加されています。

今回被害者は、「User.ReadBasic.All」のアクセス許可に同意しました。攻撃者は該当するアクセス許可に対応したアクセストークンを入手します。攻撃者は365-Stealer上でそのアクセストークンを利用し、被害者のテナントに含まれる全てのユーザのユーザプリンシパル名やメールアドレスを入手します。

次のステップとして攻撃者は、ユーザ名から管理者と推測するtestuser03_admに対して更に同意フィッシングを仕掛けます。

testuser03_admがグローバル管理者であれば高権限のアクセス許可に対して同意可能です。攻撃者は作成したアプリケーション「SecurityCheck」にメール関連の委任されたアクセス許可である「Mail.Read」[11]、「Mail.Send」[15]、「MailboxSettings.ReadWrite」[16]を付与します。「Mail.Read」は同意したユーザのメールの読み込み、「Mail.Send」は同意したユーザとしてメール送信、「MailboxSettings.ReadWrite」は同意したユーザのメールボックスの設定の読み書きを可能にするアクセス許可です。

フィッシング用URLを含むメールをターゲットに対して送付します。

被害者視点2

攻撃者から被害者に同意フィッシングメールが届きます。

被害者が不審に思わずにURLにアクセスし、同意画面で「承諾」を選択します。

攻撃者視点3

攻撃者の視点に移ります。

被害者による同意が成功し、被害者のリダイレクトにより、365-Stealerに認可コードの情報が渡されます。365-StealerのGUIを更新すると新たな被害者であるtestuser03_admが追加されています。

「Mail.Read」の委任されたアクセス許可に被害者が同意しているため、攻撃者は365-Stealer上で被害者の受信メールを閲覧することができます。

また、「Mail.Send」「MailboxSettings.ReadWrite」のアクセス許可に被害者が同意しています。攻撃者が365-Stealerを使用し、被害者としてメールを送信することでビジネスメール詐欺や内部フィッシングに悪用したり、メールルールの設定追加によりビジネスメール詐欺に悪用したり、全ての受信メールを攻撃者に転送したりすることも可能です。

同意フィッシングへの対策

同意フィッシングへの対策を記載しますが、Microsoft社が対策や調査方法をまとめているため、併せて確認していただくことを推奨します。[17][18][19][20][21]

対策として、防御と事後対応と検知について紹介します。
まずは防御についてです。
組織内のユースケースに依りますが、業務影響がなければ攻撃面を減らすためにアプリケーションに対するユーザの同意を禁止することを推奨します。Entra IDポータルの「エンタープライズアプリケーション>セキュリティ>同意とアクセス許可>ユーザーの同意設定」にて「ユーザの同意を許可しない」を選択することでユーザの同意を禁止できます。

設定変更後にユーザがアプリケーションに対して同意できなくなります。

ユーザの同意を無効化しても既に同意済みのアプリケーションは許可されたままであるため、併せてアプリケーション及び同意済みのアクセス許可の棚卸しを実施することを推奨します。加えて、ユーザの同意を無効化しても管理者であればアプリケーションに同意可能である点に関してはご注意ください。

また、「エンタープライズアプリケーション>セキュリティ>同意とアクセス許可>管理者の同意設定」にて管理者の同意フレームワーク[22]を設定可能です。管理者の同意フレームワークを設定することでユーザの同意を管理者がコントロールすることが可能です。

管理者の同意フレームワークを設定すると、アプリケーションへの同意画面が表示されるタイミングでユーザ自身が同意できない場合にレビュー担当者に対して同意要求ができます。

レビュー担当者に設定した管理者に同意要求に関するメールが届きます。「要求を確認する」を選択すると管理者の同意要求画面に遷移します。

ユーザが同意要求したGraph Explorerが保留中として表示されます。Graph Explorerを選択します。

「アクセス許可のレビューと同意」を選択します。

アプリケーションに同意するために必要なアクセス許可が表示されます。問題なければ管理者として同意をします。

この一連の管理者の同意ワークフローでは、「管理者の同意」[23]をしているため、テナント内の全てのユーザが同意なしに承諾したアプリケーションを使用可能な状態になります。ただし、「管理者の同意」済みでないアクセス許可をユーザが利用する場合、追加で管理者の同意要求の一連の流れが必要になります。テナント全体での利用が適さないアプリケーションの場合、個別のユーザに代わって同意を付与することができます。[24]

次は事後対応についてです。
Entra IDポータルの「管理>エンタープライズアプリケーション>”不正なアプリケーション”>プロパティ」にて、不正なアプリケーションを削除することでアクセス許可を削除できます。一方で影響範囲の調査が必要な場合、不正なアプリケーションを非アクティブ化することで一時的にアクセス許可を無効化することもできます。Entra IDポータルの「管理>エンタープライズアプリケーション>”不正なアプリケーション”>プロパティ」にて「ユーザーのサインインが有効になっていますか?」を「いいえ」に設定することで非アクティブ化することができます。[25]

「SecurityCheck」を非アクティブ化したことで「SecurityCheck」に紐づく365-Stealerにて新たなアクセストークンの取得ができなくなったことを確認しました。

続いて検知についてです。
Entra ID監査ログで検知する場合、「Consent to application」イベントを探すことが有効です。ログから同意したユーザ、同意したアプリケーション、同意した権限等の情報を確認することができます。

最後に、FIDO2を含むMFAは、同意フィッシングに対する有効な防御手段ではありませんが、通常のフィッシングや認証試行に対して有効な防御手段ではあるため、必ず設定していただくことを推奨します。加えて、ユーザ教育、注意喚起も含め、多層的に対策していくことを推奨します。

まとめ

今回はEntra IDの同意フィッシングについて紹介しました。同意フィッシングは、MFAを突破する強力な攻撃です。低権限のアクセス許可であっても攻撃者の情報収集に悪用され、更なる攻撃に繋がる可能性があることをデモを通して解説しました。
このブログを通じて攻撃に対する脅威を認識いただき、少しでもセキュリティ対策の強化に繋げていただくことができれば幸いです。

付録.ConsentFix

ClickFix[26]の手法と同意フィッシング(Consent Phishing)で使用された認可コードフローを悪用した手法を組み合わせた攻撃がConsentFix[27][28][29]になります。ConsentFixの実際の画面イメージはPush Security社の記事[27]をご確認ください。

簡易化したConsentFixの流れを記載します。

同意フィッシングでは、攻撃者が作成したアプリケーションにユーザが同意する必要がありましたが、ConsentFixではユーザがアプリケーションに同意する必要はありません。ConsentFixでは、攻撃者はAzure CLI等の事前同意済みの公開されたファーストパーティアプリケーションのアプリケーションIDを悪用します。これらのアプリケーションは事前同意済みであるため、被害者による同意無しに認可コードが発行されます。同意フィッシングでは、リダイレクトURLに指定された攻撃者管理Webサイトに被害者がアクセスすることで攻撃者が認可コードを取得します。これに対し、ConsentFixでは攻撃者が被害者を騙し、認可コードを含むリダイレクトURLをフィッシングサイトに対してコピー&ペーストさせることで認可コードを取得します。
アプリケーションのリダイレクトURLは事前設定されたもののみが使用可能ですが、Azure CLI等の事前同意済みの公開されたファーストパーティアプリケーションの一部ではlocalhostに対するリダイレクトや名前解決できない開発用URLへのリダイレクトが許可されています。攻撃者は、これらを利用して認可コード付きのリダイレクトURLがエラー画面等を通じて被害者の目に留まりやすい状態を作り出し、コピー&ペーストするよう誘導します。

公開情報から読み取ることができるConsentFixの手順で、認可コード発行とトークン発行を行います。リダイレクトURLにlocalhostを指定した場合であっても、認可コードとトークンを異なるIPアドレスから発行可能であることを確認しました。

防御方法について紹介します。
ConsentFixに対して脆弱なアプリケーションのサービスプリンシパル[30]を作成し、サービスプリンシパル利用に割り当てを必須化することで認可コードの発行を防ぐことができます。[31] ConsentFixに対して脆弱なアプリケーションは複数ありますが、Azure CLIを一例として具体的な流れを記載します。この手順は業務影響の有無を調査してから実施することを推奨します。
まず、Azure CLIのアプリケーションIDである04b07795-8ddb-461a-bbee-02f9e1bf7b46に対応したテナント内の実体であるサービスプリンシパルを作成します。

Azure CLI のサービスプリンシパル利用に割り当てを必須にします。

上記対応後に認可コード発行のためのURLにアクセスすると認可コードが発行されないことを確認しました。

一方でAzure CLIの利用に割り当てを必須化した場合、割り当てが無ければ正規利用者がAzure CLIを利用できません。Azure CLIの利用が必要な正規利用者をサービスプリンシパルに割り当てます。

サービスプリンシパルに割り当てたユーザは認可コードを入手可能であり、Azure CLIを利用できることを確認しました。

参考文献

執筆者の他の記事を読む