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）的帳戶或受保護用戶組的成員，從不設置為“可轉發”標志。
- 協議轉換（S4U2Self / TrustedToAuthForDelegation）：s4u2proxy要求服務在身份驗證服務為用戶生成一個TGS到另一個服務之前，為用戶提供一個TGS。它通常被稱為“附加票據”，但我喜歡將其稱為用戶確實已對調用S4U2Proxy的服務進行身份驗證的“證據”。但是，有時用戶通過其他協議（如NTLM或甚至基於表單的身份驗證）對服務進行身份驗證，因此他們不會向服務發送TGS。在這種情況下，服務可以調用s4u2self請求認證服務為任意用戶生成一個TGS，然后在調用s4u2proxy時將其用作“證據”。此特性允許模擬用戶，並且僅當為調用s4u2self的服務帳戶設置TrustedToAuthForDelegation標志時才有可能有效。
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.
下圖說明了這種情況： 
此場景的視頻演示：(https://youtu.be/7odfALcmldo)
S4U2Proxy具有先前獲得的TGS:
請注意，S4U2Proxy響應（到服務B）中生成的TGS似乎設置了FORWARDABLE標志，除非主體被標記為對委派敏感或者是受保護用戶組的成員。
0x05 Serendipity（偶然性）
當我是在測試我的rubeus修改時，是為提交請求做准備，我重置了服務A上的trustedtoauthfordelegation useraccountcontrol標志，並希望在執行s4u2self時看到錯誤消息提示。然而，s4u2和S4U2Proxy都被執行，生成的TGS為我提供了訪問服務B的權限。
我從S4U2Self獲得的票據是不可轉發的，但是，S4U2proxy依然接收了它，對服務B的用戶進行了TGS響應
此時，我想知道我是否完全錯誤配置了我的實驗室環境。
此場景的視頻演示：(https://youtu.be/IZ6BJpr28r4)
在沒有TrustedToAuthForDelegation的情況下為任意帳戶獲取可轉發TGT:
0x05 被誤解的特性
1.被誤解的特性1
經過幾個小時的測試，調試和閱讀MS-SFU之后，我意識到對S4U2Self的理解是錯誤的。不管是否設置了TrustedToAuthForDelegation UserAccountControl標志，s4u2似乎都能正常工作。但是，如果未設置，則根據MS-SFU第3.2.5.1.2節，生成的TGS不可轉發：
“如果Service 1 主體上的TrustedToAuthenticationForDelegation參數設置為：
2.被誤解的特性2
那么，S4U2Proxy仍然不應該使用不可轉發的票據？
當我嘗試使用具有傳統（“傳出”）約束委派的不可轉發TGS調用S4U2Proxy時，它失敗了。但是，基於資源的約束委派（“傳入”）它始終有效。我認為這一定是一個bug，因此在2018年10月26日，我將它報告給了微軟響應中心（MSRC）。
當我不耐煩地等待回復時，我再次閱讀了MS-SFU，並找到了第3.2.5.2節
“如果附加票據字段中的服務票據未設置為Forwardable<20>，並且PA-PAC-OPTIONS[167]（[MS-KILE]第2.2.10節）PADATA類型具有基於資源的約束委派位：
這似乎是一個設計缺陷，用微軟的話來說，這也是一個“特性”。基於資源的受限委派的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的訪問權限。
下圖說明了這種情況： 
此場景的視頻演示：(https://youtu.be/ayavtG7J_TQ)
RBCD作為基於ACL的計算機原始的對象接管：
注意，在步驟3中從S4U2Self獲得的TGS不可轉發，但在調用S4U2Proxy時,它被作為“證據”。
0x07 可轉發的結果
當我在S4U2Proxy響應中檢查生成的TGS時，它設置了FORWARDABLE標志。我為S4U2Proxy提供了一個不可轉發的TGS作為“證據”，並獲得了一個可轉發的TGS。
這是一個bug還是一個特性？
我回到MS-SFU 第3.2.5.2.2節，發現以下內容：
這似乎是另一個很好的特性：S4U2Proxy生產的每個TGS總是可轉發的。
0x08 授權Active Directory對象和基於反射資源的約束委派
當Microsoft引入基於資源的約束委派時，它將用戶和計算機轉換為強大的獨立AD對象，這些對象能夠為自己配置這個新的“傳入”委派。默認情況下，所有資源都有一個訪問控制條目（ACE），允許它們為自己配置基於資源的約束委派。但是，如果攻擊者擁有該帳戶的登錄憑據，那么他們可以偽造一張白銀票據並獲得對它的訪問權限
白銀票據的問題在於，當偽造時，他們沒有具有有效KDC簽名的PAC。如果目標主機配置為驗證KDC PAC簽名，則白銀票據將不起作用。可能還有其他安全解決方案可以檢測白銀票據使用情況。
但是，如果我們擁有計算機帳戶或甚至只是TGT的憑據，我們可以將該帳戶的基於資源的約束委派配置為自身，然后使用S4U2Self和S4U2Proxy為任意用戶獲取TGS。
濫用案列的工作原理如下：
- 攻擊者會破壞憑據或計算機帳戶的TGT（“服務A”）。
- 攻擊者將基於資源的約束委派從服務A配置為自身。
- 攻擊者使用Rubeus執行完整的S4U攻擊，並為有權訪問服務A的用戶獲取TGS。
- 攻擊者可以傳遞票據並模擬用戶訪問服務A.
下圖說明了這種情況：
此場景的視頻演示：（https://youtu.be/63RoJrDMUFg）
基於反射資源的約束委派：
事實上，當帳戶設置了TrustedToAuthForDelegation標志（也稱為“協議轉換”）時，這種基於資源的反射約束委派相當於S4U2SELF，因為它允許帳戶模擬用戶為自己獲取可轉發的TGS。但是，如果使用“僅Kerberos”的傳統約束委派配置了一個帳戶（未設置TrustedToAuthForDelegation且msDS-AllowedToDelegateTo不為空），則傳統條件優先於基於資源的條件，因此s4u2self使用不可轉發的TGS響應和s4u2proxy失敗。
請注意，此技術僅允許為用戶獲取TGS，前提是它未設置為“對委派敏感”，並且不是受保護用戶組的成員，如下面的截圖所示：
0x08 解決敏感問題
仔細檢查上述的輸出結果，則表明S4U2SELF適用於標記為對委派敏感的用戶和受保護用戶組的成員。
仔細檢查該票據表明它沒有有效的服務名稱，並且不可轉發：
但這很容易改變，因為服務名稱不在票據的加密部分。
攻擊者可以使用ASN.1編輯器修改，從S4U2Self獲得的TGS上的SPN，並將其轉換為有效的SPN。
完成后，攻擊者擁有有效的TGS。它不可轉發，但可以對服務進行身份驗證：
此場景的視頻演示：（https://youtu.be/caXFG_vAr-w）
濫用敏感用戶的S4U2Self ：
因此，如果攻擊者擁有計算機帳戶的憑據或TGT，他們可以為任何用戶（包括敏感/受保護的用戶）獲取該計算機的TGS，並在PAC中使用有效的KDC簽名
這意味着獲得一個計算機帳戶的TGT就足以破壞主機。
0x09 無約束委派導致遠程命令執行
正如Lee Christensen（@tifkin_）在DerbyCon 8中的“打印機錯誤”濫用案例中所展示的那樣，通過調用RpcRemoteFindFirstPrinterChangeNotification（Opnum 62）方法，通過SMB連接回指定的IP /主機名來欺騙打印機后台處理程序。
如果攻擊者以無約束委派方式破壞主機，則“打印機錯誤”濫用可能導致在Printer Spooler程序運行的任何加入域的Windows主機上導致遠程命令執行。
濫用案列的工作原理如下：
- 攻擊者以無受約束委派方式來攻擊主機並進行權限提升。
- 攻擊者運行rubes的monitor/harvest模塊。
- 攻擊者啟動SpoolSample或dementor.py，以控制目標主機的打印機spooler，將其TGT委派給無約束委派的受攻擊的主機。
- 攻擊者可以使用抓取的TGT為任何用戶獲取目標主機的TGS，甚至是敏感的委派/受保護的用戶。
- 攻擊者為具有本地管理員權限的用戶獲取目標主機的TGS並對其進行攻擊。
下圖說明了這種情況： 
此場景的視頻演示：（https://youtu.be/XqxWHy9e_J8）
濫用無約束委托，打印機后台處理程序錯誤，以及S4U2Self來破壞主機：
正如Will Schroeder（@ harmj0y）在他的博客文章Not A Security Boundary：Breaking Forest Trusts中所闡述的那樣，無約束委派的跨森林信任的安全邊界，使得這種攻擊跨雙向森林信任是有效的。
0x10 賬戶設置 - TrustedToAuthForDelegation
多年來，Active Directory安全專家一直告訴我們，如果我們必須配置Kerberos委派，那么約束委派是可行的方法，我們應該使用“僅Kerberos”而不是“任何身份驗證協議”（稱為“協議轉換”） “）。但也許“僅Kerberos”和“任何身份驗證協議”之間的選擇實際上並不重要。
我們現在知道，我們可以濫用基於資源約束委派來為任意用戶獲得可轉發的TGS。因此，如果我們有一個具有SPN的帳戶和一個具有傳統約束委派但沒有“協議轉換”的帳戶的憑據（或TGT），我們可以將這兩個“特性”結合起來模擬“協議轉換”。
此濫用案例的工作原理如下：
- 攻擊者會破壞具有SPN的帳戶或創建一個帳戶（“服務A”）。
- 攻擊者會破壞一個帳戶（“服務B”），該帳戶是為服務C上某個服務類的傳統約束委派而設置的，僅使用Kerberos（TrustedToAuthForDelegation未在服務B上設置，並且服務B上的msds allowedToDelegateto包含服務C上的服務，例如“時間/服務C”）。
- 攻擊者將基於資源的約束委派從服務A設置為服務B（將服務B上的msds allowedtoactonbehalf其他標識設置為使用服務B憑據或服務B的tgt包含“服務A”）。
- 攻擊者使用服務A憑據和TGT執行完整的S4U2攻擊，並獲得服務B的受害者的一個可轉發TGS。
- 攻擊者使用服務B憑證和TGT調用。 S4U2Proxy使用前一步驟中的可轉發的TGS，並獲得受害者對時間和服務C的TGS。攻擊者可以修改生成的TGS的服務類，例如從“時間”改為“cifs”，因為服務名稱不受保護。
- 攻擊者可以通過票據獲得對服務C的訪問權限。
下圖說明了這種情況： 
此場景的視頻演示：（https://youtu.be/y37Eo9zHib8）
TrustedToAuthForDelegation Bypass：
0x11無約束域的持久性
一旦攻擊者破壞了域，顯然可以在策略對象（如域控制器）上配置基於資源的約束委派，並根據需要獲得TGS。但是基於資源的約束委派也可以配置為按需生成TGT作為域持久性技術。
一旦域受到破壞，就可以將基於資源的受約束委派從一個受到破壞的帳戶配置為krbtgt帳戶以生成TGTs
濫用案例的工作原理如下：
- 攻擊者會破壞域和具有SPN或創建一個SPN的帳戶（“服務A”）
- 攻擊者將基於資源的受約束委派從服務A配置為krbtgt
- 攻擊者使用Rubeus執行完整的S4U攻擊，並為任意用戶獲取krbtgt的TGS，實際上是一個TGT。
- 攻擊者可以使用TGT向任意服務請求TGS。
下圖說明了這種情況：
此場景的視頻演示：（https://youtu.be/1BU2BflUHxA）
krbtgt帳戶上通過RBCD進行域持久化：
在這種情況下，帳戶服務A獲得了某種程度上類似於KDC的功能，從某種意義上說，它可以為任意用戶生成TGT。
可以說，通過新的訪問控制（ACE）可以實現更細微的持久性，以允許基於資源的約束委派按需配置。
0x012 攻擊方式：RCE / LPE
如上圖所示，如果攻擊者可以使用無約束委派來破壞主機，則可以使用“打印機錯誤”和S4U2Self 來實現RCE 。但是無約束委派並不是那么重要的條件，所以我試圖想出一個不需要無約束委派的攻擊鏈。
如上所述，每個資源都有權為自己配置基於資源的約束委派，這可以通過LDAP完成。如果攻擊者能夠成功執行對LDAP的計算機帳戶身份驗證的NTLM中繼，則此論證為RCE/LPE提供了有力的依據。
濫用案例的工作原理如下：
- 攻擊者會破壞具有SPN的帳戶或創建一個帳戶（“服務A”）。
- 攻擊者使用諸如“打印機錯誤”之類等方式來觸發計算機帳戶身份驗證。
- 攻擊者在域控制器上對LDAP執行計算機帳戶（“服務B”）身份驗證的NTLM中繼。
- 攻擊者配置從服務A到服務B的基於資源的約束委派。
- 攻擊者使用Rubeus執行完整的S4U攻擊，並為在該主機上具有本地管理員權限的用戶獲取服務B的TGS。
- 攻擊者可以傳遞票據並獲得RCE/ LPE，具體取決於用於觸發計算機帳戶身份驗證。
上面的場景很簡單，很好。然而，現實情況是NTLM中繼比看起來更復雜，可能有點不現實。
1.NTLM中繼101
NetNTLM是一種由Microsoft為Windows環境設計的挑戰--響應身份驗證協議。在NetNTLM協議中，發送了三條消息：
- 客戶端發送協商消息以請求身份驗證和“通告功能”。
- 服務器發送包含隨機8字節數的質詢消息。
- 客戶機發送一條包含對挑戰的響應的身份驗證消息。使用一個加密函數計算響應，加密函數具有從用戶密碼（NTLM哈希）生成的密鑰。
服務器驗證對挑戰的響應。如果有效，則驗證成功。否則，身份驗證失敗。
該協議容易受到以下中繼攻擊：
- 處於中間位置的人中的攻擊者等待來自受害者的傳入協商消息。
- 攻擊者將協商消息轉發給目標服務器。
- 目標服務器向攻擊者發送挑戰消息。
- 攻擊者將挑戰消息轉發給受害者。
- 受害者生成有效的身份驗證消息並將其發送給攻擊者
- 攻擊者將有效的身份驗證消息轉發到目標服務器。
- 目標服務器接受AUTHENTICATE消息，並且攻擊者已成功通過身份驗證。
下圖說明了NTLM中繼攻擊：
NetNTLM協議不僅提供身份驗證，還可以有利於會話密鑰交換以進行加密（“密封”）和簽名。客戶端和服務器通過交換消息中的某些標志協商是否需要加密/簽名。交換的會話密鑰使用從客戶端的NTLM哈希生成的密鑰進行RC4加密。客戶端顯然擁有NTLM哈希並可以對其進行解密。但是，域成員服務器不保留域用戶的NTLM哈希值，而只保留本地用戶的NTLM哈希值。當域用戶與成員服務器交換會話密鑰時，成員服務器使用Netlogon RPC協議驗證客戶端對域控制器的挑戰響應，如果交換了會話密鑰則由域控制器計算解密密鑰並提供給成員服務器。
如果客戶端和服務器協商會話密鑰以進行簽名，則執行中繼攻擊的攻擊者可以成功進行身份驗證，但無法獲取會話密鑰以對后續消息進行簽名，除非攻擊者可以獲取以下其中一項：
- 受害者的NTLM哈希值
- 目標服務器的計算機帳戶的憑據
- 破壞域控制器
但是，如果攻擊者獲得上述任何一項，則他們不需要執行NTLM中繼攻擊來攻擊目標主機或冒充受害者，這就是簽名減輕NTLM中繼攻擊的原因。
2.NTLM中繼102
目標是在不協商簽名或加密的情況下，從任何協議到LDAP執行成功的中繼。
我所知道的從計算機帳戶引出連接的大多數都是由smb客戶機或rpc客戶機啟動的，這兩個客戶機似乎總是協商簽名。如果在NTLM交換中協商了簽名，則域控制器上的LDAP服務將忽略所有未簽名的消息（在Windows Server 2016和Windows Server 2012R2上測試）。
最明顯的下一步是對NTLM中繼期間協商簽名的標志的重置。但是，微軟在NTLM協議中引入了一個MIC（我相信是消息完整性代碼）來防止這種情況發生。MIC由客戶端在身份驗證消息中發送，它使用HMAC-MD5和會話密鑰保護所有三個NTLM消息的完整性。如果更改了一個NTLM消息，則MIC將無效，身份驗證將失敗。
並非所有客戶端都支持MIC，例如Windows XP / 2003和更早版本，因此並非強制要求。所以嘗試的另一件事是在NTLM中繼期間忽略MIC。但是，有一個標志表示MIC是否存在，並且該標志是計算NetNTLM對挑戰的響應時使用的“salt”的一部分。因此，如果刪除MIC並重置相應的標志，則NetNTLM響應將無效，並且身份驗證將失敗。
3.反射式NTLM中繼失效
傳統上，計算機帳戶的NTLM中繼是反射性的，這意味着從某個主機返回到它自身。在MS08-068之前，通常通過從SMB轉發到SMB來實現RCE。
在修補之后，反射式跨協議NTLM中繼仍然是可能的，並且最常被濫用是在諸如Hot Potato之類的攻擊中實現LPE 。反射式跨協議中繼在MS16-075中進行了修補，從而永久地終止了反射中繼攻擊（或直到JamesForshaw將其修復）。 Rotten Potato/Juicy Potato仍然被一直利用，但它是一種不同於反射中繼的方式，因為它濫用本地認證，忽略了挑戰響應。
在MS16-075之后，許多安全研究人員停止了尋找能夠引起計算機帳戶身份驗證的證據，因為沒有存在反射中繼的攻擊，研究它們就不再有價值。
4.適用於RCE/LPE的可行NTLM中繼論證
RCE/LPE論證需要以下之一：
- 不協商簽名的客戶端，例如所有Windows版本上的Web客戶端，包括WebDAV客戶端。
- 在NTLM消息中不支持MIC的客戶端，例如Windows XP/2003及更早版本。
- 未忽略未簽名消息或不驗證支持基於資源的受約束委派的域控制器上的MIC的LDAP服務。
觸發計算機帳戶通過HTTP進行身份驗證有不同的論證。其中一些人在Hot Potato中進行濫用。我選擇研究那些采用任意UNC路徑然后觸發WebDAV客戶端連接的路徑。
請注意，在Windows服務器上，默認情況下不安裝WebDAV客戶端。在Windows Server 2012R2及更早版本上，需要桌面體驗功能，在Windows Server 2016或更高版本中，需要WebDAV重定向器功能。但是，在桌面上，默認情況下會安裝WebDAV客戶端。
正如我上面提到的，似乎一些研究人員不再關心這些論證了。然而，正如Lee Christensen（@tifkin_）在“打印機錯誤”和無約束委派的組合演示的那樣，也正如我將在下面演示的那樣，這些論證仍然可以使用的，我鼓勵大家繼續研究它們（並在找到它們時告訴我所有相關信息）。
5.獲取Intranet-Zoned
默認情況下，Web客戶端將僅自動向Intranet區域中的主機進行身份驗證，這意味着主機名中不能存在intranet zone。如果中繼服務器已經有合適的DNS記錄，那么這不是問題。但是，如果中繼服務器是“惡意的”，IP地址將不會切斷它。為了解決這個問題，可以濫用ADIDNS為中繼服務器添加新的DNS記錄，正如Kevin Robertson（@NetSPI）在他的博客文章Exploit Active Directory-Integrated DNS中所闡述的那樣。
0x13典型案例研究
1.案例研究1：MSSQL RCE/LPE
MSSQL有一個名為xp_dirtree的未記錄的存儲過程，它列出了所提供路徑的文件和文件夾。默認情況下，所有經過身份驗證的用戶（“公共”）都可以訪問此存儲過程。
在以下情況下，攻擊者可以通過濫用xp_dirtree存儲過程來實現RCE/LPE（主要取決於連接性）：
- 攻擊者已破壞了允許調用xp_dirtree存儲過程的用戶。
- MSSQL服務作為網絡服務，本地系統或虛擬帳戶運行（默認）
- WebDAV客戶端已在目標主機上安裝並運行。
濫用案例的工作原理如下：
- 攻擊者為具有SPN或創建一個SPN（“服務A”）的帳戶攻擊憑證或TGT，並且允許在目標MSSQL實例上連接並調用xp_dirtree的帳戶。
- 如果需要，攻擊者使用服務A使用ADIDNS添加DNS記錄。
- 攻擊者登錄到目標主機（“服務B”）上的MSSQL服務，並調用xp_dirtree以觸發與惡意WebDAV NTLM中繼服務器的連接
- 攻擊者將計算機帳戶NTLM身份驗證中繼到域控制器上的LDAP服務，並將基於資源的約束委派從服務A配置到服務B.
- 攻擊者使用Rubeus執行完整的S4U攻擊，以便為在目標主機上具有本地管理員權限的用戶獲取服務B的TGS。
- 攻擊者可以通過票證來破壞目標主機。
下圖說明了這種情況： 
此場景的視頻演示：（https://youtu.be/nL2oa3URkCs）
MSSQL RCE通過xp_dirtree和NTLM中繼來配置RBCD：
Matt Bush（@ 3xocyte）將“ Bad Sequel ”這種情況作為PoC利用：
2.案例研究2：Windows 10/2016/2019 LPE
一個深夜，Matt Bush（@ 3xocyte），Danyal Drew（@danyaldrew）和我一起思考如何找到合適的RCE/LPE論證，並決定研究用戶在Windows 10/2016/2019中更改帳戶圖標時會發生什么。我們使用Process Monitor對其進行了分析，並很快發現在帳戶圖標更改過程中，以SYSTEM打開圖片文件來讀取其屬性。這是一個小而毫無意義的操作; 不是任意的文件寫/讀/刪除。
濫用案例的工作原理如下：
- 攻擊者破壞具有SPN的帳戶的憑據或TGT或創建一個帳戶（“服務A”）
- 攻擊者通過安裝了WebDAV重定向器功能（“服務B”）獲得對運行Windows 10或Windows Server 2016/2019的另一台計算機的非特權訪問。
- 如果需要，攻擊者使用服務A使用ADIDNS添加DNS記錄。
- 攻擊者將帳戶配置文件圖標更改為惡意WebDAV NTLM中繼服務器上的路徑。
- 攻擊者將計算機帳戶NTLM身份驗證中繼到域控制器上的LDAP服務，並將基於資源的約束委派從服務A配置到服務B.
- 攻擊者使用Rubeus執行完整的S4U攻擊，為擁有本地管理員權限的用戶獲取服務B的TGS
- 攻擊者可以將票據傳遞來破壞服務B
下圖說明這種情況：
此場景的視頻演示：(https://youtu.be/741uz0ILxCA)
Windows 10/2016/2019 LPE通過NTLM中繼來配置RBCD:
0x14 緩解措施
標記為對委派敏感的帳戶或受保護用戶組的成員不受此處顯示的攻擊的影響，除S4U2Self濫用除外。但是，計算機帳戶會受到影響，根據我的經驗，它們永遠不會被標記為對委派敏感或添加到受保護用戶組。我沒有徹底測試將計算機帳戶設置為對委派敏感或將其添加到受保護用戶組的影響中，因此我不建議這樣做，但我建議您可以進一步研究它。
正如Lee Christensen（@tifkin_）在DerbyCon 8中的“打印機錯誤”濫用案例中所展示的那樣，獲得域控制器的TGT / TGS允許執行“dcsync”並破壞域。如上述所示，在基於資源的約束委派下，，為任何計算機帳戶獲取TGT都允許對其模擬用戶，並可能破壞主機。因此，重要的是不要將任何主機配置為無受約束的委派，因為它可以促進森林內和其他具有雙向信任的林中的其他主機的危害。
使用通道綁定進行LDAP簽名可以緩解上述案例研究中描述的RCE和LPE攻擊鏈。
涉及到ntlm中繼到ldap的rce/lpe攻擊鏈濫用了一個默認的ace，該ace允許自己將msds寫入到其他身份的一半中。添加一個拒絕自己寫入msds的新ace屬性，該屬性被分配到其他身份的一半中，將中斷這些攻擊鏈，然后將不得不返回到與無約束委派的原始屬性。如果您的企業組織不使用基於資源的受限委派，您可以考慮添加一個ACE，阻止每人寫入屬性msds allowedtototobenthetheridentity的操作。
0x015 防御檢測
以下事件可用於日志文本中描述的攻擊的檢測思路：
- S4U2Self：可以在Kerberos服務票據請求事件（事件ID 4769）中檢測到S4U2Self，其中“帳戶信息”和“服務信息”部分指向同一帳戶。
- S4U2Proxy：可以在Kerberos服務票據請求事件（事件ID 4769）中檢測到S4U2Proxy，其中“附加信息”中的“傳輸服務”屬性不為空。
- 無約束域持的久性：可以在Kerberos服務票據請求事件（事件ID 4769）中檢測到上述域持久性技術，其中附加信息中的傳輸服務屬性不為空（表示S4U2Proxy),並且服務信息指向“krbtgt”帳戶。
- msds allowedtoctonbehalf-ofotheridentity：如果定義了適當的sacl，則可以在目錄服務對象修改事件（事件ID 5136）中檢測到基於資源的約束委派配置更改,其中LDAP顯示名稱為“msds allowedtoactonbehalf-ofotheridentity”。主題標識和對象標識相同的事件可以是上面提到的一些攻擊的指示符
0x16 來自微軟的建議
微軟在MS-SFU第5.1節中強調了S4U2Proxy的風險：
“S4U2proxy擴展允許服務代表用戶獲取第二個服務的服務票據。當與S4U2self結合使用時，這允許第一個服務在訪問第二個服務時模擬任何用戶主體。這使得任何允許訪問S4U2proxy擴展的服務具有與KDC本身類似的功能。這意味着允許調用此擴展的每個服務都必須受到與KDC一樣強大的保護，並且服務僅限於使用者知道具有正確行為的服務。
S4U2Proxy是一個危險的擴展，應盡可能限制。但是，引入基於資源的約束委派允許任意帳戶調用S4U2Proxy。方法是將“傳入”委派配置為其自身，那么，我們應該像KDC一樣強有力地保護所有賬戶。