微軟Azure的安全性就是一沱💩
完整揭露：發現第 3、4 個 Azure Entra ID 登入記錄繞過漏洞 https://trustedsec.com/blog/full-disclosure-a-third-and-fourth-azure-sign-in-log-bypass-found
資安研究者 nyxgeek 揭露他在近三年內找到的第 3、4 個 Azure Entra ID（微軟的雲端身分與存取管理，前身為 Azure AD）「登入記錄繞過」漏洞：攻擊者只要對 login.microsoftonline.com 的驗證端點送出特製的登入請求，就可能在不留下 Entra ID sign-in logs（登入記錄）的情況下通過密碼驗證，甚至直接取得可用的權杖（token，例如 access token），讓密碼噴灑（password spray，對大量帳號以少量常見密碼嘗試登入）與隱形登入更難被偵測。這類登入記錄是許多組織用來偵測入侵、餵給 SIEM（Security Information and Event Management，資安事件與記錄管理平台）的關鍵依據；作者也質疑，當記錄品質與授權分級（例如進階記錄需額外付費）交織時，管理者對「記錄即真相」的信任正在被掏空。
文章回顧先前兩個繞過：GraphNinja 是把 OAuth 2.0 ROPC（Resource Owner Password Credentials，直接用帳號密碼換取權杖的流程）請求送到「非目標租戶」的 tenant 端點，藉此得知密碼是否正確，卻不會在真正租戶留下成功或失敗記錄；GraphGhost 則是用不合法的 client_id 讓流程在「密碼已驗證後」才失敗，管理者只看到失敗登入，卻不知道密碼其實已被猜中。新的 GraphGoblin 更嚴重：把 scope 參數塞入大量重複的合法值（例如 openid 重複數萬次），仍可拿到權杖，但登入記錄完全不會出現；作者推測是記錄寫入時把超長 scope 原樣寫進資料庫，觸發 SQL 欄位長度溢位導致 INSERT 失敗，整筆登入記錄被丟棄。第 4 個「Graph******」繞過同樣直白：把 User-Agent 字串拉到約 50,000 個字元，也能穩定讓登入記錄消失並取得權杖。作者提供了以 curl 一行指令即可重現的示範，並因微軟一開始難以重現而錄製影片佐證；時間線顯示其中一個繞過在他正式回報前就被微軟修掉，另一個則在提供影片後約兩週內完成修補。
面對「登入記錄可能不可靠」，作者提出較具延展性的偵測法：在 Azure Log Analytics 以 KQL（Kusto Query Language，Azure 記錄分析的查詢語言）比對 MicrosoftGraphActivityLogs（Microsoft Graph 活動記錄）與多種登入來源記錄（互動、非互動、服務主體、受控身分等），找出「有 Graph 活動、卻找不到對應登入記錄」的工作階段（以 SessionId 或更細的對照欄位 JOIN），並用告警規則通知；但他也提醒，收集 Graph 活動記錄通常需要 Microsoft 365 E5 這類高階授權。作者同時抨擊 MSRC（Microsoft Security Response Center，微軟安全回應中心）把此案評為 Moderate 而非 Important，拒絕給獎金或致謝；他以 CVSS（Common Vulnerability Scoring System，通用弱點評分系統）論證這是對關鍵稽核記錄「完整性」的重大破壞（v3.1 約 7.5、v4.0 約 8.7），並指出微軟雖口頭淡化，實際修補速度卻異常快，凸顯嚴重度評估與修補行動之間的落差。
Hacker News 討論多半把此事視為 Azure／Entra「記錄不可信」問題的又一例：有人分享在 Azure 入口網站刪除 client secret 時，因頁面過久未更新導致 API 以「覆寫整組 secrets」方式提交，最後多刪了一把金鑰，稽核記錄卻顯示是操作者本人做的；也有人提到 Application Insights 內建的自動修正功能被人按下後擴大 App Service Plan，稽核記錄只記到服務身分而非實際操作者，甚至被客服以 GDPR（General Data Protection Regulation，歐盟一般資料保護規範）合理化，讓團隊難以追責。也有觀點認為「繞過記錄」相較其他 Entra 弱點未必最致命，但反駁者指出：不被偵測的攻擊往往仰賴記錄缺口，這正是高價值能力。討論串還延伸到更大的不信任感：有人引用 CISA（Cybersecurity and Infrastructure Security Agency，美國網路安全暨基礎設施安全局）與 CSRB（Cyber Safety Review Board，美國網路安全審查委員會）對 2023 入侵事件的報告，強調是政府端系統管理員先從異常記錄察覺問題，而非微軟主動發現；整體情緒則落在「系統過度複雜、記錄設計與責任歸屬不透明、外部監管與揭露不足」，並伴隨不少對 Azure 品質與可維運性的強烈挫折感。
👥 23 則討論、評論 💬
https://news.ycombinator.com/item?id=47448994
Ryan He
npub1yz…2sm0c
2026-03-20 07:28:49 UTC
Author Public Key
npub1yzzkwcxxj064yq9e0wvtxhr0l2n2lz0w22aw88gf2qcn82mk7kksm2sm0cSeen on
wss://relay.ditto.pubPublished at
2026-03-20 07:28:49 UTCEvent JSON
{
"id": "dda26025893e65e6506f2115d9fbcf4ad41dd659a2e5a95483dd41b5dc3679ad",
"pubkey": "20856760c693f55200b97b98b35c6ffaa6af89ee52bae39d09503133ab76f5ad",
"created_at": 1773991729,
"kind": 1,
"tags": [
[
"proxy",
"https://mistyreverie.org/notes/ak256oef5lf701ul",
"activitypub"
],
[
"client",
"Mostr",
"31990:6be38f8c63df7dbf84db7ec4a6e6fbbd8d19dca3b980efad18585c46f04b26f9:mostr",
"wss://relay.ditto.pub"
]
],
"content": "微軟Azure的安全性就是一沱💩\n\n完整揭露：發現第 3、4 個 Azure Entra ID 登入記錄繞過漏洞 https://trustedsec.com/blog/full-disclosure-a-third-and-fourth-azure-sign-in-log-bypass-found\n\n資安研究者 nyxgeek 揭露他在近三年內找到的第 3、4 個 Azure Entra ID（微軟的雲端身分與存取管理，前身為 Azure AD）「登入記錄繞過」漏洞：攻擊者只要對 login.microsoftonline.com 的驗證端點送出特製的登入請求，就可能在不留下 Entra ID sign-in logs（登入記錄）的情況下通過密碼驗證，甚至直接取得可用的權杖（token，例如 access token），讓密碼噴灑（password spray，對大量帳號以少量常見密碼嘗試登入）與隱形登入更難被偵測。這類登入記錄是許多組織用來偵測入侵、餵給 SIEM（Security Information and Event Management，資安事件與記錄管理平台）的關鍵依據；作者也質疑，當記錄品質與授權分級（例如進階記錄需額外付費）交織時，管理者對「記錄即真相」的信任正在被掏空。\n\n文章回顧先前兩個繞過：GraphNinja 是把 OAuth 2.0 ROPC（Resource Owner Password Credentials，直接用帳號密碼換取權杖的流程）請求送到「非目標租戶」的 tenant 端點，藉此得知密碼是否正確，卻不會在真正租戶留下成功或失敗記錄；GraphGhost 則是用不合法的 client_id 讓流程在「密碼已驗證後」才失敗，管理者只看到失敗登入，卻不知道密碼其實已被猜中。新的 GraphGoblin 更嚴重：把 scope 參數塞入大量重複的合法值（例如 openid 重複數萬次），仍可拿到權杖，但登入記錄完全不會出現；作者推測是記錄寫入時把超長 scope 原樣寫進資料庫，觸發 SQL 欄位長度溢位導致 INSERT 失敗，整筆登入記錄被丟棄。第 4 個「Graph******」繞過同樣直白：把 User-Agent 字串拉到約 50,000 個字元，也能穩定讓登入記錄消失並取得權杖。作者提供了以 curl 一行指令即可重現的示範，並因微軟一開始難以重現而錄製影片佐證；時間線顯示其中一個繞過在他正式回報前就被微軟修掉，另一個則在提供影片後約兩週內完成修補。\n\n面對「登入記錄可能不可靠」，作者提出較具延展性的偵測法：在 Azure Log Analytics 以 KQL（Kusto Query Language，Azure 記錄分析的查詢語言）比對 MicrosoftGraphActivityLogs（Microsoft Graph 活動記錄）與多種登入來源記錄（互動、非互動、服務主體、受控身分等），找出「有 Graph 活動、卻找不到對應登入記錄」的工作階段（以 SessionId 或更細的對照欄位 JOIN），並用告警規則通知；但他也提醒，收集 Graph 活動記錄通常需要 Microsoft 365 E5 這類高階授權。作者同時抨擊 MSRC（Microsoft Security Response Center，微軟安全回應中心）把此案評為 Moderate 而非 Important，拒絕給獎金或致謝；他以 CVSS（Common Vulnerability Scoring System，通用弱點評分系統）論證這是對關鍵稽核記錄「完整性」的重大破壞（v3.1 約 7.5、v4.0 約 8.7），並指出微軟雖口頭淡化，實際修補速度卻異常快，凸顯嚴重度評估與修補行動之間的落差。\n\nHacker News 討論多半把此事視為 Azure／Entra「記錄不可信」問題的又一例：有人分享在 Azure 入口網站刪除 client secret 時，因頁面過久未更新導致 API 以「覆寫整組 secrets」方式提交，最後多刪了一把金鑰，稽核記錄卻顯示是操作者本人做的；也有人提到 Application Insights 內建的自動修正功能被人按下後擴大 App Service Plan，稽核記錄只記到服務身分而非實際操作者，甚至被客服以 GDPR（General Data Protection Regulation，歐盟一般資料保護規範）合理化，讓團隊難以追責。也有觀點認為「繞過記錄」相較其他 Entra 弱點未必最致命，但反駁者指出：不被偵測的攻擊往往仰賴記錄缺口，這正是高價值能力。討論串還延伸到更大的不信任感：有人引用 CISA（Cybersecurity and Infrastructure Security Agency，美國網路安全暨基礎設施安全局）與 CSRB（Cyber Safety Review Board，美國網路安全審查委員會）對 2023 入侵事件的報告，強調是政府端系統管理員先從異常記錄察覺問題，而非微軟主動發現；整體情緒則落在「系統過度複雜、記錄設計與責任歸屬不透明、外部監管與揭露不足」，並伴隨不少對 Azure 品質與可維運性的強烈挫折感。\n\n👥 23 則討論、評論 💬\nhttps://news.ycombinator.com/item?id=47448994",
"sig": "daf1006ea32cc83f238bed15cd4163ef1bbd8572483163be95c38980f37e48937c05fafe24a60ea268bc44cdae71207d05ca95f2f2fedde2cb97b4c20f040f49"
}