OAuthクライアントIDの偽装で数百万件のMicrosoft Entraアカウントがサイバー攻撃の標的に|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年07月16日更新日時: 2026年07月16日

セキュリティ企業Proofpointは2026年7月13日、Microsoft Entra ID環境を狙う新たな回避技術「OAuthクライアントIDスプーフィング(偽装)」について調査結果を公表しました。この手法を使うと、攻撃者は成功したサインインイベントを一切発生させることなく、有効なアカウントと窃取済みの認証情報を大規模に検証できてしまいます。少なくとも2つの独立した脅威アクターがこの手法を採用していることが確認されており、クラウドの認証監視における業界全体の盲点を示す事例として注目されています。

サマリー

Proofpointは、Microsoft Entra IDが、送信されたOAuthクライアントIDが有効かどうか、また登録済みのアプリケーションに対応しているかどうかによって異なる応答を返すという挙動を悪用し、攻撃者がアカウントを列挙し認証情報の有効性を推測できることを確認した
手口は、Microsoftのアクセストークン発行エンドポイント(/common/oauth2/token)に対し、ユーザー名・パスワードを直接送信できるResource Owner Password Credentials(ROPC)フローを使ってPOSTリクエストを送信するというもの。この際、実在しないクライアントIDを偽装して送信する
応答されるAADSTSエラーコードから、無効なユーザー名(AADSTS50034)、有効なユーザー名だがパスワードが誤り(AADSTS50126)、そしてユーザー名・パスワードの両方が正しいがアプリケーション識別子が認識されない(AADSTS700016)という3パターンを区別できる。最後のケースこそが、成功したサインインイベントを一切発生させずに、有効な認証情報の組み合わせを特定できてしまう核心部分となる
偽装されたクライアントIDを使った場合、サインインログ上でアプリケーション名の欄が空欄のまま記録される。特定のアプリケーション名に対する急増を監視する検知ルールは、この空欄のフィールドを見逃してしまう
Proofpointは、この手法を独自に採用した2つの大規模なキャンペーンを確認している。「UNK_pyreq2323」(2026年1月14日開始)はAWSインフラとPythonツールを用い、Exchange Onlineのアプリケーション識別子の末尾を改変した70万件超の偽装クライアントIDで、約4,000テナントにまたがる100万件超のアカウントを標的にし、失敗試行によって対象ユーザーの約28%がロックアウトされた。「UNK_OutFlareAZ」(2025年12月開始)はCloudflareインフラとOutlook風のUser-Agentを用い、370万件の一意な偽装クライアントIDで200万人超のユーザーを標的にした
両キャンペーンはインフラ・ツール・実行パターンが異なり、それぞれ独立して同じ手法にたどり着いたとみられている。これは、この手法が特殊な例外ではなく、攻撃者の間で標準的な手口として定着しつつあることを示している

項目	内容
公表日	2026年7月13日(Proofpoint)
手法名	OAuthクライアントIDスプーフィング(偽装)
悪用されるエンドポイント	Microsoft OAuth 2.0トークンエンドポイント(/common/oauth2/token)、ROPCフロー
鍵となるエラーコード	AADSTS700016(ユーザー名・パスワードは正しいがアプリ識別子が未認識)
検知を回避する仕組み	偽装クライアントID使用時、サインインログのアプリケーション名欄が空欄化
キャンペーン1	UNK_pyreq2323(2026年1月〜、AWS、70万件超の偽装ID、約4,000テナント、100万件超のアカウント、28%ロックアウト)
キャンペーン2	UNK_OutFlareAZ(2025年12月〜、Cloudflare、370万件の偽装ID、200万人超のユーザー)
独立性	2つのキャンペーンは無関係な攻撃者によるものとみられる

1 何が起きたか-認証エンドポイントの応答の違いを悪用する仕組み
2 2つの独立したサイバー攻撃キャンペーン
3 情報システム部門への示唆
4 出典

何が起きたか-認証エンドポイントの応答の違いを悪用する仕組み

Proofpointの説明によれば、OAuthクライアントIDとは、アプリケーションがユーザーデータへのアクセスを要求する際にMicrosoft Entra IDから割り当てられる、グローバルに一意な識別子(GUID)です。

通常はアプリケーションの認証リクエストに「client_id」というパラメータとして含まれます。今回確認された手法では、攻撃者はこのクライアントIDを実在しない値に偽装したうえで、ユーザー名とパスワードを直接送信できるResource Owner Password Credentials(ROPC)フローを用いて、Microsoftのトークン発行エンドポイントへ認証リクエストを送信します。

この際に返されるAADSTSエラーコードには重要な情報が含まれています。

AADSTS50034は無効なユーザー名を示し、AADSTS50126は有効なユーザー名に対して誤ったパスワードが入力されたことを示します。

そしてAADSTS700016は、アプリケーション識別子が認識されないことを示すエラーですが、これはユーザー名とパスワードの両方が正しい場合にも返されうるものです。つまり、攻撃者はこのエラーコードを受け取ることで、実際にはログインに失敗しているにもかかわらず、その背後にある認証情報の組み合わせが有効であることを確認できてしまいます。

