12月、Push Securityのリサーチチームは、ConsentFixと名付けた全く新しい攻撃手法を発見し、ブロックしました。この手口は、クリックフィックス型のソーシャルエンジニアリングとOAuth同意フィッシングを組み合わせたもので、マイクロソフトのアカウントを乗っ取るものでした。

私たちは、攻撃者が悪意のあるペイロードを注入する侵害されたウェブサイトの大規模なネットワーク上でこの攻撃が実行されているのを確認しました。

ConsentFixは、短期間のうちにコミュニティから非常に大きな反響を呼びました。

John Hammondは、自身のラボで開発したこのテクニックの新しい改良版を数日以内に共有し、Microsoft、Glueck Kanja、その他の個人貢献者のセキュリティ研究者は、分析と推奨事項を共有した。

このブログでは、このキャンペーンに関する新たな洞察を共有し、コミュニティ全体で共有された推奨事項やリソースをいくつかまとめ、この斬新なテクニックが急速に主流になるにつれて、今後どのような展開が待っているのかを展望する。

まずは、ConsentFixとは何か、どのように機能するのかを簡単にまとめてみよう。

ConsentFix 101

ConsentFixとは、フィッシング・ページを通じて攻撃者にOAuth認証コードを共有するよう被害者に促す攻撃手法である。攻撃者はその後、認証ハンドシェイクを完了させ、アカウントを乗っ取るために、このコードを自分のデバイス上のターゲット・アプリケーションに入力します。

OAuthをハイジャックすることで、攻撃者はパスワードやMFAのようなIDレイヤーのコントロールを効果的に回避することができる。パスキーのようなフィッシング耐性のある認証方法であっても、認証プロセスを完全に回避してしまうため、この攻撃には何の影響も及ぼさない。

OAuthを悪用した攻撃は新しいものではない。同意フィッシングや デバイスコードフィッシングのような手口は以前からありました。

しかし、これらは主に、主要なワークスペースのアカウント（MicrosoftやGoogleなど）を、攻撃者が管理する不正なアプリケーションに接続することに焦点を当てています。しかし、Azureのような中核的なエンタープライズ・クラウド環境では、デフォルト設定が厳しくなっているため、このようなことはますます難しくなっている。とはいえ、最近話題になった2025年のSalesforceの攻撃では、デバイスコードを使ったフィッシングが依然として目立っている。

