Consent Phishing（同意フィッシング）と ConsentFixとは？～正規の OAuth （認可）フローを悪用した仕組みと対策

はじめに

認証と認可の違い

クラウドサービスなどで広く使われている認可の仕組み OAuth (Open Authorization) の正規フローを悪用したフィッシング事例について、その仕組みを紐解いたうえで対策について解説します。本稿では実際に攻撃事例が確認されている、一般的に「Consent Phishing（同意フィッシング）」と「Consent Fix」についてその仕組みを記載するにあたり、まずは前提として認証と認可の違いについて整理します。

以下で、認証と認可の違い、その代表的な技術とその概要を整理しました。本稿で記載する内容は概略ですが、悪用手法を理解するためだけでなく、対策を検討する上で重要な前提知識のため、お読みいただけるとより理解が深まるでしょう。

認証（Authentication）とは

認証とは、ユーザが身元を証明するプロセスです。例として、ログインする際にユーザ名とパスワードを入力することや、本人確認のために身分証を呈示することが挙げられます。認証を行うための代表的な技術として、SAML^※ や OIDC^※、Kerberosがあります。
※SMAL（Security Assertion Markup Language）。
※OIDC（OpenID Connect）。

認可（Authorization）とは

認可とは、あるユーザのアクセス権限を検証するプロセスです。例として、あるユーザがログインした後で管理画面を開くことができるかを確認することや、特定のユーザのみにアクセス権限を付与することが挙げられます。認可を行うための代表的なプロトコルとして、OAuth^※ や GNAP^※ が挙げられます。
※OAuth（Open Authorization）。
※GNAP（Grant Negotiation and Authorization Protocol）。

	概要	使用例	代表的な技術
認証 (Authentication)	身元を証明する仕組み	サービス「あなたは誰ですか？」ユーザ「私は田中です。これがパスワード、証明書です」サービス「本人であることを確認しました」	・SAML（Webサービス間の認証規格）・OIDC（OAuth に認証レイヤーを追加したもの）・Kerberos（ネットワーク認証方式）
認可 (Authorization)	権限を検証する仕組み	ユーザ「田中としてログインしています。このファイルにアクセスできますか？」サービス「田中さんには閲覧権限があります/ありません」	・OAuth（業界標準の認可プロトコル）・GNAP（次世代の認可プロトコル）

表：認証と認可についての整理

本記事のメインテーマである Consent Phishing および ConsentFix は、認可プロトコルである OAuth のフローを悪用した攻撃手法です。

OpenID Connect（OIDC）/OAuth2.0の流れ

認証と認可について整理した内容を踏まえて、OAuth 2.0 を使用した認証フローである、OpenID Connect（OIDC）認証フローについての概要を記載します。OIDCはIDプロバイダでログインして、その結果を安全にサービスへ渡す仕組みで、ブラウザリダイレクトと認可コードを使って安全にトークンを交換します。

以下に記載した図のうち、項番5および6がOAuth 2.0（認可）に相当します。

1. ユーザ（End-User）はサービス（Relaying Party）に対しアクセスをリクエストします。
2. サービスが OIDC に対応していた場合、サービスはユーザのブラウザへ対しIDプロバイダ（OpenID provider）へリダイレクトするようレスポンスを返します。
3. IDプロバイダはユーザが本人であることを確認するため、認証情報の要求をします。ユーザの画面上ではIDプロバイダの認証画面が開きます。（認証フロー）
4. ユーザは認証情報を送信します。（認証フロー）
5. IDプロバイダは認証情報を確認後、ユーザに対し、このサービスにログインすることを許可するかどうか、同意を求めます。（認可フロー）
6. ユーザが許可（同意）したことをIDプロバイダへ返します。（認可フロー）
7. IDプロバイダは認可コード含むレスポンスをユーザのブラウザ経由でサービスに対し発行します。ユーザのブラウザはレスポンス内に含まれるリダイレクト先に従い、サービスへリダイレクトします。
8. 認可コードを受け取ったサービスは、IDプロバイダに対して認可コードとアクセストークンの交換を要求します。
9. IDプロバイダは認可コードをアクセストークンに交換し、サービスに対して発行します。

このフローを踏まえ、次に悪用手法として Consent Phishing と ConsentFix の仕組みについて記載します。

Consent Phishing（同意フィッシング）の仕組み

