Microsoftのクラウドテナントに対してアカウント列挙攻撃を行う攻撃者が、通常のテレメトリから探索行為を隠す新たな手口を加えています。彼らはOAuthクライアントID——アプリケーションに割り当てられるグローバルに一意な識別子で、認証リクエストでclient_idとして渡される値——を偽装しているのです。Microsoft Entra IDはこの値をサインインログにアプリケーションIDとして記録しますが、未知の識別子に対する処理の仕方に抜け穴があり、攻撃者はそこを突き始めています。
Entraのサインインログは、ユーザー列挙やパスワードスプレー、初期アクセスの試行など、悪意ある認証を検知する上で防御側にとって中心的な役割を担っています。すでに一般的な回避手法として、ユーザーエージェントのローテーションや、リクエストごとに送信元IPを変えるプロキシサービスの利用が挙げられます。クライアントIDの偽装は、こうした手口をさらに拡張するものです。偽装した識別子を使えば、未認証の攻撃者でもアカウントを列挙し、パスワードが正しいかどうかを推測できてしまいます。しかも、成功したサインインイベントを一切生成せずに、です。
手口の仕組み
Proofpointの研究者は、ユーザー名とパスワードを受け付けるResource Owner Password Credentialsフローを使い、MicrosoftのOAuth 2.0トークンエンドポイントにPOSTリクエストを送ることで、この手法をEntra IDに対して再現しました。カスタムのPowerShellモジュールInvoke-ClientIdSpoofEnumを使い、さまざまな種類のクライアントIDを含むリクエストに対してEntraがどう応答するかを記録しました。その応答には情報として意味のある違いがあります。登録済みのアプリケーションであれば、サインインログにアプリケーションIDとアプリケーション名の両方が記入されます。構文的には有効だが該当するアプリケーションが存在しないクライアントIDの場合は、名前フィールドが空欄のままになります。不正な形式の識別子であっても応答自体は返ってきますが、この場合は両方のフィールドが空欄になります。
あるコードは無効なユーザー名を示し、別のコードは有効なユーザー名と誤ったパスワードの組み合わせを示します。そして「認識されないアプリケーション識別子」と読める「AADSTS700016」は、ユーザー名とパスワードの両方が正しい場合に返ってきます。無効なユーザー名のケースはそもそもサインインログに記録すらされません。Entra IDは実在するユーザー名に対する試行のみを記録するためです。この最後のコードを見た攻撃者は、有効な認証情報の組み合わせを確認できたことになりますが、テナント側には成功したサインインの記録が一切残りません。
空欄のフィールドが重要な理由
クライアントIDを偽装すると、ログ上でアプリケーション名の欄が空欄になります。特定の名前を持つアプリケーションへの急増を監視するよう調整された検知ルールは、この活動を完全に見逃してしまう可能性があります。キーとなるフィールドに何も値が入っていないためです。たとえ列挙行為自体が検知されたとしても、サインインイベントが存在しないことで、有効な認証情報が見つかったことに防御側が気づかず、侵害されたアカウントが見過ごされる恐れがあります。
従来の列挙ツールは、Azure AD PowerShellのようなCLIユーティリティなど、あらゆるテナントに存在するハードコードされたファーストパーティアプリケーションを狙うのが一般的でした。こうした特定のアプリケーションへのアクセス急増があれば、通常はSOCにアラートが上がります。しかし、数千もの架空のアプリケーションに試行を分散させれば、シグナルが分散して個々のアプリケーション単位の検知が弱まり、単一アプリにひもづくレート制限もすり抜けてしまいます。特定のアプリケーションを対象とした条件付きアクセスポリシーも、偽装されたクライアントIDはどのポリシー範囲にも一致しないため、適用されずに終わります。
「偽装したフィールドを使う手法自体は、何年も前から知られている技術です。攻撃者にとっての課題は、どのフィールドが偽装可能かを特定すること、それも理想を言えば防御側に気づかれる前に、です。アンダーグラウンドフォーラムでは、偽装や悪用が可能なフィールドについての議論が常に行われており、攻撃者はそうした発見をすぐさま活用します」と、Proofpointの脅威リサーチ担当ディレクターであるYaniv Miron氏はHelp Net Securityに語りました。
2つのキャンペーン、2つのツールセット
Proofpointは、UNK_pyreq2323として追跡している1つのキャンペーンを確認しました。これは2026年1月14日に姿を現し、AWSインフラ上でユーザーエージェント「python-requests/2.32.3」を使って動いていました。この攻撃者は、Exchange Onlineアプリケーションのプレフィックスを利用し、末尾の6桁をランダム化する形で作成した70万件を超える偽装クライアントIDを使い、列挙を分散させていました。このキャンペーンは約4,000のテナントにわたり100万を超えるユーザーアカウントに到達し、失敗した試行の量によって、影響を受けたユーザーの約28%がロックアウトされる事態になりました。
2つ目のキャンペーン、UNK_OutFlareAZは2025年12月に始まり、主にCloudflareのインフラ上で動作し、12月下旬と3月15日の2度にわたってピークを迎える2つの波を経て推移しました。このキャンペーンは200万を超えるユーザーに到達し、370万件の偽装アプリケーションIDを使用していました。それぞれがリクエストごとに生成される完全にランダムなUUIDv4であり、相関分析を困難にする、より洗練された手口だと言えます。ユーザー名はアルファベット順に進んでおり、dsmith、msmith、jbrownといった汎用的なアカウント名が複数のテナントにまたがって繰り返し登場していたことから、共有されたワードリストが使われていたことがうかがえます。
ホスティング環境、クライアントIDの生成方法、列挙の順序といった点で両者には違いが見られ、これは別々のツールないし攻撃者がそれぞれ独自に同じ手法にたどり着いたことを示唆しています。
「私たちはこの手法を用いた複数のキャンペーンを確認していますが、現時点では、これらの活動が同一の脅威アクターによるものなのか、それとも異なる脅威アクターの集団によって行われているものなのかを確認することはできません。ハッカーフォーラムでの議論と、攻撃者自身による試行錯誤の実験が組み合わさった結果である可能性が高いでしょう」とMiron氏は述べています。こうした手法がどれほど速く広まるかについて、同氏は「新たな偽装手法が公表されると——それが研究者によるものであれ、脅威アクターによるものであれ——通常は数時間から数日のうちに両方のコミュニティに広く知れ渡ります」と付け加えました。
一つのベンダーにとどまらない問題
「これは業界全体に及ぶ死角だと私たちは見ています。私たちの調査はEntra IDとこの特定の手法に焦点を当てていますが、根本的な課題は単一のベンダーに限った話ではありません。具体的なフィールドや実装の詳細は異なるでしょうが、同様の問題は他のIDプロバイダーのプラットフォームにも存在する可能性が高いのです」とMiron氏は語ります。
成功した認証イベントは、これまで長らく、認証情報が有効かどうかを判断する信頼できる根拠とされてきました。しかし、この手法はその土台を揺るがします。Miron氏は今回の調査から得られる教訓を次のようにまとめています。「総じて、この調査が示すのは重要な点です。成功したサインインイベントは、もはや認証情報が侵害されたかどうかを判断する上で、決定的な根拠として扱うべきではありません」。
アプリケーションIDが空欄になっているサインインの記録や、アプリケーションIDはあるのに該当する名前が伴っていない記録は、クライアントID偽装の兆候である可能性があるものとして、あらためて注視する価値があります。この点を見直す上で、AADSTS700016というエラーコードもそれ自体が重要な意味を持ちます。それは攻撃者が有効なユーザー名とパスワードの組み合わせを確認したばかりであることを意味しつつ、ログには成功したサインインの記録が一切残っていない可能性があるからです。
翻訳元: https://www.helpnetsecurity.com/2026/07/13/entra-id-oauth-client-id-spoofing/
