OAuthクライアントIDのスプーフィングでクラウドアカウントのステルス列挙が可能に

Proofpointは、攻撃者がOAuthクライアントIDのスプーフィングを使い、Microsoft Entra IDのアカウントを密かに列挙していることを明らかにした。

執筆者
Ken Underhill
Ken Underhill
Jul 16, 2026
7 minute read
eSecurity Planet のコンテンツおよび製品のおすすめは、編集上の独立性を保っています。パートナーへのリンクをクリックすると、当社が報酬を得る場合があります。 詳細を見る

Microsoft Entra IDのサインインログは、認証アクティビティを可視化する重要な情報を防御側に提供してきた。これによりセキュリティチームは、ユーザー列挙やパスワードスプレーなど、アイデンティティを標的とする攻撃を調査できる。

しかし、Proofpointの調査によると、脅威アクターはOAuthクライアントIDスプーフィングと呼ばれる手法をますます利用するようになっている。この手法により、一般的な検知方法を回避しながら、有効なユーザーアカウントと認証情報を特定している。

重要なポイント

  • 攻撃者はOAuthクライアントIDをスプーフィングし、一般的な認証ベースの検知手法を回避しながらMicrosoft Entra IDのアカウントを列挙している。
  • スプーフィングされたクライアントIDでは、Entraのサインインログにアプリケーション名が記録されないため、セキュリティチームが不審なアクティビティを調査する際に頼る可視性が低下する。
  • Proofpointは、異なるOAuthクライアントIDスプーフィング手法を使い、数千のMicrosoft Entraテナントにまたがる数百万のユーザーアカウントを標的にした大規模キャンペーンを2件特定した。
  • これらのキャンペーンは、OAuthクライアントIDスプーフィングが、複数の脅威アクターに採用されるスケーラブルなクラウド偵察手法へと進化していることを示している。
  • 組織は、ステルス型のクラウドアイデンティティ攻撃の検知精度を高めるため、アイデンティティ監視、リスクベースのアクセス制御、インシデント対応の準備態勢を強化すべきだ。

OAuthクライアントIDスプーフィングによってMicrosoft Entra IDアカウントの列挙が可能になる仕組み

攻撃者は正規のOAuthアプリケーションを使う代わりに、OAuthクライアントIDをスプーフィングしている。これは、Microsoft Entra IDに登録されたすべてのアプリケーションに割り当てられる、グローバルに一意な識別子(GUID)だ。

認証リクエストの際、攻撃者は正規のアプリケーションに関連付けられたクライアントIDではなく、偽造または盗難したクライアントIDを提示する。これにより、自らOAuthアプリケーションを作成・登録することなく、クラウド上のアイデンティティを探ることができる。

通常、すべての認証リクエストには、アクセスを要求しているアプリケーションを識別するクライアントIDが含まれる。

クライアントIDが登録済みアプリケーションと一致すると、Microsoft Entra IDはサインインログにそのアプリケーション名を記録する。これにより防御側は、特定のアプリケーションを標的とする不審な認証アクティビティを特定するための貴重なコンテキストを得られる。

スプーフィングされたクライアントIDは検知が困難

スプーフィングされたクライアントIDでは、この可視性が失われる。提示されたクライアントIDが正規の登録済みアプリケーションに対応しないため、Microsoft Entraのサインインログではアプリケーション名のフィールドが空欄のままになる。

アプリケーション名に依存して認証の異常を検知したり、特定のクラウドアプリケーションに対する攻撃を特定したりしているセキュリティチームは、このアクティビティを完全に見落とす可能性がある。

Proofpointの研究者はまた、攻撃者がMicrosoft Entra IDの応答の違いを悪用し、提示したクライアントIDが有効かどうか、さらに標的のユーザーアカウントやパスワードが存在するかどうかを判定できることを突き止めた。

脅威アクターはこれらの応答を分析することで、ユーザーを列挙し、認証情報を検証し、組織のクラウドアイデンティティに関する情報を収集できる。しかも、認証成功イベントを発生させたり、防御側が従来監視してきた指標の多くを残したりする必要がない。

