ConsentFix デブリーフィング：新たな OAuth フィッシング攻撃から得られた洞察

12月、Push Security のリサーチチームは、私たちがConsentFixと名付けた、まったく新しい攻撃手法を発見し、阻止しました。この手法は ClickFix 風のソーシャルエンジニアリングと OAuth 同意フィッシングを組み合わせ、Microsoft アカウントを乗っ取るものでした。 

私たちは、攻撃者が侵害した多数のWebサイトに悪意のあるペイロードを注入して運用している攻撃を確認しました。これは大規模なキャンペーンを形成しており、複数の顧客環境で検知されました。 

ConsentFix は、非常に短期間でコミュニティからかなり素晴らしい反響を得ました。

数日以内に、John Hammond が、自身のラボで構築した改良版の手法を共有し、また Microsoft、Glueck Kanja、その他の個人寄稿者のセキュリティ研究者たちも、分析と推奨事項を共有しました。 

本ブログでは、このキャンペーンに関する新たな洞察を共有し、コミュニティ全体で共有された主要な推奨事項とリソースをまとめ、そしてこの新しい手法が急速に一般化していく中で今後どうなっていくのかを展望します。 

まずは、ConsentFix とは何か、そしてどのように機能するのかを簡単に振り返りましょう。 

ConsentFix 入門

ConsentFix は、フィッシングページを介して被害者に OAuth の認可コードを攻撃者へ共有させる攻撃手法です。攻撃者はその後、自身のデバイス上の標的アプリケーションにこのコードを入力し、認可のハンドシェイクを完了させてアカウントを乗っ取ります。 

OAuth を乗っ取ることで、攻撃者はパスワードや MFA といったアイデンティティ層の制御を実質的に回避できます。パスキーのようなフィッシング耐性のある認証方式であっても、この攻撃には影響しません。なぜなら、認証プロセス自体を完全に迂回するからです。 

OAuth の悪用攻撃は新しいものではありません。同意フィッシングやデバイスコードフィッシングといった手法は以前から存在します。

しかし、これらは主に、主要なワークスペースアカウント（例：Microsoft、Google など）を、攻撃者が管理する不正なアプリケーションに接続させることに焦点を当てています。ところが、より厳格な既定構成により、Azure のような中核的なエンタープライズクラウド環境では、これはますます困難になっています。とはいえ、デバイスコードフィッシングは、最近の2025年の注目度の高い Salesforce 攻撃でも依然として目立っていました。

ConsentFix がこれほど危険な理由は？

一般的な OAuth 攻撃とは異なり、新しい ConsentFix のアプローチにより、攻撃者は通常狙うものとは異なる種類のアプリケーションを標的にできました。これは検知と対応に大きな影響を及ぼします。このケースでは、攻撃者は次のことを行いました：

• サードパーティアプリケーションと同様の方法では制限できず、かつすべてのテナントで事前同意されている（つまり、ユーザーが管理者承認なしで認証できる）Microsoft のファーストパーティアプリを明確に標的にした。 

• 既定のログ記録の対象外であるレガシースコープを利用して検知を回避し、さらに条件付きアクセス ポリシーの除外が既知のスコープを標的にした。

つまり、悪意のある OAuth 付与をブロックすると期待される既定の制御が適用されず、仮に被害に遭っても検知のためのログが有効化されていない可能性があり、さらに条件付きアクセス ポリシーの除外により、多くの組織で想定している制御がこのケースでは意図どおりに機能しない、ということです。 

ConsentFix キャンペーンの振り返り

ConsentFix キャンペーンがどのように実装されたのかを簡単に振り返りましょう。 

被害者には、人間であることを確認するために URL をフィッシングページに貼り付ける必要があるページが表示されます。

「Sign In」ボタンをクリックすると、正規の Microsoft ログインページが開きます。ユーザーがすでにログインしている場合（通常のブラウザで作業していれば、その可能性は高いです）、アカウント情報はすでに事前入力されており、再認証は不要です。 

