![]()
Google旗下網絡安全公司Mandiant披露了一種新方法,可從Windows主機的Machine DPAPI中恢復活躍的Active Directory Federation Services(ADFS)簽名密鑰。該研究揭示,在部分ADFS部署中,證書記錄與實際使用的簽名材料存在嚴重脫節。
配置脫節導致密鑰泄露風險
研究指出,當組織禁用自動證書輪換(AutoCertificateRollover)并手動輪換證書,卻未完全更新配置時,漏洞便會顯現。在此狀態下,ADFS服務仍使用存儲在主機機器范圍加密存儲中的有效證書對令牌進行簽名,而Windows內部數據庫(WID)中卻保留著關于舊證書的過時記錄。
這一發現基于長期存在的“Golden SAML”攻擊技術,其核心在于竊取ADFS令牌簽名證書。此次突破在于,即使數據庫僅指向不再用于簽名的“幽靈”證書,攻擊者仍能找回仍在使用的活躍密鑰。一旦獲取私鑰,攻擊者即可在聯合環境中偽造任意用戶的SAML斷言,繞過多重身份驗證(MFA)及其他身份控制措施,非法訪問Microsoft 365和Entra ID等關聯應用。
在紅隊演練中,分析師最初從ADFS數據庫提取并使用分布式密鑰管理器材料解密得到的證書已失效,生成的斷言被Entra ID拒絕。進一步分析顯示,活躍簽名密鑰受Machine DPAPI保護,留存于服務器的機器RSA密鑰存儲中。這意味著,擁有SYSTEM權限的特權進程無需直接與LSASS內存或ADFS服務進程交互,即可恢復該密鑰。
架構彈性帶來的安全弱點
這種脫節現象常見于管理員關閉自動輪換并執行手動證書更改的環境。盡管主機在操作系統層面綁定了新證書并正常運行,ADFS數據庫卻可能未同步更新。Microsoft事件ID 385可作為證書有效性警告的信號,但在手動管理環境中,這往往是脫節最明顯的跡象。
Mandiant指出,ADFS將私鑰材料存儲于多種保護上下文中。雖然磁盤上可能存在用戶DPAPI保護的密鑰數據塊,但團隊未能通過測試恢復與ADFS服務帳戶相關的可用主密鑰。相反,活躍密鑰位于Windows機器密鑰存儲路徑下,與本地SYSTEM上下文可用的機器主密鑰關聯。這種設計旨在提高運營彈性,確保密鑰在服務帳戶密碼更改、重啟等期間保持可用,但也為具備足夠特權的本地攻擊者提供了可乘之機。
防御建議與緩解措施
演練中,研究人員利用恢復的密鑰偽造了模擬全局管理員的SAML斷言,成功獲得聯合Microsoft 365租戶的全局管理員權限。為此,Mandiant敦促防御者將監控重點轉向操作系統加密操作和令牌頒發行為,而非僅依賴應用層存儲。
具體建議包括:
- 對MachineKeys目錄和機器DPAPI保護路徑進行對象訪問審計,關注安全事件ID 4663,將其作為支持性證據。
- 將ADFS審計記錄與Entra ID登錄日志關聯,識別缺乏清晰上游認證事件的異常聯合登錄。
- 針對特權身份,排查異常IP范圍、聲明偏差及不一致的用戶代理。
Mandiant強調,組織應將ADFS基礎設施視為與域控制器同級的Tier 0身份基礎設施。若攻擊者在ADFS服務器上獲取SYSTEM權限,應默認令牌簽名密鑰已泄露。
在緩解措施方面,推薦將令牌簽名證書移入硬件安全模塊(HSM),避免私鑰以軟件可訪問形式存儲于主機。同時,建議使用組托管服務帳戶運行ADFS,并在手動管理場景中,確保使用Set-AdfsCertificate命令更新配置,而非僅安裝替換證書。此外,組織應定期檢查ADFS配置、LocalMachine證書存儲和聯合元數據的一致性,并調查事件ID 385。鑒于受損密鑰會影響所有SAML信任方,連接其他SaaS應用的組織也應審核相關關系,或考慮放棄基于ADFS的聯合以徹底消除攻擊路徑。
【星途科訊 圖文丨小林 首發于ZAKER科技,轉載請注明出處】
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.