しかも、無効なユーザー名に対するリクエストはそもそもサインインログに記録されないため、有効なアカウントを特定する行為自体がログに残りにくいという性質もあります。

さらに深刻なのは、偽装されたクライアントIDがサインインログに与える影響です。

登録済みの正規アプリケーションを使った認証では、アプリケーションIDとアプリケーション名の両方がログに記録されます。しかし、構文上は正しいものの登録されていないクライアントIDが使われた場合、アプリケーションIDはログに残るもののアプリケーション名の欄は空欄のままになります。クライアントIDの形式自体が不正な場合は、両方のフィールドが空欄になることもあります。特定の名前を持つアプリケーションに対する急増を監視するよう設計された検知ルールは、この空欄のフィールドを対象にできず、活動を見逃してしまう可能性があります。

2つの独立したサイバー攻撃キャンペーン

Proofpointは、この手法を独自に採用した2つの大規模なキャンペーンを確認しています。

1つ目の「UNK_pyreq2323」は2026年1月14日に活動が始まり、AWSインフラ上でpython-requests/2.32.3というUser-Agentを使用しています。

Exchange Onlineの既知のアプリケーション識別子(00000002-0000-0ff1-ce00-000000000000)の先頭部分をそのまま流用し、末尾6桁をランダム化する形で70万件超の偽装クライアントIDを生成していました。1つの偽装IDを最大12人のユーザーに対して使い回すという特徴があり、これによりアプリケーション単位での相関分析を困難にしていたとみられます。このキャンペーンは約4,000のMicrosoft Entraテナントにまたがる100万件超のアカウントを標的にし、大量の失敗試行によって対象ユーザーの約28%が一時的にロックアウトされる事態も引き起こしました。

2つ目の「UNK_OutFlareAZ」は2025年12月に活動が始まり、Cloudflareのインフラを利用し、Outlook風のUser-Agentを使用しています。

UNK_pyreq2323とは対照的に、リクエストごとに一意のクライアントIDを生成する方式を取っており、総数は約370万件にのぼります。ユーザー名の処理順序もアルファベット順で、UNK_pyreq2323の非アルファベット順とは異なるパターンを示しています。このキャンペーンは200万人超のユーザーを標的にしました。両キャンペーンとも、事前にコンパイルされたユーザー名リスト(dsmith、msmith、jbrown等の一般的な名前)を使用するパターンが確認されている一方、インフラ・ツール・実行パターンには明確な違いがあり、無関係な攻撃者がそれぞれ独立してこの手法にたどり着いたとみられています。

Proofpointの脅威調査ディレクターであるYaniv Miron氏は、複数のキャンペーンがこの手法を使用していることは確認できているものの、これらが同一の脅威アクターによるものか、複数の異なるクラスターによるものかは現時点で断定できないとしたうえで、こうした新しい回避手法が一度発見されると、研究者・攻撃者双方のコミュニティに数時間から数日のうちに広く知れ渡るのが通例だと説明しています。

同氏はまた、今回の調査はEntra IDとこの特定の手法に焦点を当てたものだが、根底にある課題は特定のベンダーに限定されるものではなく、他のIDプロバイダー製品にも同様の問題が存在する可能性が高いとして、業界全体の盲点だとの見解を示しています。

情報システム部門への示唆

Proofpointは、Microsoft Entraのサインインログにおいて、アプリケーション名が欠落しているイベントや、想定外のアプリケーションID、アプリケーション情報が完全に欠落しているイベントを監視することを推奨しています。これらは、認証エラーコード・リクエスト量・送信元インフラ・同一ユーザーに対する繰り返しの試行とあわせて確認することが重要です。特にAADSTS700016のエラーについては、単なるアプリケーションの設定不備として片付けるのではなく、有効な認証情報が偽装されたアプリケーションIDとともに送信された可能性を示す兆候として、個別に調査する価値があります。

当サイトで以前紹介したMicrosoft 365環境を標的にした8,100万回超のログイン試行によるパスワードスプレー攻撃でも、ROPCフローを悪用した非対話型ログインが検知回避の鍵になっていることを紹介しましたが、今回の手口も同じROPCフローを土台にしている点で共通しています。対策としても同様に、Conditional Access(条件付きアクセス)ポリシーを「全ユーザー・全クラウドアプリ・全クライアントアプリ種別」を対象にMFA必須または拒否の設定にすること、そして特に強力な設定であるuserStrongAuthClientAuthNRequiredによってROPCフローそのものをブロックすることが、この種の攻撃を根本的に無効化する有効な手段になります。なお、特定のアプリケーションに限定したConditional Accessポリシーだけでは、偽装されたクライアントIDによるリクエストがそのポリシーの対象から外れてしまい、素通りしてしまう可能性がある点に注意が必要です。ポリシーの適用範囲を「All Cloud Apps」ベースで設定できているか、この機会に再点検することをお勧めします。あわせて、フィッシング耐性のある多要素認証の導入と強固なパスワード運用によって、窃取された認証情報自体の価値を下げることも、根本的なリスク低減策として引き続き重要です。