Consent Phishing（同意フィッシング）は、一般的に「OAuth Consent Grant Attack（OAuth の同意付与攻撃）」や、「Illicit Consent Grant Attack（不正な同意付与攻撃）」などと呼称される、正規の OAuth による認可フローを悪用した手法です。以下に、Consent Phishing の流れを、当社でも攻撃事例を確認している Entra ID/Microsoft 365 をベースに記載します。

① 攻撃者は、攻撃者のEntra テナント上に、エンタープライズアプリケーションを登録します。このとき、認可コードを送信する宛先として攻撃者のドメインを設定します。登録が完了した後、アプリケーションへの追加を要求するOAuth の同意を求めるURLを生成します。このURLは正規のアイデンティティプロバイダ（Idp）のドメインになります。

② 生成した OAuth 同意用のURLを、被害者へ送付します。

③ 被害者は、URLへアクセスします。アクセス時、認証が完了していない場合には認証を行います。認証が完了している場合、または認証済の場合には以下の画面が表示されます。この画面は正規の OAuth 同意画面です。

④ 被害者ユーザによる承諾（同意）が完了すると、正規のOAuthフローに基づき攻撃者がアプリに設定していたドメインへ認可コードが発行されます。攻撃者は発行された認可コードを、アクセストークンと交換します。

⑤ 攻撃者は入手したアクセストークンを用いて被害者ユーザのリソースへアクセスします。Microsoft 365 に対する攻撃で当社が確認している事例では、代表的なサービスとして Graph API^※ が用いられていました。攻撃者は Graph API 経由で被害者のリソースへアクセスします。
このとき、攻撃者がアクセスできるリソースは要求して許可された権限の中で、被害者ユーザがアクセス可能なリソースに限定されます。例えば被害者ユーザが管理者レベルの権限を保持していた場合、攻撃者がアクセス可能となる範囲は広域になります。
※Graph API：Web APIの1つで、Microsoft Cloud サービスリソースへのアクセスを可能するAPI。Microsoft 365 アプリケーションがインターネット経由で情報をやり取りする際に利用される。

ConsentFix の仕組み

2025年12月にPush Security社が報告したConsentFix（別名Auth Code Fix）は、ClickFix と呼ばれるフィッシング手法を用いて OAuth の正規フローを悪用することで、被害者ユーザの操作により攻撃者がアクセストークンを取得・悪用する攻撃手法です。その名称から Consent Phishing と類似した手法を想起させますが、実際には全く異なる攻撃手法です。以下に、ConsentFix の仕組みを記載します。

（関連記事）ClickFix（クリックフィックス）とは？多様な攻撃に悪用されるソーシャルエンジニアリングの手口

① 被害者ユーザは、フィッシングサイトへアクセスします。フィッシングサイトには、正規のURLへアクセスした後、そのリダイレクト先URLをフィッシング画面へ入力する指示が記載されています。

② 被害者ユーザはフィッシングサイトに記載の指示に従い、正規の認証画面へアクセスします。このとき、IDプロバイダへアクセスするURL内には、被害者ユーザのローカル端末に認可コードを発行するリクエストを含んでいます。

以下は、攻撃者が被害者にアクセスを誘導する最初のURLの例です。
ここでは、例として Microsoft Graph API の認可コードを窃取する内容を挙げていますが、ConsentFix の攻撃手法は Microsoft のサービスに限らず、OAuth を使用する ID プロバイダは影響を受ける可能性があることに注意が必要です。

https://login.microsoftonline.com/common/oauth2/v2.0/authorize
?client_id=04b07795-8ddb-461a-bbee-02f9e1bf7b46
&response_type=code
&redirect_uri=hxxp://localhost:<port>
&response_mode=query
&scope=openid%20profile%20offline_access%20https://graph.microsoft.com//.default
&state=12345

これは OAuth のフローに則り、認可コードの取得を行うURLです。
redirect_uri に「hxxp://localhost:8400」を指定することが ConsentFix のポイントです。ここでは、認可コードをどこに対して発行するか、を指定しています。

Localhost を指定することで、URLをクリックした端末、つまり被害者の端末に対して認可コードが発行されます。ファーストパーティーアプリと呼ばれる一部のアプリ（Azure CLI や Graph API など）ではその性質上、localhost に対して認可コードを発行することが可能です。ファーストパーティーアプリのクライアントIDは固定されているため、上記の例の場合、URL内の「client_id」にGraph APIのIDを含めることで、Graph API 用の認可コードを取得できます。

③ 認証が未完了の場合、IDプロバイダから本人情報の確認要求を受け取ります。（認証フロー）

④ ユーザはIDプロバイダへ認証情報を送信します。（認証フロー）

