Azure Entra ID 連續四次登入記錄繞過：讀完這篇才知道問題有多大

本篇文章更新時間：2026/03/21
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。

Azure Entra ID 四大登入紀錄繞過事件：三年來微軟最不想談的漏洞、以及我們該如何自保

編輯前言：這篇文章源自 Full Disclosure: A Third (and Fourth) Azure Sign-In Log Bypass Found，作者 Nyxgeek 在三年內找到四個 Azure Entra ID「登入記錄繞過」漏洞。這些問題已被修補，但內容值得每位雲端或資安人員深讀。

核心觀點 (Key Takeaways)

• 四個登入記錄繞過（GraphNinja、GraphGhost、GraphGoblin、Graph）皆能在不同程度上驗證密碼或取得 token，而不留下登入記錄。
• GraphGoblin 與 Graph 更嚴重：不只繞過記錄，還能直接取得完整 token。
• 問題源自多個登入欄位未妥善處理長字串（scope、user-agent），疑似造成資料庫欄位溢位而導致記錄無法寫入。
• 微軟 MSRC 對此類漏洞的評級與獎勵政策高度不一致，有些給 bounty、有些完全不承認嚴重性。
• 管理者可以利用 KQL，透過比對 Graph Activity Logs 與 Sign-In Logs 的 Session ID 來補捉被繞過的事件（但需 E5 授權）。

深入解析

Nyxgeek 在 2023–2025 接連找到四個 Azure Entra ID 的登入記錄繞過方式，且都不屬於複雜攻擊。反而像是開發階段典型的輸入檢核疏忽，甚至類似 SQL 欄位長度沒設好就上線的錯誤。

以下是文章中最具代表性的觀察：

1. GraphNinja 與 GraphGhost：早期兩個繞過，能「驗證密碼」卻不留記錄

• GraphNinja：把登入送到別的 tenant，但仍可得知密碼是否正確。
• GraphGhost：送出錯誤的 Client ID，整體登入流程會在密碼驗證後失敗，因此不會記錄成功登入。

雖然沒有 token，但都能讓攻擊者進行「無影密碼噴灑」攻擊。微軟後來補上了更細緻的登入記錄資訊才修補問題。

2. GraphGoblin：重複 10,000 次 openid scope 竟可繞過記錄並取得 token

這是最讓我震驚的部分。作者發現只要把 scope 填成：

openid openid openid …（重複數千次）

Azure 會：

• 接受登入
• 發給你功能完整的 Graph token
• 卻完全「不寫入登入記錄」

作者推測原因可能是登入記錄寫入時，因 scope 字串過長導致 SQL 欄位溢位而寫入失敗。這種 bug 在現代雲端平台發生，坦白說相當不可思議。

3. Graph**：用超長 user-agent（50,000 字元）就能神隱登入記錄

這個 bypass 更直覺：

把 user-agent 填到五萬字元，就能讓登入記錄消失。

沒有複雜的 exploit，沒有 protocol trick，就是單純的字串過長。

更令人意外的是，微軟在作者提交前就偷偷修掉了這個 bug。

4. 微軟 MSRC 的反應極不一致

文章最令人感到無力的地方，就是 MSRC（Microsoft Security Response Center）對這些漏洞的態度：

• GraphNinja：給 bounty
• GraphGhost：給 bounty
• GraphGoblin：不給，理由是「不重要」
• Graph：修掉但不認帳，也沒有給任何獎勵

作者計算 CVSS 分數，認為這類問題應屬「高風險」，因為它破壞的是 Azure 最關鍵的安全記錄鏈。微軟卻反向認定為「Moderate」。

作者一句總結了管理員最該讀的重點：

微軟視 Entra ID sign-in logs 的漏洞為非重大，這是所有依賴 Azure 的企業都應看到的態度。

筆者心得與啟發

讀完這篇，我最大的感受是：

Azure Entra ID sign-in logs 這個「全世界雲端安全的核心資料來源」竟然能被四種簡單方式繞過，三年內連發四件，實在不合理。

如果今天是 JWT 驗證或 token 簽章出問題，我反而比較能理解，因為那是複雜邏輯。但 scope、user-agent 長度造成記錄無法寫入？這種錯誤本應該在自動化 fuzzing 與基本 QA 測試就能擋下。

從管理者角度，我會建議：

• 如果組織能負擔，務必啟用 E5 來收集 Microsoft Graph Activity Logs。
• 不要再把 Entra ID sign-in logs 當唯一的 source of truth。
• 建立 KQL 偵測，定期比對 Session ID 是否有「只有 Graph logs 有，而 sign-in logs 沒記錄」的情況。
• 若你的 SIEM 依賴這些記錄做 anomaly detection，務必重新評估模型假設。

更重要的是，這篇文章提醒了我們：

雲端平台並非天生安全，尤其當平台本身的日誌寫入都有可能失效。

當核心安全紀錄都可能被簡單參數搞壞，我們應該重新思考：

• 雲端的安全邊界在哪？
• 什麼資料要自己另做記錄與備援？
• 微軟對重大安全事件的透明度與一致性是否值得依賴？

這四個漏洞已經被修補，但文章提出的問題——微軟的測試流程、資安文化、以及官方對漏洞評等的態度——值得每一位 IT 管理者繼續追問。

---