域滲透學習（二）KERBEROS協議
KERBEROS認證協議
上一篇提到了域內身份認證是采用的Kerberos協議，那么具體的認證流程是怎樣的？
需要了解的幾個概念
1.KDC(Key Distribution Center):密鑰分發中心，里面包含兩個服務：AS和TGS
2.AS(Authentication Server):身份認證服務
3.TGS(Ticket Granting Server):票據授予服務,該服務提供的票據也稱為 TGS 或者叫白銀票據
4.TGT(Ticket Granting Ticket):由身份認證服務授予的票據(黃金票據)，用于身份認證，存儲在內存，默認有效期為10小時
關于下文需要記住的一些點
Client 密鑰 TGS密鑰 和 Service 密鑰 均為對應用戶的NTLM Hash
TGS密鑰 == KDC Hash == krbtgt用戶的NTLM Hash，這幾個可能有時候叫法不一樣但是是一個東西
Server 和 Service 也可以當作一個東西，就是Client想要訪問的服務器或者服務
Client/(TGS/Server) Sessionkey 可以看作客戶端與TGS服務和嘗試登陸的Server之間會話時用來加密的密鑰，而(Client/TGS/Service)密鑰(上面提到的三個實際為NTLM Hash的密鑰)是用來加密會話密鑰的密鑰，為了保證會話密鑰的傳輸安全，這些加密方式均為對稱加密
也就是說，參與認證的三個角色的NTLM Hash是三個密鑰，這三個NTLM Hash的唯一作用是確保會話密鑰Sessionkey的安全傳輸
后面的描述可以看完具體認證流程再回來看
然后Service 和 TGS 通過對TGT 和 Ticket （TGT 和 Ticket中包含會話密鑰Sessionkey和客戶端的身份信息）使用自己的NTLM Hash進行解密獲取到會話密鑰，再使用這個會話密鑰解密客戶端通過這個會話密鑰加密發來的驗證信息
通過解密客戶端發來的驗證信息，可以得到客戶端的身份驗證信息，再與使用自己的NTLM Hash進行解密TGT或者Ticket得到的客戶端身份信息進行比較來完成對客戶端身份的驗證
TGT或Ticket 是由KDC使用TGS密鑰和Service密鑰進行加密的(上文講到KDC可以從AD數據庫中提取這三個東西)，但是Client因為沒有這兩個密鑰所以無法解密與修改。KDC將一份會話密鑰通過Client的密鑰加密發送給Client，另一份放在TGT中和客戶端身份信息一起通過TGS的密鑰進行加密也發送給Client
Client可以使用自己的密鑰解密第一份會話密鑰，然后用這個會話密鑰來加密一份自己的身份信息，再把加密的身份信息和TGT一起發送給KDC，KDC此時如果能使用自己的TGS密鑰來成功解密TGT，說明這個TGT是可信任的，因為Client無法修改TGT，然后再用這個TGT中的會話密鑰來解密客戶端發來的身份信息，與解密TGT得到的身份信息進行比對，如果能成功解密并且比對成功，說明這個Client是可信任的
Server端認證跟上面是一樣的
再說個更簡單易懂的例子（編個故事）：戲說地獄三頭犬
- 用戶登陸
用戶輸入 [用戶名] 和 [密碼] 信息
在客戶端，用戶輸入的 [密碼] 通過計算生成NTLM哈希作做為 [CLIENT密鑰]
2.請求身份認證
2.1 客戶端向AS(身份認證服務)發送認證請求
客戶端向AS發送認證請求，請求中帶有明文的 [用戶名] 信息 此時并未發送[密碼]或[密鑰]信息
2.2 AS確認Client端登錄者用戶身份
AS收到用戶認證請求之后，根據請求中的 用戶名 信息，從數據庫中查找該用戶名是否存在。
如果 用戶名 存在，則根據該用戶名提取NTLM Hash做為AS生成的CLIENT 密鑰，如果第1步中用戶提供的 密碼 信息正確，該秘鑰與用戶登錄中的 CLIENT密鑰 是相等的。
AS為Client響應如下消息：
Msg A 使用 KDC生成的CLIENT密鑰 加密的CLIENT/TGS SESSIONKEY
Msg B 使用 TGS密鑰 加密的TGT(TICKET-GRANTING-TICKET)，客戶端沒有KDC NTLM Hash因此Client無法解密TGT。TGT中包含如下信息：
[Client/TGS SessionKey]
Client ID
Ticket有效時間
CLient 地址
Client收到AS的響應消息以后，利用自身的 CLIENT密鑰 可以對Msg A進行解密，這樣可以獲取到 CLIENT/TGS SESSIONKEY 。但由于Msg B是使用 TGS密鑰 加密的，Client無法對其解密。
AS響應的消息中有一條是屬于Client的，但另外一條卻屬于TGS。
Client/TGS SessionKey出現了兩個Copy，一個給Client端，一個給TGS端。
認證過程中的加密除哈希外均采用的是對稱加密算法。
- 請求服務授權
3.1 客戶端向TGS發送請求服務授權請求
客戶端發送的請求中包含如下兩個消息：
Msg C
要請求的服務ID, 即[Service ID] 上一步2.2中由AS為Client提供的TGT。
Msg D
使用 CLIENT/TGS SESSIONKEY 加密的Authenticator 1 {Client ID, Timestamp}。
KDC接收到TGT與其他內容后，會首先使用KDC 的NTLM Hash解密TGT，只有KDC可以解密TGT，從TGT中提取到 CLIENT/TGS SESSIONKEY ，再使用 CLIENT/TGS SESSIONKEY 解密Authenticator 1，獲取到{Client ID, Timestamp}
并與通過解密TGT獲取到的{Client ID, 有效時間}進行對比
3.2 TGS為Client響應服務授權票據
TGS為Client響應的消息包括：
Msg E 使用 SERVICE密鑰(服務器的NTLMHASH) 加密的 CLIENT-TO-SERVER TICKET , 該Ticket中包含了如下信息:
[Client/Server SessionKey]
Client網絡地址
Ticket有效時間
Client ID
Msg F 使用 CLIENT/TGS SESSIONKEY 加密的 CLIENT/SERVER SESSIONKEY 。
Msg F使用了 CLIENT/TGS SESSIONKEY 加密，因此，該消息對Client可見。Client對其解密以后可獲取到 CLIENT/SERVER SESSIONKEY 。
而Msg E使用了 [SERVICE密鑰] 加密，該消息可視作是TGS給Service Server的消息，只不過由Client一起攜帶發送給Service Server
4.發送服務請求
4.1 Client向Service Server發送服務請求
發送的消息中包括：
Msg E 上一步3.2中，TGS為Client響應的消息Msg E。該消息可以理解為由Client攜帶的消息。
Msg G 由[Client/Server SessionKey]加密的Authenticator 2，包含{Client ID, Timestamp}信息。
CLIENT/SERVER SESSIONKEY 并非直接傳輸，而是被包含在使用[Service密鑰]加密的Msg E中。
既然 [CLIENT/SERVER SESSIONKEY] 并不直接明文傳輸， Client需要向Service Server證明自己擁有正確的 CLIENT/SERVER SESSIONKEY ，所以，Authenticator 2使用了 CLIENT/SERVER SESSIONKEY 加密。
4.2 SS響應Client
SS收到客戶端的服務請求之后，先利用自身的 [SERVICE密鑰] 對Msg E進行解密，提取出Client-To-Server Ticket, 在3.2步驟中，提到了該Ticket中包含了 CLIENT/SERVER SESSIONKEY 以及Client ID信息。
SS使用 CLIENT/SERVER SESSIONKEY 解密Msg G，提取Client ID信息，而后將該Client ID與Client-To-Server Ticket中的Client ID進行比對，如果匹配則說明Client擁有正確的 CLIENT/SERVER SESSIONKEY 。
而后，SS向Client響應Msg H(包含使用 CLIENT/SERVER SESSIONKEY 加密的Timestamp信息)。
Client收到SS的響應消息Msg H之后，再使用 CLIENT/SERVER SESSIONKEY 對其解密，提取Timestamp信息，然后確認該信息與Client發送的Authenticator 2中的Timestamp信息一致。
如上信息可以看出來，該交互過程起到了Client與SS之間的“雙向認證”作用。
認證流程中需要關注的點，票據偽造的原理
2.2 AS確認Client端登錄者用戶身份
KDC返回的Msg B：使用 TGS密鑰(KDCHASH/KRBTGT用戶NTLMHASH) 加密的TGT(Ticket-Granting-Ticket)，當我們獲取到krbtgt用戶的NTLM哈希后，便可主動使用krbtgt用戶的NTLM哈希做為TGS密鑰來生成TGT發送給KDC，這樣KDC如果通過解密偽造TGT獲取到偽造的 [CLIENT/TGS SESSIONKEY] 可以成功解密 Authenticator 1 并完成與TGT中的數據進行比對，便成功騙過了KDC，也就是成功偽造了黃金票據
4.1 Client向SS(Service Server)發送服務請求
客戶端向服務器發送的為使用 SERVICE密鑰(服務器的NTLMHASH) 加密的 CLIENT-TO-SERVER TICKET Ticket中包含用來供服務器解密Authenticator 2的 CLIENT/SERVER SESSIONKEY 。如果獲取到了Service Server的NTLM Hash，便可偽造Ticket，和Authenticator 2 ，Service Server在接收到Ticket和Authenticator 2后可以使用自己的NTLM Hash正常解密完成比對，也就是成功偽造了白銀票據
關于Service Hash，Service Hash其實是目標中一個用戶名與hostname相同的用戶的Hash
如hostname為PC-WIN7的服務器，對應的Hash就是Username : PC-WIN7$的哈希