a.fl_button { background-color：#border：a.fl_button { background-color: #5177b6; border: 1px solid #3b59aa; color：#text-align: center; text-decoration: none; border-radius: 8px; display: inline-block; font-size: 16px; font-weight: bold; margin：4px 2px; cursor: pointer; padding：12px 28px; } .fl_ad { background-color：#width: 95%; margin: 15px auto 15px auto; border-radius: 8px; border：1px solid #d6ddee; box-shadow: 2px 2px #728cb8; min-height: 200px; display: flex; align-items: center; } .fl_lef>a>img { margin-top: 0px !important; } .fl_rig>p { font-size: 16px; } .grad-text { background-image: linear-gradient(45deg, var(–dawn-red), var(–iris)54%, var(–aqua)); -webkit-text-fill-color: transparent; -webkit-background-clip: text; background-clip: text; } .fl_rig h2 { font-size: 18px!important; font-weight: 700; color：color: #333; line-height: 24px; font-family：font-family: Georgia, times new roman, Times, serif; display: block; text-align: left; margin-top: 0; } .fl_lef { display: inline-block; min-height: 150px; width: 25%; padding：10px 0 10px 10px; } .fl_rig { padding：10px; display: inline-block; min-height: 150px; width: 100%; vertical-align: top; } .fl_lef>a>img { border-radius: 8px; } .cz-news-title-right-area ul { padding-left: 0px; } @media screen and (max-width: 1200px) { .fl_ad { min-height: 184px; } .fl_rig>p { margin: 10p10px; } .fl_rig { padding：0 10px 10px 10px; width: 100%; } } @media screen and (max-width: 400px) { .cz-story-navigation ul li:first-child { padding-left: 6px; } .cz-story-navigation ul li:last-child { padding-right: 6px; } } }.

ConsentFixはなぜ危険なのか？

典型的なOAuth攻撃とは異なり、ConsentFixの斬新なアプローチは、攻撃者が通常狙うものとは異なるタイプのアプリケーションを標的にすることを可能にしました。この場合、攻撃者は

• サードパーティのアプリケーションと同じように制限することができず、すべてのテナントで事前にConsentされている（つまり、ユーザーは管理者の承認なしに認証することができる）ファーストパーティのマイクロソフトのアプリケーションを特にターゲットにした。

• 検出を回避するために、デフォルトのロギングの範囲外であるレガシースコープを活用し、既知の条件付きアクセスポリシーの除外を持つスコープを標的とした。

つまり、悪意のあるOAuth認証の付与をブロックするために期待されるデフォルトのコントロールは適用されず、もしそれが起こったとしても検知するためのロギングが有効になっていない可能性があり、さらに、条件付きアクセスポリシーの除外により、多くの組織で期待されるコントロールがこのケースでは意図したとおりに機能しないことを意味します。

ConsentFixキャンペーンのまとめ

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

被害者は、フィッシング・ページにURLを貼り付けることで、自分が人間であることを確認するよう要求されるページを閲覧する。

Sign In」ボタンをクリックすると、正規のマイクロソフトのログインページが開きます。ユーザーが既にログインしている場合（通常のブラウザーで作業している場合はログインしている可能性が高い）、アカウント情報は既に入力済みであり、再度認証する必要はない。

アカウントを選択すると、OAuth認証コードを含むlocalhost URLにリダイレクトされる。

攻撃者はこのURLを取得すると、ターゲットとなる特定のアプリケーション（この場合はAzure CLI）のアクセストークンやリフレッシュトークンと交換することができる。

要するに、ユーザーがAzure CLI（AzureのAD/Entra ID環境を簡単に管理できるコマンドラインクライアント）にログインする際に発生する認証フローを、攻撃者が手動で完了させているということだ。ただしこのケースでは、攻撃者のデバイスでログインするために被害者の情報を代わりに取得している。

最新のキャンペーン詳細

私たちがブログの投稿をシェアして以来、このキャンペーンに関する詳細が次々と明らかになりました。

私たちが協力している脅威研究者によって裏付けされたように、このキャンペーンはロシア国家に関連するAPT29に関連しているようです。これは私たちが観察したステルス的な手口と一致しており、犯罪的なフィッシングキャンペーンで使用されるありふれた検知回避テクニックをはるかに超えています。

これは、Volexityによって確認されたこのロシア関連キャンペーンと多くの類似点を共有しており、手動バージョンの攻撃を特徴とするこのキャンペーンの進化版であるように見えます。

コミュニティからの貢献

先に述べたように、ConsentFixに対するコミュニティの反応は驚くべきものでした。

相変わらず、多くのベンダーが「私たちの製品をインストールする」ことを推奨する攻撃手法を取り上げている。これは予想されたことではあるが、これらのベンダーの中には、攻撃を検知したりブロックしたりする方法が全くないEDR製品を推しているところもあり、誤解を招く。

しかし、マーケティングを切り抜けると、本当に素晴らしいリソースや推奨事項がたくさん共有された。

ジョン・ハモンドがリリースしたV2.0

数日のうちに、ジョン・ハモンドは自身のYoutubeチャンネルにConsentFixについて投稿し、攻撃者が使用するConsentFixの実装を巧妙に改良したことを披露した。

彼のバージョンでは、マイクロソフトの認証コードを含むURLは、単にフィッシング・ページにドラッグ・アンド・ドロップできるポップアップ・ブラウザ・ウィンドウに生成されていた。

この実装の方がはるかにスムーズで、被害者が引っかかる可能性が高くなる。そして、これは数日で完了した。

脆弱なファーストパーティ製アプリの追加を確認

Glueck KanjaのFabian Bader氏とDirk-jan Mollema氏は、ConsentFixの脆弱性があるより広範なファーストパーティアプリに関する素晴らしいリソースを共有している。

全部で11のアプリがConsentFixに対して脆弱であり、条件付きアクセスの除外（アプリ全般、またはアプリに対して特定のスコープが要求された場合）も知られている：

• 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

• エンタープライズローミングとバックアップ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コード: aebc6443-996d-45c2-90f0-388ff96faa56

ConsentFixの予測

ConsentFix テクニックの新しい反復がセキュリティ研究者によって共有されるスピードと、活用可能なアプリと可能なスコープの広さから、レッドチームと犯罪者の両方が近い将来 ConsentFix を TTP の武器として採用することは避けられないだろう。

新しいConsentFixの亜種が（まだ流通していないとしても）間もなく出現する可能性は高い。

マイクロソフトの環境保護に責任を持つすべてのセキュリティチームは、最優先事項として、監視コントロールと緩和策を確実に導入する必要があります。

セキュリティチームに対する最新の推奨事項

完全にブラウザネイティブの攻撃手法であるため、従来のセキュリティツールやデータソースの多くは、この攻撃を検知したり、先手を打ってブロックしたりする際に、あまり役に立ちません。同時に、この攻撃はマイクロソフトのデフォルトのセキュリティ設定を悪用して、防御と検知の両方のコントロールを回避します。

ConsentFixのような、完全にブラウザのコンテキスト内で発生する最新の攻撃に対処するためには、組織がブラウザを検知対象として監視し、悪意のある活動の兆候を探し、リアルタイムで攻撃をブロックすることが不可欠です。

この攻撃に対する唯一の防御手段としてマイクロソフトのロギングに依存している組織のために、コミュニティの反応のおかげで、リストに追加する新しい推奨事項がいくつかあります：

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

• Windows Azure Active Directory (00000002-0000-0000-c000-000000000000) および Microsoft Intune Checkin (26a4ae64-5862-427f-a9b0-044e62572a4f) のリソース ID と共に、上記のアプリケーション ID のログをハントする。

• 脆弱性のあるアプリごとにサービスプリンシパルを作成し、アクセスを許可されるユーザーを制限することで、この手法でフィッシングされる可能性のあるユーザーの攻撃対象範囲を狭めます。

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

その他のリソースとしては、コミュニティが作成したConsentFix用のElastic検知ルールや、Glueck Kanjaによるミティゲーションやハンティングのガイダンスなどがあります。

プッシュ・セキュリティについてもっと知る

これは全く新しい手法でしたが、Pushは攻撃を遮断し、顧客が攻撃とやり取りする前にシャットダウンしました。

Pushは、ブラウザで発生する攻撃に対する広範な検出とブロック機能を提供するために、ブラウザの詳細な遠隔測定による行動脅威検出コントロールを使用して、ブラウザベースの攻撃を検出します。これは、ブラウザでウェブページがロード／実行されるエンドツーエンドのプロセスや、ユーザーがページとどのようにやりとりするかを分析し、悪質なアクティビティの普遍的な指標を発見することを意味します。

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

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

また、ゴーストログイン、SSOカバレッジギャップ、MFAギャップ、脆弱なパスワードなど、従業員が使用するアプリ全体の脆弱性をプロアクティブに見つけて修正し、アイデンティティ攻撃面を強化するためにPushを使用することもできます。

Pushの詳細については、最新の製品概要をご覧いただくか、弊社チームによるライブデモをご予約ください。

a.fl_button { background-color：#border：1px solid #3b59aa; color：#text-align: center; text-decoration: none; border-radius: 8px; display: inline-block; font-size: 16px; font-weight: bold; margin：4px 2px; cursor: pointer; padding：12px 28px; } .fl_ad { background-color：#width: 95%; margin: 15px auto 15px auto; border-radius: 8px; border：1px solid #d6ddee; box-shadow: 2px 2px #728cb8; min-height: 200px; display: flex; align-items: center; } .fl_lef>a>img { margin-top: 0px !important; } .fl_rig>p { font-size: 16px; } .grad-text { background-image: linear-gradient(45deg, var(–dawn-red), var(–iris)54%, var(–aqua)); -webkit-text-fill-color: transparent; -webkit-background-clip: text; background-clip: text; } .fl_rig h2 { font-size: 18px!important; font-weight: 700; color：color: #333; line-height: 24px; font-family：font-family: Georgia, times new roman, Times, serif; display: block; text-align: left; margin-top: 0; } .fl_lef { display: inline-block; min-height: 150px; width: 25%; padding：10px 0 10px 10px; } .fl_rig { padding：10px; display: inline-block; min-height: 150px; width: 100%; vertical-align: top; } .fl_lef>a>img { border-radius: 8px; } .cz-news-title-right-area ul { padding-left: 0px; } @media screen and (max-width: 1200px) { .fl_ad { min-height: 184px; } .fl_rig>p { margin: 10p10px; } .fl_rig { padding：0 10px 10px 10px; width: 100%; } } @media screen and (max-width: 400px) { .cz-story-navigation ul li:first-child { padding-left: 6px; } .cz-story-navigation ul li:last-child { padding-right: 6px; } } }.

主催・執筆：Push Security.