⑤ IDプロバイダはユーザの認証が完了すると、②でユーザがアクセスした URL に含まれるパラメータ（client_id や redirect_uri）を参照し、そのアプリ（例：Graph API）向けの認可コードを生成します。
（②の例の場合、Graph API へのアクセスを要求）

⑥ IDプロバイダはユーザからの要求を受け、認可コード含むレスポンスをユーザのローカルへ対して返します。

⑦ ユーザは攻撃者のフィッシングサイトに記載の指示へ従い、認可コードが含まれるURLをフィッシングサイトへ入力します。

⑧ 攻撃者は、ユーザから送られてきた認可コードを用いて、正規のIDプロバイダに対しアクセストークンを要求します。

⑨ IDプロバイダは発行したトークンを攻撃者へ送付します。

このように ConsentFix では、正規の OAuth の仕組みによって発行した認可コードを攻撃者へ送付することで、攻撃者はアクセストークンを取得し、被害者ユーザのリソースへ不正アクセスすることが可能となります。

アクセストークンが攻撃者の手へ渡るとどのような影響に繋がるのか

アクセストークンが攻撃者によって利用可能となった場合、ログイン時に必要なユーザ情報やパスワードといった認証情報を持っていなくとも、攻撃者による不正アクセスが可能となります。

例として記載した Microsoft Graph API などの API へ対するアクセスが成功した場合、Teamsチャットの内容や、SharePointやOneDrive に保存されているファイルの取得・閲覧の他、メールボックスの閲覧・操作も可能となる場合があり、侵害されたアカウントから、機密情報の漏洩やグループ企業・取引先に不正なURLやファイルを送付する、といったが可能となります。短時間で重大なセキュリティインシデントに発展する可能性があり、侵害後の検知が困難であることから事前の対策が重要です。

それぞれの攻撃手法の対策

これまで記載したように、Consent Phishing と ConsentFix は、どちらも正規の OAuth フローを悪用し被害者のリソースに不正アクセスを行う攻撃手法ですが、悪用されているロジックがそれぞれ異なります。そのため、手法ごとに影響範囲の確認と対策を行う必要があります。ここからはそれぞれの攻撃手法に応じてどのような対策をすべきかその概要を整理します。

Consent Phishing の対策

Consent Phishing の対策としては、アプリケーションの監査やユーザ権限の棚卸しが有効です。

●ユーザに同意の許可権限を与えない
●ユーザの権限を最小限にする
●追加されたアプリケーションの監査

また、当社の TrendAI Vision One をご利用中のお客様は Third-Party Integration から Microsoft Entra ID と連携することで、不審な同意の検出を監視することが可能です。以下は、検証環境で検出した検知の例です。
（※検出内容や検出名は一例であり、利用環境によっては一部異なる可能性があります。）

●検出フィルタ名: Unusual Application Consent Behavior
●場所: Trend Vision One コンソール>Agentic SIEM and XDR > Observed Attack Techniques から確認可能です。

画面：TrendAI Vision One で不審なAppの同意を検知した場合の検出例

ConsentFixの対策

ConsentFix はソーシャルエンジニアリングの手法を用いて、権限を持ったユーザの操作を促すため、技術的対策で未然に攻撃を100%防ぐことは困難ですが、ローカルへ認可コードを発行できるアプリケーションの棚卸や、アクティビティログの監査が対策として有効です。加えて、認可コードのリクエスト/レスポンスのネットワーク上の通信監視も対策となり得ます。
また、攻撃の成立にはユーザ操作が前提となるため、一般的なフィッシング対策と同様にユーザへの注意喚起やセキュリティ教育も効果的と言えます。

TrendAI Vision One では従業員向けのプロアクティブなセキュリティ対策として、Phishing Simulation によるメール訓練を行うことが可能です。

執筆者

Consent Phishing（同意フィッシング）と ConsentFixとは？～正規の OAuth （認可）フローを悪用した仕組みと対策 | トレンドマイクロ (JP)

押田香緒里

トレンドマイクロ株式会社
JP Cyber Service Center, Sr. Engineer

2020年に入社後、エンタープライズ向けセキュリティ製品のテクニカルサポート業務に従事。現在は脅威分析やインシデント対応を担当。多様な現場の運用課題の対応を踏まえ、攻撃手法の調査や防御策の検討に携わりながら、実際の運用に根ざした実践的なセキュリティ支援を行っている。同時に、専門的な内容を現場目線で分かりやすく伝え、セキュリティに詳しくないエンジニアでも実践しやすい対策の紹介に取り組んでいる。