在雲端身分驗證的防禦體系中，登入日誌（Sign-in Logs）是安全工程師判斷是否遭受攻擊的最重要依據。然而，近期發現的一種名為 OAuth Client ID Spoofing（OAuth 客戶端 ID 偽造）的技術，讓攻擊者能夠在不觸發成功登入警報的情況下，大規模驗證盜取的帳號密碼是否正確。
首先我們需要理解 OAuth Client ID 的角色。在 Microsoft Entra ID（原 Azure AD）的生態系中，每當一個應用程式想要請求存取使用者資料時，系統會分配一個全球唯一識別碼（GUID），即 Client ID。當應用程式發起驗證請求時，必須在請求中攜帶這個 ID，讓系統知道是哪個應用程式在請求權限。
這項攻擊的核心在於利用了 Entra ID 在處理錯誤回應時的邏輯差異。攻擊者使用了 ROPC（Resource Owner Password Credentials）流程，這是一種允許使用者直接將帳號密碼交給應用程式來換取 Token 的舊式驗證方式。
攻擊者的操作手法是發送 HTTP POST 請求到 Microsoft 的 Token 端點，但在 client_id 欄位中填入一個偽造的、不存在的 ID。關鍵在於，即使這個 ID 是偽造的，Entra ID 回傳的錯誤代碼（AADSTS Error Code）會根據帳號密碼是否正確而有所不同。
對 junior 工程師來說，這就像是在嘗試進入一棟大樓，雖然你拿著一張偽造的員工識別證（Client ID），大樓保安雖然會攔住你不讓你進去，但他拒絕你的理由卻出賣了資訊。如果他說帳號不存在，你就知道這個 Email 是錯的；如果他說密碼錯誤，你就知道帳號是對的但密碼錯了；而如果他回傳的是關於應用程式權限的錯誤，則代表帳號與密碼全部正確。
這種攻擊方式對防禦方造成了極大的威脅，主要原因有三點。
第一是監控盲點。在正常的登入日誌中，系統會記錄應用程式名稱。但當使用偽造的 Client ID 時，日誌中只會留下一個 ID 字串，應用程式名稱欄位則是空白。許多安全監控規則（Detection Rules）是設定在監控特定應用程式的異常登入量，當名稱為空時，這些規則會直接失效。
第二是規避條件式存取（Conditional Access）。企業通常會針對高風險應用程式設定條件式存取策略（例如必須開啟 MFA）。但由於攻擊者使用的是偽造 ID，這些請求不會觸發任何針對特定應用程式設定的 CA 策略，讓攻擊者能悄悄地進行帳號枚舉（Account Enumeration）與密碼噴灑（Password Spraying）。
第三是分散化攻擊。觀察到的攻擊組織如 UNK_pyreq2323 與 UNK_OutFlareAZ，會為每次請求或每組使用者隨機生成不同的偽造 ID。這種做法將攻擊流量碎片化，讓防禦系統難以將這些請求關聯為同一次攻擊，進而繞過針對單一應用程式的頻率限制（Rate Limiting）。
實務上，這種技術讓攻擊者能在不產生任何成功登入紀錄的情況下，將手中盜取的憑證清單過濾出真正有效的帳號。一旦確認帳號密碼正確，攻擊者就能選擇在最有利的時間點，以更隱蔽的方式正式進入企業雲端環境。
面對此類威脅，安全團隊不能僅依賴應用程式名稱的監控，而應將關注點移至 AADSTS 錯誤代碼的分佈異常，以及日誌中出現大量缺乏應用程式名稱的驗證請求，這才是識別此類偽造攻擊的關鍵指標。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。