Microsoft Entra IDの監視をすり抜ける新手法「OAuthクライアントID偽装」が判明、攻撃者グループが大規模に悪用

要点

• Microsoft Entra ID環境において、認証の成功ログを記録させずに資格情報の有効性を検証できる「OAuthクライアントIDスプーフィング（偽装）」と呼ばれる新たな回避手法が判明しました。
• Entra IDが送信されたクライアントIDの有効性に応じて異なるエラー応答を返す仕様を利用し、攻撃者はアカウントの有無やパスワードの正当性を推測しています。
• セキュリティ企業のProofpointにより、2025年12月以降にこの手法を用いた2つの独立した大規模な攻撃キャンペーンが並行して実行されていることが確認されました。
• 標的となったアカウントは合計で300万を超えており、AWSやCloudflareなどのクラウドインフラが悪用されています。

リード文

米セキュリティ企業のProofpointは、Microsoft Entra ID（クラウドベースのID・アクセス管理サービス）の監視をすり抜け、盗まれた資格情報の検証やアカウントの列挙を行う新しい回避手法「OAuthクライアントIDスプーフィング（偽装）」が、複数の攻撃者グループによって悪用されていることを明らかにしました。この手法は2025年12月末頃から確認されており、セキュリティ監視の死角を突いて組織のクラウド環境へ侵入を試みる手段として広がっています。

新たな回避手法「OAuthクライアントIDスプーフィング」の仕組み

通常、管理者はEntra IDのサインインログを主な情報源として不正アクセスを特定しますが、今回の手法はこの監視体制の「死角」を突くものです。

OAuthクライアントIDは、アプリ登録時に割り当てられる一意の識別子（GUID）で、認証時に「client_id」として送信されます。攻撃者は、HTTP POSTリクエストでMicrosoftのOAuth 2.0トークンエンドポイントに対し、ROPC（Resource Owner Password Credentials、ユーザーのIDとパスワードをアプリが直接受け取る認証フロー）を用いて接続します。その際、実在しない偽のクライアントIDを送信します。

Entra IDは、送信されたIDの有効性に応じて異なるエラー応答（AADSTSエラーコード）を返します。IDの形式が標準的なUUIDv4（一意の識別子の規格）でなくても即座に要求を拒否せずエラーを返すため、攻撃者はその応答の差異からアカウントの有無やパスワードの正当性を推測し、サインイン成功ログを生成せずに資格情報を検証できます。

監視ログに残らない空白のアプリケーション名

この手法の最も厄介な点は、防御側が異常を検知しにくいことです。偽装されたクライアントIDが使用された場合、Entra ID of サインインログにはアプリケーションIDこそ記録されるものの、それに対応する「アプリケーション名」の欄が空白になります。

通常のセキュリティ対策では、特定のアプリケーションに対するアクセス要求の急増を検知するルールが敷かれていることが多いですが、アプリケーション名が空欄になっているとこのフィルタリングルールに引っかからず、検知システムを完全にすり抜けてしまいます。その結果、攻撃者は成功ログを一切残すことなく、盗んだ認証情報リストの妥当性をチェックできるため、防御側が疑わしいアクティビティを特定することが極めて困難になります。

2つの大規模攻撃キャンペーンの存在

Proofpointの分析によると、2025年12月末のほぼ同時期に、互いに関連性のない2つの攻撃グループが独立してこの手法を採用したことが分かっています。これは、このアプローチが単なる孤立したインシデントではなく、攻撃手法の一部として組み込まれつつあることを示しています。

1. 「UNK_pyreq2323」による攻撃

2026年1月から3月にかけて観測されたキャンペーンで、Amazon Web Services（AWS）のインフラを足がかりに実行されました。

• 規模: 約4,000のテナント（組織単位）における100万件以上のアカウントが標的となりました。
• 特徴: 既存のアプリIDの末尾数桁を改ざんする形でIDを偽装していました。1つの偽装IDを最大12人のユーザーに対して使い回しており、失敗した試行によって標的ユーザーの約28%がアカウントロックアウトに追い込まれました。

2. 「UNK_OutFlareAZ」による攻撃

2025年12月に開始されたキャンペーンで、Cloudflareのインフラが悪用されました。

• 規模: 200万人以上のユーザーを標的とし、370万件ものランダムに偽装されたアプリケーションIDが使用されました。
• 特徴: リクエストごとに毎回新しい固有のクライアントIDを生成して送信していました。ユーザーの列挙をアルファベット順に実行していたことも特徴です。

両キャンペーンともに、構文として有効な形式のUUIDを使用しており、あらかじめ用意されたユーザー名リスト（ワードリスト）をベースに攻撃を行っていた形跡があります。

過去の手法からの進化

OAuthクライアントIDを悪用したパスワードスプレー攻撃としては、過去に「UNK_CustomCloak」と呼ばれる攻撃グループが、すでに提供終了となっているレガシーなファーストパーティアプリケーション「Windows Live Custom Domains」を悪用して標準的なサインイン制限を回避し、4,000以上のテナントを標的にした事例が確認されています。
今回の手法は、この過去の技術を進化させ、実在する登録アプリケーションを介すことすら必要とせず、よりステルス性を高めたものとなっています。