主なポイント
- プルーフポイントは、OAuthクライアントIDスプーフィングが新たな手法として登場し、クラウドを狙ったキャンペーンで利用が拡大していることを確認しました。
- Microsoft Entra IDは、送信されたOAuthクライアントIDが有効であるかどうか、また登録済みアプリケーションに対応しているかどうかに応じて、異なる応答を返します。
- この挙動により、登録済みのOAuthアプリケーションがなくてもアカウントの列挙が可能となり、攻撃者はサインイン成功イベントを発生させることなくパスワードの有効性やアカウントの状態を推測できます。
- リサーチャーは、偽装されたOAuthアプリケーション識別子を悪用する複数のキャンペーンを大規模に確認しました。それぞれ異なるツール、インフラ、実行パターンを持っており、複数の脅威アクターが独自に本手法を採用していることを示しています。
- 同様の活動を検知するために、防御側はサインインログでアプリケーション名が記録されていないイベントを監視すべきです。これは偽装されたクライアントIDを示している可能性があります。
はじめに
攻撃者が、サインイン成功イベントを一切発生させることなく、組織全体のアカウントを列挙できるとしたらどうでしょうか。
Entraのサインインログは、ユーザー列挙、パスワードスプレー、初期アクセスの試行など、悪意のある認証アクティビティを特定するための主要なテレメトリソースです。検知を回避するために、攻撃者は日常的に、ユーザーエージェントをローテーションさせたり（UNK_CustomCloakで確認されたとおり）、リクエストごとに送信元IPを切り替えるプロキシサービスを利用したりして、リクエストを分散させています。
プルーフポイントのリサーチャーは、攻撃者がこの回避的な手口をさらに発展させ、OAuthクライアントID（アプリケーションID）を偽装している複数のキャンペーンを確認しました。これはアプリケーションに割り当てられるグローバルに一意な識別子（GUID）です。この識別子は認証リクエストでclient_idとして渡され、EntraのサインインログにアプリケーションIDとして記録されます。
偽装されたクライアントIDにより、登録済みのOAuthアプリケーションがなくてもアカウントの列挙が可能となり、攻撃者はサインイン成功イベントを発生させることなく、パスワードとアカウントの両方の有効性を推測できます。
クライアントIDスプーフィングのシミュレーション
クライアントIDスプーフィングが実際にどのように機能するかを理解するため、私たちはEntra IDに対してこの手法をシミュレーションしました。
クライアントIDスプーフィングは、MicrosoftのOAuth 2.0トークンエンドポイント（/common/oauth2/token）に対して、ユーザー名とパスワードの資格情報を直接送信できるリソースオーナーパスワードクレデンシャル（ROPC）フローを用いてPOSTリクエストを発行することで実行しました。
図1：クライアントIDパラメータを含むROPCリクエスト
返されるAADSTSエラーコードにより、認証されていないリクエスト送信者でも、ユーザー名とパスワードの有効性、さらには多要素認証（MFA）や条件付きアクセス（CA）といった制御が適用されているかどうかを推測できます。
Entra IDがclient_id値を含むリクエストに対してどのように応答し、記録するかを観察するため、以下のシナリオを対象としたカスタムPowerShellモジュール（Invoke-ClientIdSpoofEnum）を開発しました。
- 登録済みアプリケーションに紐づく有効なクライアントID
- 未登録アプリケーションに紐づく有効なクライアントID
- 有効な構造を持つランダム生成のUUID
- 無効なクライアントID
有効なクライアントID＋登録済みアプリケーション
有効なclient_idが登録済みアプリケーションに対応している場合、Entraはリクエストを想定どおりに処理し、サインインログにはアプリケーションIDとアプリケーション名の両方が記録されます。
図2：登録済みアプリケーションIDのサインインログエントリ
有効なクライアントID＋未登録アプリケーション
送信されたclient_idが構文的には有効であるものの、実在するアプリケーションに対応していない場合、サインインログにはアプリケーションIDのみが記録され、対応するアプリケーション名は記録されません。
図3：偽装されたアプリケーションIDではアプリケーション名が記録されない様子
この応答は、登録済みアプリケーションがなくても、アカウントが存在するかどうか、およびパスワードが正しいかどうかを推測するために利用できます。
ユーザー名が無効な場合はAADSTS50034が返されます。Entra IDは有効なユーザー名に対するサインイン試行のみを記録するため、このイベントはサインインログに記録されません。
図4：ユーザーが無効で、クライアントIDが登録済みアプリケーションに対応しないランダム生成のUUIDv4文字列である場合の応答を示すカスタムツールInvoke-ClientIdSpoofEnum
ユーザー名が有効でパスワードが無効な場合はAADSTS50126が返されます。
図5：ユーザーが有効でパスワードが無効な場合の応答を示すカスタムツールInvoke-ClientIdSpoofEnum
注目すべき点として、ユーザー名とパスワードの両方が有効な場合にはAADSTS700016（アプリケーション識別子が認識されない）が返されます。したがって、偽装されたアプリ識別子を使用することで、サインイン成功の記録を残すことなく、有効なユーザー名とパスワードの組み合わせを列挙できてしまいます。
図6：有効なユーザー名とパスワードに対するInvoke-ClientIdSpoofEnumの実行結果
無効なクライアントID
偽装されたクライアントIDが正規のUUIDv4でない場合でも、Entraはリクエストを即座に拒否するわけではありません。代わりに、サインインログにアプリケーションIDやアプリケーション名を記録しないまま、AADSTSエラーを返します。
そのため攻撃者は、不正な形式のクライアントIDを使用していても、このエラー応答を分析することで有効なアカウントとパスワードを特定できます。
図7：無効なUUIDv4クライアントIDではアプリケーション名とアプリケーションIDが記録されない様子
攻撃者はなぜクライアントIDを偽装するのか
偽装されたクライアントIDが使用されると、サインインログには対応するアプリケーション名が記録されません。つまり、特定のアプリケーション名に対する急増を検知しようとする仕組みでは、このフィールドが空欄であるためにこの活動をまったく見逃してしまう可能性があります。
確認されたログ記録の挙動により、認証されていない攻撃者でも、サインイン成功イベントを発生させることなくユーザーを列挙し、パスワードの有効性を推測できます。列挙が検知された場合であっても、防御側は有効な資格情報が特定されたことに気づかず、侵害された資格情報を完全に見落としてしまうおそれがあります。
従来の列挙ツールは、ハードコードされたファーストパーティアプリケーション、一般的にはAzure AD PowerShellのようなCLIツールを標的としています。これらはすべてのテナントに存在し、これまでMFA適用の抜け穴となってきました。しかし、単一のアプリケーションに対する認証リクエストの急増は、SOCチームの警戒をすぐに招きます。認証試行を多数の架空のアプリケーションに分散させることで、活動の相関分析が難しくなり、アプリケーション単位の検知やレート制限を回避できる可能性があります。
組織は、列挙の標的になりやすいアプリケーションを対象範囲とした条件付きアクセスポリシーを適用することで、従来の列挙攻撃を緩和しようとする場合があります。しかし、偽装されたクライアントIDは、特定のアプリケーションを対象範囲としたCAポリシーを発動させません。
UNK_PyReq2323
プルーフポイントがUNK_pyreq2323として追跡しているキャンペーンは、2026年1月14日に初めて確認されました。攻撃者は、70万を超える偽装クライアントIDに列挙の試行を分散させていました。
確認された認証リクエストは、以下のユーザーエージェントからのものでした。
python-requests/2.32.3
活動は1月下旬から2月上旬にかけてピークを迎え、3月上旬までに減少しました。このキャンペーンはAWSのインフラを起点としており、約4,000のテナントにまたがる100万を超える固有のユーザーアカウントを標的としていました。この大量の失敗試行により、標的となったユーザーの約28％でアカウントロックアウトが発生しました。
図8：UNK_pyreq2323のタイムライン
クライアントIDスプーフィングの詳細
クライアントIDを偽装する手法は単純なもので、アプリケーション「Exchange Online」のプレフィックスを使用していました。
00000002-0000-0ff1-ce00-000000000000
この脅威アクターは、IDを連番で列挙するのではなく、識別子の末尾6桁をランダム化していました。その結果、偽装されたIDは最大12ユーザーに対して使用され、同一ユーザーに対して再利用されることはありませんでした。
以下の表は、確認されたクライアントIDの一部であり、値の小さい3件と大きい3件を含んでいます。各クライアントIDに紐づくタイムスタンプを分析したところ、昇順や降順のパターンは見られず、連番で生成されたものではなくランダムであることが裏付けられました。
|
00000002-0000-0ff1-ce00-000000100001 |
|
00000002-0000-0ff1-ce00-000000100003 |
|
00000002-0000-0ff1-ce00-000000100005 |
|
00000002-0000-0ff1-ce00-000000425603 |
|
00000002-0000-0ff1-ce00-000000544540 |
|
00000002-0000-0ff1-ce00-000000645372 |
|
00000002-0000-0ff1-ce00-000000999997 |
|
00000002-0000-0ff1-ce00-000000999998 |
|
00000002-0000-0ff1-ce00-000000999999 |
図9：偽装アプリIDの大半は1～3ユーザーに使用され、最大でも12ユーザー
UNK_OutFlareAZ（2025年12月）
2025年12月以降、プルーフポイントのリサーチャーは、主にCloudflareのインフラを起点とするUNK_OutFlareAZとして追跡している大規模な列挙キャンペーンを確認しました。この活動は同じクライアントIDスプーフィング手法を用いていましたが、より大規模に展開されており、200万を超えるユーザーと370万件の偽装アプリケーションIDを標的としていました。
確認された認証リクエストは、以下のユーザーエージェントからのものでした。
Microsoft Office/16.0 (Windows NT 10.0; Microsoft Outlook 16.0.12026; Pro.
プルーフポイントは、このユーザーエージェントを数年にわたり複数の列挙キャンペーンで一貫して確認しており、攻撃者のツールを通じて広く普及しています。
このキャンペーンは2つの明確な波に分かれて発生しました。第1波は12月10日から拡大し、12月下旬にピークを迎えました（約24万2,000ユーザー）。第2波はより大規模で、2月上旬に始まり、3月を通じて拡大し、3月15日にピークに達しました（約72万ユーザー）。
ユーザー名のかなりの部分が複数のテナントにまたがって出現しており、dsmith、msmith、jbrownといった一般的な命名規則に従っていました。Entra IDは有効なアカウントに対する試行のみを記録するため、このパターンは、攻撃者が一般的なユーザー名からなる共通のワードリストを多数の組織に対して使い回していたことを示唆しています。
クライアントIDスプーフィングの詳細
UNK_OutFlareAZで用いられた偽装手法は、UNK_pyreq2323と比較してより成熟したものでした。この脅威アクターは、既知のファーストパーティアプリケーション識別子の末尾の桁をランダム化するのではなく、完全にランダム化されたUUIDv4を生成し、認証試行ごとに固有のクライアントIDを使用していました。
偽装アプリIDの例：
|
f9bae775-ef31-44c0-ad33-f50f62b3aba8 |
|
89274bc8-5605-4639-b850-1d5fc2de4bad |
|
ad48e616-54a3-4c53-b7f7-605d493d54ba |
|
2e2fa57b-e41e-40e6-b2d6-5aa448cef563 |
|
574f120a-5094-4f2d-930a-9e926221f0f2 |
|
fff3c7ac-36d1-46b8-80a9-212095b76264 |
キャンペーンの比較
どちらのキャンペーンもユーザー列挙のためにOAuthクライアントIDスプーフィングを利用していましたが、ユーザーエージェント、インフラ、クライアントIDの生成方法、列挙パターンに違いが見られることから、異なるツールまたは異なる実行者によって行われたと考えられます。
両キャンペーンとも、不正な形式の識別子ではなく有効なUUIDを使用しており、事前に用意されたユーザー名のワードリストと整合するパターンを示していました。ただし、UNK_OutFlareAZはユーザーをアルファベット順に列挙していたのに対し、UNK_pyreq2323はそうではありませんでした。
クライアントIDの偽装手法も異なっていました。UNK_pyreq2323は既知のアプリケーションIDの末尾の桁を変更し、偽装IDを最大12ユーザーにわたって再利用していました。一方UNK_OutFlareAZはリクエストごとに固有のクライアントIDを生成しており、相関分析を困難にするより高度な手法でした。
これらの違いは、同一の基盤技術が独自に採用されていることを示しており、OAuthクライアントIDスプーフィングが脅威アクターの間でますます一般的な手口になりつつあるというプルーフポイントの評価を裏付けています。
キャンペーンの比較表
|
追跡名 |
UNK_pyreq2323 |
UNK_OutFlareAZ |
|
ユーザーエージェント |
python-requests/2.32.3 |
Microsoft Office/16.0 (Windows NT 10.0; Microsoft Outlook 16.0.12026; Pro |
|
インフラ |
AWS |
Cloudflareおよびその他 |
|
アプリID生成方法 |
00000002-0000-0ff1-ce00-000000XXXXXX |
完全ランダムなUUID v4 |
|
再利用 |
1IDあたり最大12ユーザー |
1IDあたり最大1ユーザー |
|
列挙のスタイル |
アルファベット順ではない |
アルファベット順 |
|
キャンペーン期間 |
2026年1月～3月 |
2025年12月 2026年2月～3月 |
|
推定されるツール |
Pythonベース |
ユーザーエージェントから見て既存ツールからの派生の可能性 |
まとめ
OAuthクライアントIDスプーフィングにより、攻撃者はEntra IDのログにサインイン成功イベントを発生させることなく、大規模にアカウントを列挙し、資格情報を検証できます。固有のツールとインフラを持つ複数のキャンペーンが出現していることは、この手法がクラウド環境を標的とする脅威アクターの間で広がりつつあることを示唆しています。
サインインのテレメトリを回避できることに加えて、偽装されたクライアントIDには、見かけ上複数のアプリケーションに攻撃を分散できることや、アプリケーション名フィールドが埋まっていることを前提とする下流の検知を回避できる可能性といった、さらなる利点があります。
防御側は、アプリケーションIDが空欄のサインインログエントリ、または対応するアプリケーション名がないエントリを、クライアントIDスプーフィングの潜在的な兆候として扱うべきです。また、AADSTS700016エラーコードが単なるログイン失敗ではなく、資格情報の侵害を示している可能性があることを認識する必要があります。
本ブログは英語ブログ「OAuth Client ID Spoofing: Why Fake Client IDs Are Gaining Traction for Stealthy Enumeration」の日本語訳です。英語原文との間で内容に齟齬がある場合には、英語原文が優先します。