アカウントを選択すると、OAuth の認可コードを含む localhost URL にリダイレクトされます。これを元のフィッシングページに投稿して攻撃を完了させます。 

攻撃者がその URL を入手すると、標的としている特定のアプリケーション（このケースでは Azure CLI）向けのアクセストークンまたはリフレッシュトークンに交換できます。

要するに、攻撃者は、ユーザーが Azure CLI にログインする際に発生する認可フローを手動で完了させているのです。Azure CLI は、Azure AD / Entra ID 環境を容易に管理できるコマンドライン クライアントです。ただしこのケースでは、被害者の情報を使って攻撃者のデバイス上でログインしているのです。 

最新のキャンペーン詳細

ブログ記事を公開して以降、追跡を継続する中で、このキャンペーンに関する追加の詳細がいくつも明らかになりました。 

共同で取り組んでいる脅威リサーチャーの裏付けにより、ロシア国家系の APT29 と関連しているようです。これは、私たちが観測したステルス性の高い戦術と整合します。これらは、犯罪系フィッシングキャンペーンで見られるありふれた検知回避手法をはるかに超えています。 

また、Volexity が特定した、手動版の攻撃を特徴とするこのロシア関連キャンペーンと多くの類似点があり、その発展形であるように見えます。そこでは、被害者がメールでソーシャルエンジニアリングされ、Microsoft の URL を開いて localhost の応答をコピーし、それをメールで攻撃者に送り返すよう誘導されていました。 

コミュニティからの主な貢献

先ほど触れたとおり、ConsentFix に対するコミュニティの反応は驚くべきものでした。 

いつものことながら、多くのベンダーが「当社製品を導入してください」を推奨としてこの攻撃手法を取り上げています。これは想定内ですが、EDR 製品を推しているベンダーの中には、この攻撃を検知もブロックもできるはずがないものもあり、誤解を招きます。 

しかし、マーケティングを差し引いて見ると、本当に優れたリソースと推奨事項が数多く共有されました。 

John Hammond による V2.0 の公開

数日以内に、John Hammond は自身の YouTube チャンネルで ConsentFix について投稿し、攻撃者が使用していた ConsentFix 実装の洗練された改良版を披露しました。

彼のバージョンでは、Microsoft の認可コードを含む URL がポップアップのブラウザウィンドウで生成され、それをそのままドラッグ＆ドロップでフィッシングページに投入できました。 

この実装ははるかにスムーズで、被害者がだまされる可能性が大きく高まります。そして、これがわずか数日で実現したのです… 

追加の脆弱なファーストパーティアプリが特定

Glueck Kanja の Fabian Bader と Dirk-jan Mollema は、ConsentFix の影響を受けるより広範なファーストパーティアプリに関する優れたリソースを共有しています。 

合計で、ConsentFix の影響を受け、かつ既知の条件付きアクセスの除外（アプリ全般、またはアプリに対して特定のスコープが要求された場合のいずれか）を持つアプリは 11 個あります：

• Microsoft Azure CLI: 04b07795-8ddb-461a-bbee-02f9e1bf7b46

• Microsoft Azure PowerShell: 1950a258-227b-4e31-a9cf-717495945fc2

• Microsoft Teams: 1fec8e78-bce4-4aaf-ab1b-5451cc387264

• Microsoft Whiteboard Client: 57336123-6e14-4acc-8dcf-287b6088aa28

• Microsoft Flow Mobile PROD-GCCH-CN: 57fcbcfa-7cee-4eb1-8b25-12d2030b4ee0

• Enterprise Roaming and Backup: 60c8bde5-3167-4f92-8fdb-059f6176dc0

• Visual Studio: 872cd9fa-d31f-45e0-9eab-6e460a02d1f1

• Aadrm Admin Powershell: 90f610bf-206d-4950-b61d-37fa6fd1b224

• Microsoft SharePoint Online Management Shell: 9bc3ab49-b65d-410a-85ad-de819febfddc

• Microsoft Power Query for Excel: a672d62c-fc7b-4e81-a576-e60dc46e951d

