taibeihacker
Moderator
0x00 前言
早在2018年3月前，我就開始了一場毫無意義的爭論，以證明TrustedToAuthForDelegation屬性是無意義的，並且可以在沒有該屬性的情況下實現“協議轉換”。我相信，只要一旦啟用約束委派（msDS-AllowedToDelegateTo不為空），它是否配置為使用“僅Kerberos”或“任何身份驗證協議”並起作用。我在Benjamin Delpy（@gentilkiwi）的幫助下開始了這段研究過程，他幫助修改了kekekeo以支持一種特定的攻擊，這種攻擊涉及在沒有PAC的情況下使用白銀票據調用s4u2proxy，我們取得了部分成功，但最終的TGS卻無法使用。從那時起，我就一直研究這個問題，試圖用不同的方法來解決這個問題，但沒有取得多大的成功。直到我最終接受了失敗，具有諷刺意味的是，隨後解決方案出現了，以及其他一些有趣的利用案例和新的攻擊技術。
0x01 TL; DR
這篇文章篇幅很長，我很清楚很多人沒有時間或毅力來閱讀它，所以我將在下午中列出本文的重要點：在調用S4U2Proxy時，基於資源的約束委派不需要可轉發的TGS。
無論TrustedToAuthForDelegation屬性的狀態如何，S4U2Self都可以在任何具有SPN的帳戶上運行。如果設置了TrustedToAuthForDelegation，則S4U2Self生成的TGS是可轉發的，除非它對委派或受保護用戶組的成員是信息敏感
以上幾點意味著，如果攻擊者可以控制Active Directory中的計算機對象，則可能會濫用該對象來破壞主機。
即使請求中提供的額外TGS不可轉發，S4U2Proxy也能生成可轉發的TGS。
以上幾點意味著，如果攻擊者利用SPN以及具有傳統約束委派的賬號來攻擊其他任何賬號，那麼是否設置了TrustedToAuthForDelegation屬性並不重要。
默認情況下，任何域用戶都可以濫用MachineAccountQuota來創建一個計算機帳戶並為其設置一個SPN，這使得濫用基於資源的約束委派模擬協議轉換變得更為簡單（為任意用戶獲取一個可轉發的TGS到一個被破壞的服務）。
S4U2Self允許為任意用戶生成有效的TGS，包括那些標記為對委派敏感的用戶或受保護用戶組的成員。生成的TGS具有一個帶有效KDC簽名的PAC。所需要的只是計算機帳戶憑據或TGT。
上述點與無約束委派和“打印錯誤”相結合可能導致遠程代碼執行（RCE）。
krbtgt帳戶上基於資源的約束委派允許為任意用戶生成TGT，並且可以作為持久性技術惡意利用。
通過基於資源的受限委派的從HTTP到LDAP的NTLM中繼配置可能有助於MSSQL服務器上的遠程代碼執行（RCE）或本地權限提升（LPE），Windows 10/2016/2019上的本地權限提升（LPE）。
計算機帳戶變得更有趣。開始尋找更多利用點來觸發攻擊鏈
0x02 Kerberos委派101
如果您沒有跟上濫用kerberos委派授權的分析進度，您應該先閱讀will schroeder（@harmj0y）和lee christensen（@tifkin_uuu）的文章S4U2Pwnage。在那篇文章中，他們比我更好地闡述了它，但我也會盡量簡潔概述它首先，簡要概述Kerberos：
當用戶登錄時，他們使用從其密碼生成的加密密鑰對一條信息（時間戳）進行加密，以向驗證服務器證明他們知道密碼。此步驟稱為“預身份驗證”。
在Active Directory環境中，身份驗證服務器是域控制器。
預身份驗證成功後，身份驗證服務器將向用戶提供一個有效期有限的票據授予票據（TGT）
當用戶希望對某個服務進行身份驗證時，用戶將TGT發送給身份驗證服務器。如果TGT有效，用戶將從身份驗證服務器接收一個票據授予服務（TGS），也稱為“服務票據”。
然後，用戶可以將TGS發送給他們想要訪問的服務，服務可以對用戶進行身份驗證，並根據TGS中包含的數據做出授權決策。
關於Kerberos票據的一些重要說明：
每張票都有明文部分和一個加密部分
票據的明文部分包含票據所針對的服務的服務主體名稱（SPN）
用於票據的加密部分的加密密鑰是從目標服務的帳戶的密碼導出的
TGT是為內置帳戶“krbtgt”加密
TGT上的SPN是krbtgt/domain
通常，服務需要模擬用戶來訪問另一個服務。為了便於實現這一點，在Kerberos協議中引入了以下委派特性：
無約束委派（TrustedForDelegation）：用戶發送一個TGS來訪問服務，連同他們的TGT，然後服務可以使用用戶的TGT為用戶向任何其他服務請求TGS並模擬用戶
約束委派（S4U2Proxy）：用戶發送一個TGS來訪問該服務（“服務A”），如果允許該服務委派給另一個預定義的服務（“服務B”），那麼服務A可以向認證服務提供用戶提供的TGS，並為用戶獲得一個TGS到服務B。請注意，TGS提供了在s4u2proxy請求中，必須設置Forwardable標誌。對於配置為“對委派敏感”（用戶沒有對委派屬性設置為true）的帳戶或受保護用戶組的成員，從不設置為“可轉發”標誌。
0x03 其他受限制的委派
早在2018年10月前，我與Will Schroeder（@ harmj0y）合作，將為基於資源的約束委派的濫用提供了基於ACL的計算機標識的基礎論證。威爾寫了一篇關於這個主題的優秀文章，在繼續之前你也應該閱讀它。再一次，在那篇文章中，Will比我更好地闡述了它，但我會在這裡非常簡潔地概述它。為了配置約束委派，必須具有SeEnableDelegation權限，該權限是敏感的，通常僅授予Domain Admins。為了使用戶/資源更加獨立，在Windows Server 2012中引入了基於資源的約束委派。基於資源的約束委派允許資源配置哪些帳戶可信任委派給他們。
這種約束委派的風格與傳統約束委派非常相似，但配置相反。從帳戶A到帳戶B的傳統約束委派在msDS-AllowedToDelegateTo屬性中的帳戶A上配置，並定義從A到B的“傳出”信任，而在msDS-AllowedToActOnBehalfOfOtherIdentity屬性中的帳戶B上配置基於資源的約束委派，並定義從A到B的“傳入”信任。
一個重要的點是，每個資源都可以為自己配置基於資源的約束委派。在我看來，讓資源自行決定誰是他們信任的是有意義的
Will和我想出了以下濫用案例來破壞特定的主機：
攻擊者破壞設置了TrustedToAuthForDelegation標誌（“服務A”）的帳戶
攻擊者還利用為目標主機（“服務B”）的計算機帳戶配置基於資源的約束委派的權限來攻擊帳戶。
攻擊者配置從服務A到服務B的基於資源的約束委派。
攻擊者調用s4u2self和s4u2proxy作為服務A，以獲取特權用戶對服務B的TGS，以破壞目標主機。
下圖說明了此濫用案例：
這是一個很好的技巧，但使用TrustedToAuthForDelegation標誌設置來破壞帳戶並非一件易事。如果我的研究TrustedToAuthForDelegation取得更大的成效的話，那麼對於這種濫用案例它會派上用場。
0x04 滥用案例：Skipping S4U2Self
為了使用上面的基於ACL的計算機標識的原始論證，我稍微修改了Rubeus以允許攻擊者在調用S4U2Proxy時為受害者提供“證據”TGS而跳過S4U2Self。 Benjamin Delpy也於2018年4月對Kekeo進行了修改;但是，在編寫本文時，Kekeo不支持基於資源的約束委派。更通用的濫用案例將按如下方式：
攻擊者破壞服務A和DACL，並在服務B上配置基於資源的約束委派。
通過社會工程或水坑攻擊，受害者向服務A進行身份驗證以訪問服務（例如CIFS或HTTP）
攻擊者使用mimikatz sekurlsa:tickets或其他方法將受害者的TGS轉儲到服務A
攻擊者配置從服務A到服務B的基於資源的約束委派。
攻擊者使用Rubeus執行S4U2Proxy，之前獲得的TGS是受害者從服務A到服務B所需的“證據”。
攻擊者可以通過票據並冒充受害者訪問服務B.
下圖說明了這種情況：
此場景的視頻演示：(
S4U2Proxy具有先前獲得的TGS:
請注意，S4U2Proxy響應（到服務B）中生成的TGS似乎設置了FORWARDABLE標誌，除非主體被標記為對委派敏感或者是受保護用戶組的成員。
0x05 Serendipity（偶然性）
當我是在測試我的rubeus修改時，是為提交請求做準備，我重置了服務A上的trustedtoauthfordelegation useraccountcontrol標誌，並希望在執行s4u2self時看到錯誤消息提示。然而，s4u2和S4U2Proxy都被執行，生成的TGS為我提供了訪問服務B的權限。
我從S4U2Self獲得的票據是不可轉發的，但是，S4U2proxy依然接收了它，對服務B的用戶進行了TGS響應
此時，我想知道我是否完全錯誤配置了我的實驗室環境。
此場景的視頻演示：(
在沒有TrustedToAuthForDelegation的情況下為任意帳戶獲取可轉發TGT:
0x05 被误解的特性
1.被误解的特性1
經過幾個小時的測試，調試和閱讀MS-SFU之後，我意識到對S4U2Self的理解是錯誤的。不管是否設置了TrustedToAuthForDelegation UserAccountControl標誌，s4u2似乎都能正常工作。但是，如果未設置，則根據MS-SFU第3.2.5.1.2節，生成的TGS不可轉發：“如果Service 1主體上的TrustedToAuthenticationForDelegation參數設置為：
TRUE：KDC必須在S4U2self服務票據中設置FORWARDABLE票據標誌（[RFC4120]第2.6節）。
FALSE和ServicesAllowedToSendForwardedTicketsTo是非空的：KDC不能在S4U2self服務票據中設置FORWARDABLE票據標誌（[RFC4120]第2.6節）“
2.被误解的特性2
那麼，S4U2Proxy仍然不應該使用不可轉發的票據？當我嘗試使用具有傳統（“傳出”）約束委派的不可轉發TGS調用S4U2Proxy時，它失敗了。但是，基於資源的約束委派（“傳入”）它始終有效。我認為這一定是一個bug，因此在2018年10月26日，我將它報告給了微軟響應中心（MSRC）。
當我不耐煩地等待回复時，我再次閱讀了MS-SFU，並找到了第3.2.5.2節
“如果附加票據字段中的服務票據未設置為Forwardable20，並且PA-PAC-OPTIONS[167]（[MS-KILE]第2.2.10節）PADATA類型具有基於資源的約束委派位：
如果未設置，則KDC必須返回狀態為STATUS_NO_MATCH的KRB-ERR-BADOPTION選項。
設置在KERB_VALIDATION_INFO結構的UserAccountControl字段中設置（[MS-PAC]第2.5節）的USER_NOT_DELEGATED位，然後，KDC必須返回狀態為STATUS_NOT_FOUND的KRB-ERR-BADOPTION選項
這似乎是一個設計缺陷，用微軟的話來說，這也是一個“特性”。基於資源的受限委派的s4u2proxy在設計上提供不可轉發的TGS！
請注意，根據上述文檔，即使TGS不必為基於資源的約束委派進行轉發，如果用戶設置為“對委派敏感”，則S4U2Proxy將失敗，這是預料的結果。
0x06 通用的DACL滥用
這兩個被誤解的“特性”意味著對基於ACL的計算機標的原始論證的唯一要求是DACL在計算機對象和另一個帳戶上配置是基於資源的約束委派。任何擁有SPN的帳戶都可以。即使只是其他帳戶的TGT也可以。需要SPN的原因是S4U2Self似乎不適用於沒有SPN的帳戶。但是，任何域用戶都可以通過濫用MachineAccountQuota（默認設置為10）來獲取具有SPN的帳戶，並允許創建新的計算機帳戶。創建新計算機帳戶時，用戶可以為其設置一個SPN，或在以後添加一個。 Kevin Robertson（@NetSPI）提供了一個名為Powermad的工具，它允許通過LDAP實現這一點。
通用濫用案例的工作原理如下：
攻擊者破壞具有SPN或創建一個（“服務A”）帳戶，並使用DACL在計算機帳戶（“服務B”）上配置基於資源的約束委派。
攻擊者破壞具有SPN的帳戶或創建一個（服務A），以配置計算機帳戶（“服務B”）上基於資源的約束委派的DACL
攻擊者配置從服務A到服務B的基於資源的約束委派。
攻擊者使用rubes為有權訪問服務B的用戶執行從服務A到服務B的完整S4U攻擊（s4u2self和s4u2proxy）。
攻擊者可以傳遞票據並模擬用戶以獲得對服務B的訪問權限。
下圖說明了這種情況：
此場景的視頻演示：(
RBCD作為基於ACL的計算機原始的對象接管：
注意，在步驟3中從S4U2Self獲得的TGS不可轉發，但在調用S4U2Proxy時,它被作為“證據”。
0x07 可转发的结果
當我在S4U2Proxy響應中檢查生成的TGS時，它設置了FORWARDABLE標誌。我為S4U2Proxy提供了一個不可轉發的TGS作為“證據”，並獲得了一個可轉發的TGS。
這是一個bug還是一個特性？
我回到MS-SFU第3.2.5.2.2節，發現以下內容：
“在以下情況下，KDC必須響應服務票據：
sname字段包含