如何利用Active Directory中的ACL提升權限
責編：gltian ｜2018-05-04 13:43:58一、前言
在內部滲透測試中，我們經常可以在幾個小時以內獲取域管訪問權限，原因在于相關系統并沒有經過足夠的安全加固，運維人員使用了默認的不安全的Active Directory（活動目錄）設置。在這種場景中，許多公開工具可以幫助我們查找并利用這些缺陷，最終獲得域管理員訪問權限。在本文中我們描述了一種滲透場景，其中我們無法使用標準的攻擊方法，只能深入挖掘才能獲得目標域中的高等級權限。我們介紹了如何使用訪問控制列表（Acccess Control Lists）來提升權限，也發布了Invoke-Aclpwn這款新型工具，該工具是ntlmrelayx的擴充，可以自動執行這種高級的攻擊步驟。
二、AD、ACL以及ACE
隨著大家對網絡安全方面的理解變得更加成熟也更加深刻，我們不得不深入研究才能在Active Directory（AD）中提升權限。在這類場景中，枚舉是一項非常關鍵的技術。AD目錄中的ACL（訪問控制列表）經常容易被人忽視。ACL指的就是一組規則，定義了哪些實體在特定的AD對象上具備哪些權限。這些對象可以是用戶賬戶、組、計算機賬戶、域本身等等。ACL可以在某個對象（比如用戶賬戶）上進行配置，也可以在Organizational Unit（OU，類似于AD內的一個目錄）上配置。在OU上配置ACL的主要優點在于，如果配置得當，所有的后繼對象都將繼承ACL。對象所屬的OU對應的ACL中包含一個ACE（Access Control Entry，訪問控制項），定義了OU以及/或者子對象上對應的標識以及權限。ACE中的標識不一定是用戶賬戶本身；將權限應用于AD的安全組（security groups）是一種常見的做法。將用戶賬戶添加為該安全組的成員后，該用戶賬戶就可以被賦予ACE中配置的權限，因為用戶賬戶與安全組為隸屬關系。
AD中的組成員關系屬于遞歸從屬關系，舉個例子，假設我們有3個組：
- Group_A
- Group_B
- Group_C
- Group_B
Group_C為Group_B的成員，而Group_B自己又是Group_A的成員。當我們將Bob添加為Group_C的成員，Bob不僅是Group_C的成員，也是Group_B以及Group_A的間接成員。這意味著當Group_A具備某個對象或者資源的訪問權限時，Bob也同樣具備該資源的訪問權限。被訪問的資源可以是NTFS文件共享、打印機或者某個AD對象（比如用戶、計算機、組或者域本身）。
為AD安全組提供權限以及訪問控制權是維護和管理（訪問）IT基礎架構的好方法。然而，如果嵌套關系過于復雜，可能就會存在一些安全隱患。前面提到過，如果某個用戶是某個組的直接或者間接成員，那么該用戶就會繼承該組對某個資源的所有權限。如果Group_A被賦予修改AD中域對象的權限，那么Bob自然就會繼承這些權限。然而，如果某個用戶僅屬于某個組，是該組的直接成員，但這個組又是其他50個組的間接成員，那么想理清這種權限繼承關系顯然要花費不少精力。
三、利用Exchange在AD中提升權限
在最近的滲透測試中，我們成功獲取了某個用戶賬戶權限，該用戶為Organization Management組的成員。當安裝Exhcange時會創建這個組，賦予其訪問Exchange相關活動的訪問權限。除了能訪問這些Exchange設置選項以外，該組的成員還可以修改其他Exchange安全組的組成員關系，比如Exchange Trusted Subsystem安全組。這個組是Exchange Windows Permissions安全組的成員之一。
默認情況下，如果某個域安裝了Exchange，那么Exchange Windows Permissions安全組就具備該域對象的writeDACL權限[1]。
writeDACL權限可以允許持有者修改特定對象的權限（換句話說就是修改ACL），這意味著只要成為Organization Management組的成員，我們就可以提升成為域管理員權限。
為了利用這一點，我們將之前已獲得的用戶賬戶添加至Exchange Trusted Subsystem組中。再次登錄后（因為只有在登錄時才會加載安全組成員關系），現在我們已成為Exchange Trusted Subsystem以及Exchange Windows Permission組的成員，這樣我們就可以修改域的ACL。
如果我們可以修改某個AD對象的ACL，我們就可以給某個賬戶分配權限，使其可以向某個屬性（比如包含電話號碼的屬性）中寫入數據。除了為這些屬性分配讀寫權限之外，我們還可以進一步分配，使其具備更多的權限。這些權限為預定義的任務，包括修改密碼的權限、往郵箱發送電子郵件等等[2]。我們還可以為任意賬戶添加如下擴展權限，使其成為當前域的復制（replication）同伴：
Replicating Directory Changes
Replicating Directory Changes All
當我們給這個用戶賬戶設置這些權限后，我們就可以請求域中任何用戶的密碼散列，其中也包括域的krbtgt賬戶。大家可以參考GitHub深入了解這種權限提升技術。
當然，成功控制Organization Management組下某個用戶賬戶并不是經常出現的事情。盡管如此，我們還是可以在更廣泛的層面上使用這種技術。Organization Management組很有可能受另一個小組管理，而這個組又有可能被其他組管理，以此類推。這意味著域環境中存在一條難以發現的關系鏈，如果某一環出問題，整個域就可能淪陷。
為了幫助大家利用關系鏈存在的這種安全風險，Fox-IT編寫了兩款工具。第一款工具使用PowerShell編寫，可以在AD環境內部或者外部運行。第二款工具是ntlmrelayx工具的擴展，這個擴展可以讓攻擊者將身份標識（用戶賬戶以及計算機賬戶）轉發至活動目錄，修改域對象的ACL。
四、Invoke-ACLPwn
Invoke-ACLPwn是一個Powershell腳本，可以使用集成的憑據或者指定的憑據來運行。這款工具的工作原理是使用SharpHound導出域內所有ACL以及當前用戶賬戶下的組成員關系。如果用戶不具備域對象的writeDACL權限，該工具會枚舉域內ACL的所有ACE。ACE中的每個標識都擁有自己的ACL，也會被添加到枚舉隊列中進行處理。為了枚舉所有信息，整個過程需要一點時間，但最終很有可能理出一條關系鏈，獲得域對象的writeDACL權限。
當算出關系鏈后，腳本就會開始處理鏈中可能被利用的每一環：
1、將用戶加入必要的組中；
2、將兩個ACE（Replicating Directory Changes、Replicating Directory Changes All）添加到域對象的ACL中：
3、如果有必要，則使用Mimikatz的DCSync功能請求給定用戶賬戶的哈希值。默認情況下會使用krbtgt賬戶。
利用過程結束后，該腳本會移除利用過程中添加的組成員關系，也會刪掉域對象ACL中的ACE。
為了測試腳本是否能正常工作，我們創建了26個安全組。每個組都是另一個組的成員（即testgroup_a是testgroup_b，而testgroup_b又是testgroup_c的成員，以此類推，直到testgroup_z為止）。
testgroup_z安全組具備修改Organization Management安全組的成員關系權限。前面提到過，這個組有權修改Exchange Trusted Subsystem安全組的組成員關系。只要我們成為該組的成員，就有權修改活動目錄中域對象的ACL。
現在我們擁有包含31條鏈接的一條關系鏈：
1、26個安全組的間接成員關系；
2、具備修改Organization Management安全組成員關系的權限；
3、已成為Organization Management組的成員；
4、具備修改Exchange Trusted Subsystem安全組成員關系的權限；
5、已成為Exchange Trusted Subsystem以及Exchange Windows Permission安全組的成員。
工具的輸出結果如下圖所示：
需要注意的是，雖然這個例子中我們使用了ACL配置信息（Exchange安裝過程中會進行配置），然而這款工具并不需要依賴Exchange或者其他產品來查找或者利用關系鏈。
目前該工具只能枚舉并利用域對象上的writeDACL權限，我們還可以利用其他對象上的其他類型的訪問權限，比如owner、writeOwner、genericAll等。
BloodHound團隊在一篇白皮書中詳細解釋了這些訪問權限，我們將在未來更新這款工具時將這些權限的利用方法包含在內。大家可以從我們的GitHub上下載Invoke-ACLPwn工具。
五、NTLMRelayx
去年我們為ntlmrelay編寫了新的擴充，使其支持中繼至LDAP功能，這樣就能將新用戶添加到活動目錄中，實現域枚舉并提升至域管權限。之前ntlmrelayx中的LDAP攻擊會檢查中繼賬戶是否為域管（Domain Admins）或者企業管理員（Enterprise Admins）組，如果是則會提升權限。
雖然這種方法的確有效，但并沒有考慮中繼賬戶可能擁有的任何特殊權限。根據本文介紹的研究成果，我們在ntlmrelayx中引入了新的攻擊方法。這種攻擊首先會請求重要域對象的ACL，然后將二進制格式解析成工具能夠理解的格式，接著枚舉中繼賬戶的權限。
這樣就能將中繼賬戶所屬的所有組（包括遞歸的組成員關系）考慮在內。一旦枚舉完權限，ntlmrelayx就會檢查用戶是否具備足夠高的權限，以便新用戶或者現有用戶提升權限。
為了提升權限，我們可以使用兩種不同的攻擊方法。第一種攻擊稱為“ACL攻擊”，其中域對象的ACL被修改，攻擊者可控的某個賬戶被賦予域中的Replication-Get-Changes-All權限，這樣就可以使用前面提到過的DCSync方法。如果無法修改ACL，則使用“Group攻擊”將成員添加到域的高權限組中，這些高權限組包括：
Enterprise Admins
Domain Admins
Backup Operators（可以備份域控制器上的關鍵文件）
Account Operators（可以控制域中幾乎所有的組）
如果使用--escalate-user標志指定已有的某個用戶，那么在可以執行ACL攻擊的前提下，該用戶將被賦予Replication權限。如果使用的是“Group攻擊”，則會將該用戶添加到高權限組中。如果沒有指定已有的用戶，則可以考慮創建新的用戶。用戶可以創建在User容器中（用戶賬戶的默認位置），或者在OrganizationalUnit中（類似IT部門等成員具備該容器的管理權限）。
可能會有人注意到我們提到的是中繼賬戶，而不是中繼用戶。這是因為這種攻擊對具備高權限的計算機賬戶來說同樣適用。比如Exchange服務器的計算機賬戶就屬于這類賬戶，在默認配置下該賬戶屬于Exchange Windows Permissions組的成員。如果攻擊者能夠讓Exchange服務器向攻擊者的主機發起身份認證請求（比如使用mitm6這種網絡層的攻擊技術），那么攻擊者就能立即將權限提升為域管理員權限。
現在我們可以使用impacket的secretsdump.py或者Mimikatz導出NTDS.dit的哈希值。
同樣，如果攻擊者具備Exchange服務器的管理員權限，也有可能不需要導出任何密碼或者機器賬戶哈希，就能實現域權限的提升。如果以NT AuthoritySYSTEM身份連接到攻擊者的主機并使用NTLM進行身份認證，這樣就足以向LDAP進行身份認證。如下圖中，我們以SYSTEM權限使用psexec.py調用Invoke-Webrequest這個PowerShell函數，使用-UseDefaultCredentials啟動NTLM的自動身份驗證：
備注：這里出現404錯誤非常正常，因為如果中繼攻擊完成后，ntlmrelayx.py會提供一個404頁面。
需要注意的是，在默認配置的Active Directory中，針對LDAP的中繼攻擊有可能順利完成。如果啟用LDAP簽名就能在一定程度上緩解這種攻擊，然而LDAP簽名默認處于禁用狀態。即便啟用了LDAP簽名，攻擊者還是有可能中繼至LDAPS（基于SSL/TLS的LDAP），因為LDAPS可以當成一個簽名通道。針對此類攻擊的唯一緩解方法是在注冊表中為LDAP綁定通道。
如果想獲取ntlmrelayx中的新功能，只需更新到GitHub上最新版本的impacket即可。
六、安全建議
為了緩解這類安全風險，Fox-IT有如下幾點建議：
1、移除危險的ACL。
使用Bloodhound之類的工具來檢查危險的ACL[3]。Bloodhound可以導出域內的所有ACL，幫助我們識別危險的ACL。
2、移除Exchange Exterprise Servers的writeDACL權限。
移除Exchange Exterprise Servers的writeDACL權限。更多信息請參考這篇.aspx)技術文檔。
3、監控安全組。
監控可能對域產生重大影響的安全組（的成員關系），比如Exchange Trusted Subsystem以及Exchange Windows Permissions。
4、審核并監控對ACL的修改操作。
審核域內ACL的修改操作。如果尚未部署這種機制，那么我們需要修改域控制器的策略。大家可以參考TechNet上的這篇文章了解更多細節。
當域對象的ACL被修改后，就會出現ID為5136的一條事件日志。我們可以使用PowerShell查詢Windows事件日志，比如我們可以使用如下一行語句查詢Security事件日志中ID為5136的事件：
Get-WinEvent -FilterHashtable @{logname='security'; id=5136}
該事件中包含帳戶名以及以SDDL（Security Descriptor Definition Language）格式表示ACL。
我們無法直接查看這個數據，但在Windows 10中有一個PowerShell cmdlet：ConvertFrom-SDDL[4]，這個cmdlet可以將SDDL字符串轉化為可讀性較好的ACL對象。
如果服務器運行的是Windows Server 2016操作系統，我們還可能看到原始的以及修改后的描述符。大家可以參考此鏈接了解更多信息。
獲得這個信息后，我們就可以開始著手調查，發現哪些條目被修改過，研究背后的真實原因。
七、參考資料
[1] https://technet.microsoft.com/en-us/library/ee681663.aspx
[2] https://technet.microsoft.com/en-us/library/ff405676.aspx
[3] https://github.com/BloodHoundAD/SharpHound