• Visual Studio Code: aebc6443-996d-45c2-90f0-388ff96faa56

ConsentFix の今後予測

セキュリティ研究者によって ConsentFix 手法の新しい反復が共有されるスピード、そして悪用可能なアプリとスコープの幅広さを踏まえると、レッドチームも犯罪者も、近い将来、ConsentFix を TTP の武器庫に必然的に取り入れるでしょう。

新たな ConsentFix の亜種は、間もなく（すでに流通している可能性も含め）出現すると考えられます。 

Microsoft 環境の防御を担うすべてのセキュリティチームは、監視コントロールと緩和策を最優先事項として確実に整備すべきです。 

セキュリティチーム向けの更新された推奨事項

完全にブラウザネイティブな攻撃手法であるため、この攻撃の検知や事前ブロックに関して、多くの従来型セキュリティツールやデータソースは有用性が限定的です。同時に、この攻撃は Microsoft の既定のセキュリティ構成を悪用し、予防と検知の両方の制御を回避します。

ブラウザのコンテキスト内で完結する ConsentFix のような最新攻撃に対処するには、組織が検知面としてブラウザを監視し、悪意ある活動の兆候をハンティングし、攻撃をリアルタイムでブロックすることが不可欠です。これは、エンドポイント攻撃に対して EDR が機能することを期待するのと同じ考え方です。 

この攻撃に対する唯一の防衛線として Microsoft のログに依存している組織向けに、コミュニティの反応により、リストに追加すべき新たな推奨事項がいくつかあります： 

• 非推奨となった AADGraphActivityLogs のログ記録が有効になっていることを確認する。

• 上で強調したアプリケーション ID に加え、Windows Azure Active Directory（00000002-0000-0000-c000-000000000000）および Microsoft Intune Checkin（26a4ae64-5862-427f-a9b0-044e62572a4f）のリソース ID をログでハンティングする。

• 脆弱な各アプリに対してサービス プリンシパルを作成し、アクセスを許可するユーザーを制限することで、この手法でフィッシングされ得るユーザーの攻撃対象領域を縮小する。

• 条件付きアクセス ポリシーで CLI ツールへのアクセスをブロックし、許可されたユーザー/グループに対して除外を設定する。 

役立つ可能性のある追加リソースとして、ConsentFix 向けにコミュニティが作成したElastic の検知ルールや、Glueck Kanja による追加の緩和策およびハンティングのガイダンスもあります。 

Push Security について詳しく知る

これはまったく新しい手法でしたが、Push は顧客がそれとやり取りする前に攻撃を捕捉し、遮断しました。 

Push は、深いブラウザテレメトリに支えられた振る舞いベースの脅威検知コントロールを用いて、ブラウザベースの攻撃を検知します。これにより、ブラウザ内で発生する攻撃に対して幅広い検知・ブロック機能を提供します。つまり、Webページがブラウザで読み込まれ/実行されるエンドツーエンドのプロセスと、ユーザーがページとどのように相互作用するかを分析し、不正活動の普遍的な指標を見つけ出します。 

IoC ベースの検知が攻撃者にとって容易に回避できる世界において、悪意あるWebサイトを検知する唯一の信頼できる方法がこれです。既知の悪性を叩くモグラ叩きではなく、Push はゼロデイのブラウザ脅威であってもリアルタイムで検知・ブロックします。

Push は、AiTM フィッシング、クレデンシャルスタッフィング、悪意あるブラウザ拡張機能、ClickFix、ConsentFix、セッションハイジャックといったブラウザベースの攻撃を阻止します。

すべてが破綻するまで待つ必要もありません。Push を使えば、ゴーストログイン、SSO カバレッジのギャップ、MFA のギャップ、脆弱なパスワードなど、従業員が利用するアプリ全体にわたる脆弱性をプロアクティブに見つけて修正し、アイデンティティ攻撃対象領域を強化することもできます。

Push について詳しく知るには、最新の製品概要をご覧いただくか、チームメンバーとのライブデモの時間をご予約ください。