Advertisement

この手法は大規模に実行できる

この手法によって、大規模キャンペーンの検知も難しくなる。

攻撃者は、よく知られたMicrosoftアプリケーション数個に認証試行を集中させるのではなく、何千もの架空のクライアントIDにリクエストを分散できる。

これにより認証テレメトリーが分散され、判別しやすい攻撃パターンが目立ちにくくなる。また、特定のアプリケーションを対象範囲とする一部の条件付きアクセス(Conditional Access)ポリシーを回避できる可能性もある。

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スプーフィングが、大規模なクラウドアカウント列挙を可能にするスケーラブルな手法として台頭していることを示している。同時に、認証ベースの攻撃を検知するために防御側が頼る可視性も低下させている。

Advertisement

Microsoft Entra IDでOAuthクライアントIDスプーフィングを検知・緩和する方法

2件のキャンペーンは、インフラ、ユーザーエージェント、クライアントIDの生成方法、列挙パターンが異なっていたが、OAuthクライアントIDスプーフィングが広く採用される偵察手法になりつつあることを示している。

そのため組織は、Microsoft Entra IDを監視する際、認証成功イベントだけに目を向けるべきではない。

  • Microsoft Entraのサインインログでアプリケーション名が空欄になっていないか監視する。OAuthクライアントIDスプーフィングを示している可能性のある、アプリケーションIDの欠落やAADSTS700016エラーコードも確認する。
  • ユーザー間で認証アクティビティを相関分析する。IPアドレス、ユーザーエージェント、認証失敗も相関させ、パスワードスプレーやアカウント列挙キャンペーンを特定する。
  • フィッシング耐性のあるMFA(パスキーやFIDO2セキュリティキーなど)を必須とし、盗まれた認証情報の影響を抑える。
  • 条件付きアクセス(Conditional Access)ポリシーを強化する。アプリケーションベースの制御だけに頼らず、ユーザーリスク、デバイスの健全性、ネットワークの場所、認証強度を評価する。
  • レガシー認証方式を無効にするとともに、可能な限りOAuth Resource Owner Password Credentials(ROPC)を制限する。
  • Microsoft Entra Identity Protection、Defender XDRなどのアイデンティティテレメトリーを継続的に監視し、不審な認証アクティビティの兆候を探す。
  • アイデンティティに重点を置いたインシデント対応計画と検知ワークフローを定期的にテストし、チームがクラウドアカウント列挙の試みを迅速に特定、調査、封じ込められるようにする。

これらの対策を組み合わせることで、組織はクラウドアイデンティティ攻撃に対するレジリエンスを高められる。

結論

クラウドアイデンティティ攻撃が進化を続ける中、セキュリティチームは攻撃者の手法と歩調を合わせて検知戦略も進化させる必要がある。

OAuthクライアントIDスプーフィングは、脅威アクターが偵察段階で自らの活動を見えにくくし、従来型の認証監視だけでは効果が低下していることを示している。

アクセス制御を強化し、影響範囲を縮小するZero Trustソリューション

Ken Underhill

Ken Underhill is an award-winning cybersecurity professional, bestselling author, and seasoned IT professional. He holds a graduate degree in cybersecurity and information assurance from Western Governors University and brings years of hands-on experience to the field.

eSecurity Planet Logo

eSecurity Planet is a leading resource for IT professionals at large enterprises who are actively researching cybersecurity vendors and latest trends. eSecurity Planet focuses on providing instruction for how to approach common security challenges, as well as informational deep-dives about advanced cybersecurity topics.

TechnologyAdvice が所有・運営しています。 © 2026 TechnologyAdvice. 無断転載を禁じます

広告主に関する開示:このサイトに掲載されている製品の一部は、TechnologyAdvice が報酬を受け取っている企業のものです。この報酬は、製品がこのサイトのどこにどのように表示されるか(表示される順序など)に影響する場合があります。TechnologyAdvice は、市場で入手可能なすべての企業やすべての種類の製品を掲載しているわけではありません。