eSecurity Planet のコンテンツおよび製品推奨は、編集上独立した立場で提供されています。パートナーへのリンクをクリックいただくことで、当社が収益を得る場合があります。 詳細はこちら
Microsoft Entra IDのサインインログは、認証活動に関する重要な可視性を防御側にもたらし、ユーザー列挙やパスワードスプレー攻撃をはじめとするID関連攻撃の調査に役立ってきました。
しかし、Proofpointによる調査によると、脅威アクターは「OAuthクライアントIDのなりすまし」と呼ばれる手法を使い、一般的な検知手法を回避しながら有効なユーザーアカウントや認証情報を特定するケースが増えているといいます。
要点
- 攻撃者はOAuthクライアントIDをなりすまし、一般的な認証ベースの検知手法を回避しながらMicrosoft Entra IDアカウントを列挙しています。
- なりすましたクライアントIDを使うと、Entraのサインインログ上でアプリケーション名が空欄になり、防御側が不審な活動の調査に頼る可視性が低下します。
- Proofpointは、異なるOAuthクライアントIDなりすまし手法を用いて数千のMicrosoft Entraテナントにまたがる数百万のユーザーアカウントを標的とした、大規模な2件のキャンペーンを確認しました。
- これらのキャンペーンは、OAuthクライアントIDなりすましが複数の脅威アクターに採用されつつある、スケーラブルなクラウド偵察手法へと発展していることを示しています。
- 組織は、ステルス性の高いクラウドID攻撃の検知能力を高めるため、ID監視の強化やリスクベースのアクセス制御、インシデント対応体制の整備を進めるべきです。
OAuthクライアントIDのなりすましがMicrosoft Entra IDアカウント列挙を可能にする仕組み
攻撃者は正規のOAuthアプリケーションを利用する代わりに、Microsoft Entra IDに登録された各アプリケーションに割り当てられるグローバル一意識別子(GUID)である「OAuthクライアントID」をなりすましています。
認証リクエストの際、攻撃者は正規アプリケーションに紐づくクライアントIDではなく、捏造または窃取したクライアントIDを提示します。これにより、自らOAuthアプリケーションを作成・登録することなく、クラウドID情報を探ることができます。
通常、すべての認証リクエストには、アクセスを要求しているアプリケーションを識別するクライアントIDが含まれています。
クライアントIDが登録済みアプリケーションと一致する場合、Microsoft Entra IDはそのアプリケーション名をサインインログに記録します。これにより防御側は、特定のアプリケーションを標的とした不審な認証活動を特定するための貴重な手がかりを得られます。
なりすましたクライアントIDは検知が困難
なりすましたクライアントIDを使われると、この可視性が失われます。提示されたクライアントIDが正規の登録済みアプリケーションに対応していないため、Microsoft Entraのサインインログ上ではアプリケーション名の項目が空欄のままになります。
アプリケーション名を頼りに認証の異常や特定のクラウドアプリケーションへの攻撃を検知しているセキュリティチームは、こうした活動を見落としてしまう可能性があります。
Proofpointの研究者はさらに、攻撃者がMicrosoft Entra IDの応答の違いを悪用し、提示したクライアントIDが有効かどうか、また標的とするユーザーアカウントやパスワードが実在するかどうかを判別できることも突き止めました。
脅威アクターはこうした応答を分析することで、サインイン成功イベントを発生させることも、防御側が従来監視してきた多くの兆候を残すこともなく、ユーザーの列挙や認証情報の検証、組織のクラウドID情報の収集を行えます。
大規模展開でも有効な手法
この手法は、大規模なキャンペーンの検知も一層困難にします。
攻撃者は、少数のよく知られたMicrosoftアプリケーションに認証試行を集中させるのではなく、数千に及ぶ架空のクライアントIDにリクエストを分散させることができます。
これにより認証テレメトリが分散し、認識しやすい攻撃パターンが減少するほか、特定のアプリケーションに絞った一部の条件付きアクセスポリシーが回避される可能性もあります。
OAuthクライアントIDなりすましキャンペーンが数百万のMicrosoft Entra IDアカウントを標的に
研究者は、OAuthクライアントIDのなりすましを利用しながらも、インフラ、ツール、実行方法が大きく異なる大規模キャンペーンを2件確認しました。
UNK_pyreq2323
1件目のキャンペーン「UNK_pyreq2323」は、2026年1月14日に初めて観測されました。
攻撃者は主にAmazon Web Services(AWS)のインフラを使い、python-requests/2.32.3のユーザーエージェントで認証リクエストを生成しながら、70万件を超えるなりすましOAuthクライアントIDに活動を分散させていました。
Proofpointによると、このキャンペーンは約4,000のMicrosoft Entraテナントにまたがる100万件超のユーザーアカウントを標的としていました。
認証失敗の試行回数が多かったため、標的となったユーザーの約28%でアカウントロックアウトが発生し、攻撃者に偵察の機会を与えるだけでなく、運用上の混乱も引き起こしました。
攻撃者はランダムなクライアントIDを生成するのではなく、よく知られたExchange OnlineアプリケーションのGUIDの末尾数桁のみを改変していました。
なりすました各クライアントIDは短時間しか使い回されずに破棄されており、防御側が活動を関連付けにくい仕組みになっていました。
UNK_OutFlareAZ
研究者はさらに、2025年12月に開始し主にCloudflareのインフラから活動していた2件目のキャンペーン「UNK_OutFlareAZ」も確認しました。
全体的な手法は同じでしたが、このキャンペーンはさらに規模が大きく、200万人超のユーザーを標的とし、約370万件のユニークななりすましアプリケーションIDを生成していました。
攻撃者は既存のアプリケーション識別子を改変するのではなく、認証リクエストごとに完全にランダムなUUIDv4形式のクライアントIDを生成していました。
この手法により、ほぼすべてのリクエストが異なるアプリケーション識別子から発信されているように見えるため、防御側が認証イベントを関連付ける手がかりはさらに減少しました。
攻撃者がクラウドアカウント列挙を大規模化した方法
このキャンペーンでは、Proofpointが過去に複数のアカウント列挙活動で確認していたMicrosoft Outlookのユーザーエージェントも使用されていました。
研究者は、攻撃者が複数の組織にわたって広範な偵察を行っていたことを示す追加の証拠も発見しました。
攻撃者は、dsmith、msmith、jbrownなど、よく使われる企業のユーザー名を、多数のMicrosoft Entraテナントに対して繰り返し試行していました。
Entra IDは有効なアカウントに対する認証試行のみを記録するため、これは攻撃者が正規ユーザーや一般的な企業のユーザー名の形式を特定しようとしていたことを示唆しています。
これら2件のキャンペーンは、OAuthクライアントIDのなりすましが、防御側が認証ベースの攻撃を検知するために頼る可視性を低下させながら、大規模なクラウドアカウント列挙を実現するスケーラブルな手法として台頭しつつあることを示しています。
Microsoft Entra IDにおけるOAuthクライアントIDなりすましの検知と対策
この2件のキャンペーンは、インフラ、ユーザーエージェント、クライアントIDの生成方法、列挙パターンにおいて異なっていましたが、いずれもOAuthクライアントIDのなりすましが広く採用されつつある偵察手法であることを示しています。
そのため、組織はMicrosoft Entra IDを監視する際、認証成功イベントだけに注目するのでは不十分です。
- Microsoft Entraのサインインログで、アプリケーション名の空欄、アプリケーションIDの欠落、AADSTS700016エラーコードを監視し、OAuthクライアントIDなりすましの兆候がないか確認してください。
- ユーザー、IPアドレス、ユーザーエージェント、サインイン失敗にまたがる認証活動を相互に関連付け、パスワードスプレー攻撃やアカウント列挙キャンペーンを特定してください。
- パスキーやFIDO2セキュリティキーなど、フィッシング耐性のある多要素認証(MFA)を必須にし、認証情報窃取の影響を軽減してください。
- アプリケーションベースの制御のみに頼るのではなく、ユーザーリスク、デバイスの健全性、ネットワークの所在地、認証強度を評価することで条件付きアクセスポリシーを強化してください。
- レガシー認証方式を無効化し、可能な限りOAuthのResource Owner Password Credentials(ROPC)を制限してください。
- 不審な認証活動の兆候がないか、Microsoft Entra Identity Protection、Defender XDR、その他のIDテレメトリを継続的に監視してください。
- クラウドアカウント列挙の試みを迅速に特定・調査・封じ込められるよう、ID関連のインシデント対応計画と検知ワークフローを定期的にテストしてください。
これらの対策を組み合わせることで、組織はクラウドID攻撃に対する耐性を高めることができます。
結論
クラウドID攻撃が進化を続ける中、セキュリティチームは自らの検知戦略も攻撃者の手法の進化に合わせて更新していく必要があります。
OAuthクライアントIDのなりすましは、脅威アクターが偵察段階での可視性を低下させる手口を示す好例であり、従来の認証監視だけでは有効性が低下しつつあることを浮き彫りにしています。
進化するID関連の攻撃手法は、アクセス制御を強化しブラストラディウス(被害の及ぶ範囲)を縮小するゼロトラストソリューションの必要性を一層高めています。
