歡迎來到 黑吧安全網 聚焦網絡安全前沿資訊,精華內容,交流技術心得!

Kerberos中繼攻擊:濫用無約束委派(上)

來源:本站整理 作者:佚名 時間:2019-10-06 TAG: 我要投稿

關于在Active Directory中濫用Kerberos的研究,最近十分火爆。所以,這篇文章也討論了一個相對未知(從攻擊者的角度來看)但很危險的特性:無約束的Kerberos委派。另外,在撰寫本文的過程中,我還發現了一些有趣的RPC調用,這些調用可以讓域控制器對你進行身份驗證,甚至允許跨越“森林邊界”發起攻擊。然后我發現了PrivExchange,它可以使交換驗證以類似的方式進行。由于用于無約束委派濫用的工具非常少,所以我編寫了一個新的工具包krbrelayx,它可以濫用無約束委派,并從連接到你主機的用戶那里獲取TicketGrantingTicket(TGT)。在本文中,我將深入研究無約束的委派濫用,以及krbrelayx工具包可能提供的一些更高級的攻擊。
結合NTLM中繼
在開始之前,讓我們先澄清一個事情:你實際上不能以中繼NTLM身份驗證的方式中繼Kerberos身份驗證。我編寫的這個工具之所以稱為krbrelayx,是因為它的工作方式類似于impackets ntlmrelayx(中繼工具),并且共享了相當一部分代碼。Kerberos票據使用基于用戶正在驗證的服務的密碼的密鑰進行部分加密,因此將其發送到不同的服務是沒有意義的,因為他們將無法解密票據,因此我們無法進行身份驗證。那么這個工具到底是做什么的呢? 當Windows對啟用了無約束委派的服務或計算機帳戶進行身份驗證時,會發生一些有趣的事情(稍后我會解釋),這些帳戶最終會有一個可用的TGT。如果我們(作為攻擊者)是控制這個帳戶的人,那么可以使用這個TGT對其他服務進行身份驗證。Krbrelayx執行此操作的方式與使用ntlmrelayx進行中繼時類似,即使用自動轉儲密碼、獲取DA權限或執行基于ACL的攻擊,因此它們的命名也很類似。如果你想了解無約束委派是什么,我推薦你看一下Sean Metcalf 的博客。
攻擊要求
要執行這種無約束的委派攻擊,我們需要滿足以下幾個要求:
1.使用無約束的委派權限控制帳戶;
2.修改該帳戶的servicePrincipalName屬性的權限(可選);
3添加/修改DNS記錄的權限(可選);
4.一種連接受害者用戶/計算機的方法。
無約束的委派帳戶
首先,我們需要一個具有無約束委派權限的帳戶。這意味著設置了TRUSTED_FOR_DELEGATION UserAccountControl標志的帳戶,可以是用戶帳戶,也可以是計算機帳戶。AD中的任何用戶都可以使用PowerView來查詢這些帳戶:
$Computers = Get-DomainComputer -Unconstrained
$Users = Get-DomainUser -ldapfilter "(userAccountControl:1.2.840.113556.1.4.803:=524288)"
或使用ActiveDirectory Powershell模塊來查詢這些帳戶也行:
$computers = get-adcomputer -ldapfilter "(userAccountControl:1.2.840.113556.1.4.803:=524288)"
$user = get-aduser -ldapfilter "(userAccountControl:1.2.840.113556.1.4.803:=524288)"
或者可以使用我自己編寫的工具ldapdomaindump提取它們,它將使用TRUSTED_FOR_DELEGATION標志報告具有此權限的用戶/計算機:
grep TRUSTED_FOR_DELEGATION domain_computers.grep
grep TRUSTED_FOR_DELEGATION domain_users.grep
此時,我們已經獲取了帳戶密碼或Kerberos密鑰,就可以解密Kerberos服務票據了,這些票據是用戶在對與受攻擊帳戶關聯的服務進行身份驗證時使用的。以前濫用無約束委派的方法包括使用Mimikatz或Rubeus等從LSASS轉儲緩存的票據,但這需要在已受攻擊的主機上執行代碼。在本文中,我不會這么做,而是通過完全控制的主機通過網絡完成整個操作,這樣就不必擔心端點檢測或通過轉儲進程破壞執行服務器。不過這不適用于Rubeus,因為它使用native API。
對于用戶帳戶,可以通過Kerberoast攻擊(Kerberoast是一種可以作為普通用戶從Active Directory中提取服務帳戶憑證而不需要向目標系統發送任何數據包的有效方法),破解NTLMv1 / NTLMv2身份驗證,簡單地猜測弱密碼或從受損主機上的內存中轉儲密碼來獲取密碼。計算機帳戶很難獲取,因為它們默認情況下具有非常強大的隨機生成密碼,并且其密碼/密鑰僅駐留在帳戶所屬的主機或DC上。當我們在關聯主機上擁有管理員權限時,它變得相對容易,因為計算機帳戶密碼存儲在注冊表中,因此可以通過網絡使用secretsdump.py獲取,或者通過使用mimikatz lsadump :: secrets轉儲密碼,這兩種方法都支持從離線注冊表配置單元轉儲密碼。
要從明文密碼計算Kerberos密鑰,還需要指定salt值。如果你熟悉Kerberos,就會知道使用了不同的加密算法。現代AD安裝支持的最弱密碼使用RC4,密鑰基于用戶的NTLM哈希(不包括任何salt值)。然而,Windows默認選擇的AES-128和AES-256密碼確實包含一個salt值,我們需要將其包含在密鑰計算中。計算這些salt值的步驟如下:
1. 對于用戶帳戶,它是大寫的Kerberos域名+區分大小寫的用戶名;
2. 對于計算機帳戶,它是大寫域名+主機名(the word host )+完整的小寫主機名;
Kerberos域名是域的完全限定域名(FQDN)(因此不是NETBIOS名稱!),完整主機名也是主機的FQDN,而不僅僅是計算機名稱,并且不包含$。用作用戶帳戶salt值的用戶名是區分大小寫的SAMAccountName,因此,如果用戶名為awEsOmEusER1,那么awEsOmEusER1將不會生成正確的密鑰。
對于計算機帳戶,我已經為secretsdump.py添加了一些功能,如果在主機上運行它,它將自動轉儲設備Kerberos密鑰(至少需要impacket 0.9.18或運行git的最新開發版本)。如果由于某種原因無法計算出正確的salt值,你可以使用——krbpass或——krbhexpass(用于十六進制編碼的二進制計算機帳戶密碼)和——krbsalt值參數將其指定為krbrelayx.py。附帶說明一下,由于計算機帳戶密碼是UTF-16-LE中的隨機二進制,但是Kerberos使用UTF-8輸入進行密鑰推導,所以實現起來比預期的時間要長得多。然而,UTF-16字節不是有效的Unicode,當你試圖將其轉換為UTF-8時,Python會不太給力。我花了一些時間才發現,在將Kerberos密鑰執行轉換為UTF-8時,Microsoft實現實際上已經悄悄地替換了所有無效的Unicode字符。
對無約束委派帳戶的ServicePrincipalName屬性的控制
在獲取受攻擊帳戶的Kerberos密鑰之后,就可以解密票據了,但是我們還沒有討論如何讓主機使用Kerberos進行身份驗證。當用戶或計算機希望通過SMB在主機somehost.corp.com上使用Kerberos進行身份驗證時,Windows將向域控制器發送一個服務票據請求。這個請求將包括服務主體名稱(SPN),它由協議和服務所在的主機組成。在本文所舉的例子中,這將是cifs/somehost.corp.com。域控制器在分配了這個ServicePrincipalName的帳戶(如果有的話)的目錄中執行查找,然后使用與該帳戶關聯的Kerberos密鑰加密服務票據。

[1] [2] [3]  下一頁

【聲明】:黑吧安全網(http://www.gkrbnd.live)登載此文出于傳遞更多信息之目的,并不代表本站贊同其觀點和對其真實性負責,僅適于網絡安全技術愛好者學習研究使用,學習中請遵循國家相關法律法規。如有問題請聯系我們,聯系郵箱[email protected],我們會在最短的時間內進行處理。
  • 最新更新
    • 相關閱讀
      • 本類熱門
        • 最近下載
        福彩原副主任