0x01、kerberos簡介
kerberos是一種域內認證協議，Kerberos的標誌是三頭狗，狗頭分別代表以下角色：
- Client
- Server
- KDC(Key Distribution Center) = DC(Domain Controller)
Kerberos認證協議的基礎概念：
票據（Ticket）：是網路物件互相訪問的憑證。
TGT（Ticket Granting Ticket）：入場券，通過入場券能夠獲得票據，是一種臨時憑證的存在。
KDC負責管理票據、認證票據、分發票據，但是KDC不是一個獨立的服務，它由以下服務組成：
- Authentication Service: 為client生成TGT的服務
- Ticket Granting Service: 為client生成某個服務的ticket
另外還需要介紹一個類似於本機SAM的一個資料庫：AD，全稱叫account database，儲存所有client的白名單，只有存 在於白名單的client才能順利申請到TGT。
從物理層面看，AD與KDC均為域控制器(Domain Controller)。
0x02、域認證粗略流程
下列為粗略的一個認證流程，但是沒圖；沒事，我們在0x03更為詳細的分析client和kdc的請求響應。我們們先有個大概的印象
1. client向kerberos服務請求，希望獲取訪問server的許可權。 kerberos得到了這個訊息，首先得判斷client是否是可信賴的， 也就是白名單黑名單的說法。這就是AS服務完成的工作，通過 在AD中儲存黑名單和白名單來區分client。成功後，返回AS返 回TGT給client。
2. client得到了TGT後，繼續向kerberos請求，希望獲取訪問 server的許可權。kerberos又得到了這個訊息，這時候通過client 訊息中的TGT，判斷出了client擁有了這個許可權，給了client訪 問server的許可權ticket。
3. client得到ticket後，終於可以成功訪問server。這個ticket只是 針對這個server，其他server需要向TGS申請
0x03、域認證流程
我們先看流程圖，我們可以發現其中的認證過程分為四步，其中就是與AS和TGS的認證過程。所以我們接下來就慢慢的分析
1、as-req & as-rep
通過簡介的圖片中可以發現TGT認購權證由KDC中的AS認證服務（Authentication Service）下發，那我們就可以剖析as的請求寶與返回包
(一)、as-req請求包
當域內某個使用者試圖訪問域中的某個服務，於是輸入使用者名稱和密碼，本機的Kerberos服務會向KDC的AS認證服務傳送一個AS-REQ認證請求。該請求包中包含： 請求的使用者名稱、請求的主機名、加密型別和Authenticator(使用者NTLM Hash加密的時間戳)等等
pvno: kerberos版本號,這裡為5
msg-type: 訊息型別, AS_REQ 對應的是 krb-as-req(10)
padata：主要是一些認證資訊，每個認證訊息有type和value。
PADA PA-ENC-TIMESTAMP：這個是預認證，就是用使用者hash加密時間戳，作為value傳送給AS伺服器。然後AS伺服器那邊有使用者hash，使用使用者hash進行解密，獲得時間戳，如果能解密，且時間戳在一定的範圍內，則證明認證通過。由於是用使用者密碼Hash加密的，所以也就造成了可以利用雜湊傳遞攻擊
padata-type: padata型別,這裡是 kRB5-PADATA-ENC-TIMESTAMP(2)
padata-vaule: padata的值
etype: 加密型別，這裡是 eTYPE-AES256-CTS-HMAC-SHA1-96(18)
cipher: 金鑰
PADA PA-PAC-REQUEST：這個是啟用PAC支援的擴充套件。PAC(Privilege Attribute Certificate)並不在原生的kerberos裡面，是微軟引進的擴充套件。PAC包含在響應包AS_REP中。這裡的value對應的值為True或False,KDC根據include的值來確定返回的票據中是否需要攜帶PAC。
padata-type: padata型別,這裡是 kRB5-PADATA-PA-PAC-REQUEST(128)
padata-vaule: padata的值
include-pac: 是否包含PAC,這裡為True
req-body：請求body
padding:填充,這裡為0
kdc-options:用於與KDC約定一些選項設定
cname：客戶端使用者名稱,這個使用者名稱存在和不存在，返回的包有差異，可以用於列舉域內使用者名稱。PrincipalName型別，包含type和Value
name-type:名字型別，這裡是 KRB5-NT-PRINCIPAL(1)
cnmae-string:名字，也就是請求的使用者名稱
CNameString: 請求的使用者名稱，這裡為 hack
realm:域名，這裡為 xie
sname：服務端使用者名稱，PrincipalName型別，包含type和Value。在AS-REQ裡面snames krbtgt
name-type:名字型別，這裡是 KRB5-NT-SRV-INST(2)
sname-string: krbtgt使用者的資訊,這裡有2個items
SNameString: 這裡是krbtgt使用者名稱
SNameString: 這裡是域名 xie
till:到期時間，rubeus和kekeo都是20370913024805Z，這個可以作為特徵來檢測工具。
rtime：也是到期時間
nonce：隨機生成的一個數。kekeo/mimikatz nonce是12381973，rubeus nonce是1818848256，這個也可以用來作為特徵檢測工具。
etype：加密型別，這裡有6個items
ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96(18)
ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96(17)
ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5(23)
ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5-56(24)
ENCTYPE: eTYPE-ARCFOUR-HMAC-OLD-EXP (-135)
ENCTYPE: eTYPE-DES-CBC-MD5 (3)
address：客戶端的請求地址，也就是客戶端的主機名
HostAddress WIN7<20>
ddr-type: 地址型別，這裡是 nETBIOS (20)
NetBIOS Name: WIN7<20> (Server service)
(二)、as-rep返回包
當KDC接收到請求之後，通過AD活動目錄查詢得到該使用者的密碼Hash，用該密碼Hash對請求包的Authenticator進行解密，如果解密成功，則證明請求者提供的密碼正確。
而且需要時間戳範圍在五分鐘內，且不是重放，於是預認證成功。KAS成功認證對方的身份之後，傳送響應包給客戶端。
響應包中主要包括：krbtgt使用者的NTLM Hash加密後的TGT認購權證(即ticket這部分)和使用者NTLM Hash加密的Login Session key(即最外層 enc-part 這部分) 以及一些其他資訊
Login Session Key的作用是用於確保客戶端和KDC下階段之間通訊安全。最後TGT認購權證、加密的Lgoin Session Key、時間戳 和 PAC等資訊會傳送給客戶端。PAC中包含使用者的SID，使用者所在的組等一些資訊。
pvno:kerberos版本號,這裡為5
msg-type:訊息型別,AS_REP對應的是 krb-as-rep(11)
padata：主要是一些認證資訊。一個列表，包含若干個認證訊息用於認證
PA-DATA PA-ENCTYPE-INFO2
padata-type: padata的型別，這裡是 kRB5-PADATA-ETYPE-INFO2(19)
padata-value: padata的值
ETYPE-INFO2-ENTRY
etype: eTYPE-AES256-CTS-HMAC-SHA1-96(18)
salt: 鹽值，這裡是 XIE.COMhack
crealm: 域名,這裡是 XIE.COM
cname：請求的使用者名稱
name-type: 使用者名稱型別，這裡是 kRB5-NT-PRINCIPAL(1)
cname-string: 1item
CNameString: hack
ticket：TGT認購權證
tkt-vno: TGT版本號，這裡為5
realm: 域名，這裡是 XIE.COM
sname:
name-type: KRB5-NT-SRV-INST(2)
sname-string: 2items
SNameString: krbtgt
SNameString: XIE.COM
enc-part: 這部門是用krbtgt的密碼Hash加密的。因此如果我們擁有krbtgt的hash就可以自己製作一個ticket，這就造成了黃金票據攻擊
etype: eTYPE-AES256-CTS-HMAC-SHA1-96(18)
kvno: 版本號，這裡為2
cipher：金鑰
enc-part：這部分是用使用者密碼Hash加密的。裡面最重要的欄位是Login session key，作為下階段的認證金鑰。
etype: eTYPE-AES256-CTS-HMAC-SHA1-96(18)
kvno: 版本號，這裡為3
cipher：金鑰
2、tgs-req & tgs-rep
經過上面的步驟，客戶端獲得了 TGT認購權證 和 Login Session Key。然後用登陸者的密碼NTLM Hash解密Login Session Key得到 原始的Logon Session Key。然後它會在本地快取此 TGT認購權證 和 原始的Login Session Key。
如果現在它需要訪問某臺伺服器的某個服務，它就需要憑藉這張TGT認購憑證向KDC購買相應的入場券ST服務票據（Service Ticket）。
ST服務票據是通過KDC的另一個服務 **TGS（Ticket Granting Service）下發的。在這個階段，微軟引入了兩個擴充套件自協議 S4u2self 和 S4u2Proxy(當委派的時候，才用的到）
(一)、TGS-REQ請求包
客戶端向KDC請求針對指定服務的ST服務票據請求，該請求主要包含如下的內容：客戶端資訊、Authenticator(Login Session Key加密的時間戳)、TGT認購權證(padata下ap-req下的ticket) 和 訪問的服務名 以及一些其他資訊 。
pvno:kerberos版本號,這裡為5
msg-type:訊息型別,TGS_REQ對應的是 krb-tgs-req(12)
padata：padata中包含ap_req,這個是TGS_REQ必須攜帶的部分,這部分會攜帶AS_REP裡面獲取到的TGT票據。還有可能會有PA_FOR_USER，型別是S4U2SELF,是一個唯一的識別符號，該識別符號指示使用者的身份，該識別符號由使用者名稱和域名組成。S4U2Proxy必須擴充套件PA_FOR_USER結構，指定服務代表某個使用者去請求針對服務自身的kerberos服務票據。還有可能會有PA_PAC_OPTIONS，型別是PA_PAC_OPTIONS，S4U2Proxy必須擴充套件PA-PAC-OPTIONS結構。如果是基於資源的約束委派，就需要指定Resource-based Constrained Delegation位。
padata-type: padata型別，這裡是 KRB5-PADATA-TGS-REQ(1)
padata-value: padate的值
ap-req：ap-req詳細分析見下文.這個是TGS_REQ必須攜帶的部分，這部分會攜帶AS_REP裡面獲取到的TGT票據。KDC校驗TGT票據，如果票據正確，就返回TGS票據。
req-body：請求body
padding:這裡為0
kdc-options:用於與KDC約定一些選項設定
realm:域名，這裡為 xie.com
sname：這個是要請求的服務。TGS_REP獲得的ST服務票據是用該服務使用者的hash進行加密的。如果指定的服務是krbtgt，那麼拿到的ST服務票據是可以當做TGT認購權證使用的。
name-type: KRB5-NT-SRV-HST(3)
sname-string: 2 items
SNameString: host
SNameString: win7.xie.com
till:到期時間，rubeus和kekeo都是20370913024805Z，這個可以作為特徵來檢測工具。
nonce：隨機生成的一個數。kekeo/mimikatz nonce是12381973，rubeus nonce是1818848256，這個也可以用來作為特徵檢測工具。
etype：加密型別
ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96(18)
ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96(17)
ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5(23)
ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5-56(24)
ENCTYPE: eTYPE-ARCFOUR-HMAC-OLD-EXP (-135)
(二)、TGS-REP返回包
TGS接收到請求之後，首先會檢查自身是否存在客戶端所請求的服務。如果服務存在，則通過 krbtgt 使用者的NTLM Hash 解密TGT並得到Login Session Key，然後通過Login Session Key解密Authenticator，如果解密成功，則驗證了對方的真實身份，同時還會驗證時間戳是否在範圍內。並且還會檢查TGT中的時間戳是否過期，且原始地址是否和TGT中儲存的地址相同。
在完成上述的檢測後，如果驗證通過，則TGS完成了對客戶端的認證，會生成一個用Logon Session Key加密後的用於確保客戶端-伺服器之間通訊安全的Service Session Key會話祕鑰(也就是最外層enc-part部分)。
並且會為該客戶端生成ST服務票據。ST服務票據主要包含兩方面的內容：客戶端使用者資訊 和 原始Service Session Key，整個ST服務票據用該服務的NTLM Hash；進行加密。最終Service Session Key 和 ST服務票據 傳送給客戶端。
注意：這一步不管使用者有沒有訪問服務的許可權，只要TGT正確，就都會返回ST服務票據，這也是kerberoasting能利用的原因，任何一個使用者，只要hash正確，就可以請求域內任何一個服務的ST票據
pvno:kerberos版本號,這裡為5
msg-type:訊息型別,TGS_REP對應的是 krb-tgs-rep(13)
crealm: 域名,這裡是 XIE.COM
cname：請求的使用者名稱
name-type: 名稱型別，這裡為 KRB5-NT-PRINCIPAL(1)
cname-string: 1 item
CNameString: hack
ticket：即ST服務票據
tkt-vno: 服務票據版本號，這裡為5
realm: XIE.COM
sname:
name-type: KRB5-NT-SRV-HST(3)
sname-string: 2 items
SNameString: host
SNameString: win7.xie.com
enc-part: 這部分是用請求服務的密碼Hash加密的。因此如果我們擁有服務的密碼Hash，那麼我們就可以自己製作一個ST服務票據，這就造成了白銀票據攻擊。也正因為該票據是用請求服務的密碼Hash加密的，所以當我們得到了ST服務票據，可以嘗試爆破enc_part，來得到服務的密碼Hash。這也就造成了kerberoast攻擊
etype: eTYPE-AES256-CTS-HMAC-SHA1-96(18)
kvno: 版本號，這裡為3
cipher：金鑰
enc-part：這部分是用AS-REP返回的session-key加密的。裡面最重要的欄位是Service session key，作為下階段的認證金鑰。
etype: eTYPE-AES256-CTS-HMAC-SHA1-96(18)
cipher:金鑰
0x04、Kerberos下的攻擊手法
雜湊傳遞攻擊：在AS-REQ階段，是用使用者密碼Hash加密的Authenticator(使用者NTLM Hash加密的時間戳，所以也就造成了雜湊傳遞攻擊
域使用者名稱列舉：AS-REQ 的 cname 值，當域使用者不存在時，返回包提示錯誤
密碼噴灑攻擊：並且當使用者名稱存在，密碼正確和錯誤時，返回包也不一樣，所以可以進行使用者名稱密碼爆破。是用固定的密碼去跑使用者名稱
黃金票據：AS-REP 階段，由於返回的 TGT 認購權證是由 krbtgt 使用者的密碼Hash加密的，因此如果我們擁有 krbtgt 的 hash 就可以自己製作一個TGT認購權證。
AS-REP Roasting攻擊：AS-REP階段，最外層的 enc-part 是用使用者密碼 Hash 加密的。對於域使用者，如果設定了選項” Do not require Kerberos preauthentication”，此時向域控制器的 88 埠傳送 AS_REQ 請求，對收到的AS_REP內容(enc-part底下的ciper，因為這部分是使用使用者 hash 加密的 Login Session Key，我們通過進行離線爆破就可以獲得使用者hash)重新組合，能夠拼接成”Kerberos 5 AS-REP etype 23”(18200)的格式，接下來可以使用hashcat對其破解
kerberoast攻擊：在TGS-REP階段，由於enc-part是用服務密碼Hash加密的，所以我們可以通過爆破獲得服務的hash
白銀票據：在TGS-REP階段，TGS_REP裡面的ticket的enc-part是使用服務的hash進行加密的，如果我們擁有服務的hash，就可以給我們自己簽發任意使用者的TGS票據，這個票據也被稱為白銀票據。相較於黃金票據，白銀票據使用要訪問服務的hash，而不是krbtgt的hash，由於生成的是TGS票據，不需要跟域控打交道，但是白銀票票據只能訪問特定服務。但是要注意的一點是，偽造的白銀票據沒有帶有有效KDC簽名的PAC。如果將目標主機配置為驗證KDC PAC簽名，則銀票將不起作用