溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章將為大家詳細講解有關kerberos體系中委派的利用方式是什么，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。
下面主要說明一下在kerberos體系中關于委派的利用方式，委派在域環境中其實是一個很常見的功能，對于委派的利用相較于先前說的幾種攻擊方式較為“被動”，但是一旦利用也會有很大的危害。
在域中如果出現A使用Kerberos身份驗證訪問域中的服務B，而B再利用A的身份去請求域中的服務C，這個過程就可以理解為委派。
例：
User訪問主機s2上的HTTP服務，而HTTP服務需要請求其他主機的SQLServer數據庫，但是S2并不知道User是否有權限訪問SQLServer，這時HTTP服務會利用User的身份去訪問SQLServer，如果User有權限訪問SQLServer服務才能訪問成功。
而委派主要分為非約束委派（Unconstraineddelegation）和約束委派（Constrained delegation）兩個方式，下面分別介紹兩種方式如何實現。
非約束委派在Kerberos中實現時，User會將從KDC處得到的TGT發送給訪問的service1（可以是任意服務），service1拿到TGT之后可以通過TGT訪問域內任意其他服務，所以被稱為非約束委派。
流程：
1. 用戶通過發送KRB_AS_REQ消息請求可轉發 TGT（forwardable TGT，為了方便我們稱為TGT1）。
2. KDC在KRB_AS_REP消息中返回TGT1。
3. 用戶再通過TGT1向KDC請求轉發TGT（forwardedTGT，我們稱為TGT2）。
4. 在KRB_TGS_REP消息中返回轉發TGT2。
5. 用戶使用TGT1向KDC申請訪問Service1的ST（ServiceTicket）。
6. TGS返回給用戶一個ST。
7. 用戶發送KRB_AP_REQ請求至Service1，這個請求中包含了TGT1和ST、TGT2、TGT2的SessionKey。
8. Service1使用用戶的TGT2通過KRB_TGS_REQ發送給KDC，以用戶的名義請求能夠訪問Service2的票據。
9. KDC在KRB_TGS_REP消息中返回Service2到Service1的票據。
10. Service1以用戶的名義像Service2發送KRB_AP_REQ請求。
11. Service2響應步驟10中Service1的請求。
12. Service1響應步驟7中用戶的請求。
13. 在這個過程中的TGT轉發機制，沒有限制Service1對TGT2的使用，也就是說Service1可以通過TGT2來請求任意服務。
14. KDC返回步驟13中請求的票據。
15和16即為Service1通過模擬用戶來訪問其他Service。
可以看到在前5個步驟中User向KDC申請了兩個TGT（步驟2和4），一個用于訪問Service1一個用于訪問Service2，并且會將這兩個都發給Service1。并且Service1會將TGT2保存在內存中。
非約束委派的設置：
Windows域中可以直接在賬戶屬性中設置：
由于非約束委派的不安全性，微軟在windows2003中發布了約束委派的功能。約束委派在Kerberos中User不會直接發送TGT給服務，而是對發送給service1的認證信息做了限制，不允許service1代表User使用這個TGT去訪問其他服務。這里包括一組名為S4U2Self（Service for User to Self）和S4U2Proxy（Service forUser to Proxy）的Kerberos協議擴展。
從下圖可以看到整個過程其實可以分為兩個部分，第一個是S4U2Self的過程（流程1-4），第二個是S4U2Proxy的過程（流程5-10）。
流程：
1. 用戶向Service1發送請求。
2. 這時在官方文檔中的介紹是在這一流程開始之前Service1已經通過KRB_AS_REQ得到了用戶用來訪問Service1的TGT，然后通過S4U2self擴展模擬用戶向KDC請求ST。
3. KDC這時返回給Service1一個用于用戶驗證Service1的ST（我們稱為ST1），并且Service1用這個ST1完成和用戶的驗證過程。
4. Service1在步驟3使用模擬用戶申請的ST1完成與用戶的驗證，然后響應用戶。
注：這個過程中其實Service1是獲得了用戶的TGT和ST1的，但是S4U2Self擴展不允許Service1代表用戶去請求其他的服務。
5. 用戶再次向Service1發起請求，此時Service1需要以用戶的身份訪問Service2。這里官方文檔提到了兩個點：
A.Service1已經驗證通過，并且有一個有效的TGT。
B.Service1有從用戶到Service1的forwardableST（可轉發ST）。個人認為這里的forwardable ST其實也就是ST1。
6. Service1代表用戶向Service2請求一個用于認證Service2的ST（我們稱為ST2）。用戶在ST1中通過cname（client name）和crealm（client realm）字段標識。
7. KDC在接收到步驟6中Service1的請求之后，會驗證PAC（特權屬性證書，在第一篇中有說明）的數字簽名。如果驗證成功或者這個請求沒有PAC（不能驗證失敗），KDC將返回ST2給Service1，不過這個ST2中cname和crealm標識的是用戶而不是Service1。
8. Service1代表用戶使用ST2請求Service2。Service2判斷這個請求來自已經通過KDC驗證的用戶。
9. Service2響應Service1的請求。
10. Service1響應用戶的請求。
在這個過程中，S4U2Self擴展的作用是讓Service1代表用戶向KDC驗證用戶的合法性，并且得到一個可轉發的ST1。S4U2Proxy的作用可以說是讓Service1代表用戶身份通過ST1重新獲取ST2，并且不允許Service1以用戶的身份去訪問其他服務。更多的細節可以參考官方的文檔，和RFC4120的內容。
同時注意forwardable字段，有forwardable標記為可轉發的是能夠通過S4U2Proxy擴展協議進行轉發的，如果沒有標記則不能進行轉發。
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/3bff5864-8135-400e-bdd9-33b552051d94
約束委派的配置：
可以在賬戶屬性中將tsvc的委派方式更改為約束委派
在域中，可以通過PowerView腳本來搜索開啟了委派的主機和用戶。查詢非約束委派主要是通過搜索userAccountControl屬性包含ADS_UF_TRUSTED_FOR_DELEGATION的主機或賬戶。而約束委派則通過查詢userAccountControl屬性包含TRUSTED_TO_AUTH_FOR_DELEGATION的主機或用戶。
通過Import-ModulePowerView.ps1加載PowerView腳本之后使用下面的命令進行查詢。
查詢域中配置非約束委派的賬戶：
Get-NetUser -Unconstrained -Domainyunying.lab
查詢域中配置非約束委派的主機：
Get-NetComputer -Unconstrained -Domainyunying.lab
在另一個版本的PowerView中采用的是Get-DomainComputer
Get-DomainComputer -Unconstrained-Properties distinguishedname,useraccountcontrol -Verbose | ft -a
查詢域中配置約束委派的賬戶：
Get-DomainUser –TrustedToAuth -Propertiesdistinguishedname,useraccountcontrol,msds-allowedtodelegateto| fl
Get-DomainUser -TrustedToAuth -Domainyunying.lab
查看設置了約束委派的用戶
查詢域中配置約束委派的主機:
Get-DomainComputer -TrustedToAuth -Domainyunying.lab
上文中說明了兩種委派方式，下面結合實驗說明針對兩種委派的利用方式。
首先環境和前兩篇文章相同。假設我們已經獲取了一個已經配置了委派的賬戶權限或者是密碼，現在我們通過這些條件來攻擊其他賬戶。
實驗環境：
域：YUNYING.LAB
域控：WindowsServer 2008 R2 x64(DC)：用戶Administrator
域內主機：WindowsServer 2008 R2 x64(s2)：用戶tsvc
所需工具：
Mimikatz
實驗流程：
在域中只有服務賬戶才能有委派功能，所以先把用戶tsvc設置為服務賬號。
setspn -U -Avariant/golden tsvc
通過setspn -l tsvc查看配置成功。
然后在“AD用戶和計算機”中將tsvc設置為非約束委派模式
此時在域控上使用Administrator訪問tsvc所在主機S2的SMB服務。
我們在S2上通過mimikatz可以導出Administrator發送過來的TGT內容。這里需要使用管理員權限打開mimikatz，然后通過privilege::debug命令提升權限，如果沒有提升權限會報kuhl_m_sekurlsa_acquireLSA錯誤。再使用sekurlsa::tickets/export命令導出內存中所有的票據。
可以看到名稱為[0;9bec9]-2-0-60a00000-Administrator@krbtgt-YUNYING.LAB.kirbi的這一條即為Administrator發送的TGT。
此時訪問域控被拒絕。
通過
kerberos::ptt [0;9bec9]-2-0-60a00000-Administrator@krbtgt-YUNYING.LAB.kirbi
命令將TGT內容導入到當前會話中，其實這也是一次Pass The Ticket攻擊（有興趣的可以了解一下）。
通過kerberos::list查看當前會話可以看到票據已經導入到當前會話。
導入之后已經可以訪問域控的共享目錄。也就是說每當存在用戶訪問tsvc的服務時，tsvc的服務就會將訪問者的TGT保存在內存中，可以通過這個TGT訪問這個TGT所屬用戶的所有服務。非約束委派的原理相對簡單，就是通過獲取到的administrator的TGT進行下一步的訪問。
這里有一個點就是sekurlsa::tickets是查看內存中所有的票據，而kerberos::list只是查看當前會話中的kerberos票據。更多的mimikatz的使用可以參考https://github.com/gentilkiwi/mimikatz/wiki
Print Spooler服務+非約束委派提升至域控權限：
在2018年的DerbyCon中WillSchroeder（@ Harmj0y），Lee Christensen（@Tifkin_）和Matt Nelson（@ enigma0x3）提到了關于非約束委派的新方式，通過域控的Print Spooler服務和非約束委派賬戶提升至域控權限（https://adsecurity.org/?p=4056），主要的原理就是通過PrintSpooler服務使用特定POC讓域控對設置了非約束委派的主機發起請求，獲取域控的TGT，從而提升權限。
約束委派由于只指定了特定的服務，所以利用起來相對非約束委派更加復雜，本實驗的條件是配置了約束委派的賬號，并且已知當前配置了約束委派的當前賬戶的密碼（tsvc的密碼）。
這里環境和上文中不變，依然使用普通域賬號tsvc和域Administrator賬戶。不過增加了一個新的工具kekeo，他和mimikatz是同一個作者。
1）、確認賬號tsvc設置了約束委派。
通過工具PowerView的查詢可以看到域內配置了約束委派的列表：
2）、使用kekeo對域控發起申請TGT的請求。
通過已知的賬戶名和明文密碼對KDC發起請求，得到TGT。
Kekeo# tgt::ask /user:tsvc /domain:yunying.lab/password:admin1234! /ticket:tsvc.kirbi
/user:當前用戶名
/domain:所在域名
/password:當前用戶名的密碼
/ticket:生成票據名稱，上圖里生成的沒有按參數設定的來命名，不重要，也可以直接跳過這個參數
3）、使用kekeo申請TGS票據
Kekeo#tgs::s4u /tgt:TGT_filename/user:administrator@yunying.lab /service:cifs/dc.yunying.lab
/tgt:上一步通過kekeo生成的tgt票據
/user:想要偽造的用戶名寫全稱（用戶名@域名）
/service:想要偽造訪問的服務名（服務名/主機的FQDN名稱）
4）、從kekeo中使用exit命令退出，然后使用mimikatz將生成的TGS文件導入到Kerberos憑據列表中
這時可以看到導入之后已經能夠成功訪問域控的共享文件（嚴格來說應該是非約束委派中設置的SPN的權限）。而且在這個過程中是不需要管理員權限的，只是用當前賬戶的權限就可以完成，因為不需要從內存中導出票據。
下面看一下在非約束委派中是如何實現通過非約束委派去獲得所設置的SPN的權限的。實驗過程其實主要是三個步驟：
1、請求TGT
2、請求TGS
3、將TGS導入內存
主要看1、2兩個步驟，第1步中使用Kekeo發起AS-REQ請求去請求TGT。
Kekeo# tgt::ask /user:tsvc/domain:yunying.lab /password:admin1234! /ticket:tsvc.kirbi
這時tsvc獲取到了一個TGT，并且kekeo工具將其保存為一個kirbi格式的文件。
第2步，再使用這個TGT申請兩個ST文件，上文中說到過在約束委派實現的過程中分為兩個部分，分別是S4U2Self擴展和S4U2Proxy擴展。S4U2Self中Service1會代替用戶向KDC申請一張用于訪問自身的TGS，這個TGS也就是生成的兩個TGS中的一個（TGS_administrator@yunying.lab@YUNYING.LAB_tsvc@YUNYING.LAB.kirbi）還有一個TGS是用于訪問非受限委派中設置的SPN的TGS（TGS_administrator@yunying.lab@YUNYING.LAB_cifs~dc.yunying.lab@YUNYING.LAB.kirbi）。
我們抓包也可以看到這里是發起了兩次TGS_REQ請求，在第一個TGS_REQ請求的包里面可以看到KRB5-PADATA-S4U2SSELF的標識。并且cname和sname都是tsvc，也是側面說明這個TGS其實就是拿來驗證自身的。
再看第二個TGS_REQ請求，sname的值為cifs/dc.yunying.lab，也就是截圖中非約束委派中“可由此賬戶提供委派憑據的服務”一欄中添加的SPN。而這個其實就是S4U2Proxy擴展中所申請的TGS票據。
關于約束委派的這種攻擊方式就是通過在Service1（tsvc）中將自己偽造成用戶，然后獲取允許約束委派的SPN的TGS的一個過程。
通過上文中說到設置了非約束委派的賬戶權限如果被竊取那么攻擊者可能獲取非常多其他賬戶的TGT，所以最好是不要在域中使用非約束委派這種功能。
域中不需要使用委派的賬戶特別是administrator賬戶，設置為“敏感用戶不能被委派”。
如果是win2012的系統也可以通過設置受保護的用戶組來緩解委派所帶來的危害。
在兩種方式的委派中，非約束委派的實驗獲取的權限更大，能夠通過TGT直接獲取目標主機的所有服務權限，而約束委派實驗主要是通過TGS來獲取約束委派列表中設置的SPN的TGS來獲得相應的SPN的權限。
關于kerberos體系中委派的利用方式是什么就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
