域滲透-Kerberos身份驗證流程

Kerberos協議框架

在 Kerberos 協議中主要是有三個角色的存在：

1. 訪問服務的 Client；

2. 提供服務的 Server；

3.KDC（Key Distribution Center）金鑰分發中心

注意：

1、KDC 服務預設會安裝在一個域的域控中
2、從物理層面看，AD與KDC均為域控制器(Domain Controller)
3、AD其實是一個類似於本機SAM的一個數據庫，全稱叫account database，儲存所有client的白名單，只有存在於白名單的client才能順利申請到TGT
4、KDC 服務框架中包含一個 KRBTGT 賬戶，它是在建立域時系統自動建立的一個賬號，你可以暫時理解為他就是一個無法登陸的賬號，在發放票據時會使用到它的密碼 HASH 值。

 

Kerberos粗略的驗證流程：

先來舉個例子：如果把 Kerberos 中的票據類比為一張火車票，那麼 Client 端就是乘客，Server 端就是火車，而 KDC 就是就是車站的認證系統。如果Client端的票據是合法的（由你本人身份證購買並由你本人持有）同時有訪問 Server 端服務的許可權（車票對應車次正確）那麼你才能上車。當然和火車票不一樣的是 Kerberos 中有存在兩張票，而火車票從頭到尾只有一張。

在KDC中又分為兩個部分：Authentication Service和Ticket Granting Service

Authentication Service：AS 的作用就是驗證 Client 端的身份（確定你是身份證上的本人），驗證通過就會給一張 TGT

Ticket Granting Service：TGS 的作用是通過 AS 傳送給 Client 的票（TGT）換取訪問 Server 端的票（上車的票 ST）。ST（ServiceTicket）也被稱之為 TGS Ticket，為了和 TGS 區分，在這裡就用 ST 來說明，所以TGS Ticket和ST的意思是一樣的。

這就說明了為什麼在Kerberos中存有兩種票，其實就是更加細分了其中的驗證，簡單的描述就是首先你拿身份證驗證頭像是不是一樣，是的話就返回一張TGT，然後在通過驗證車票獲得上車的資格，這裡就有對TGT的驗證，通過的話再返回一張ST/TGS Ticket的票，如果都可以那麼就驗證成功了。

Kerberos 詳解認證流程：

當 Client 想要訪問 Server 上的某個服務時，需要先向 AS 證明自己的身份，然後通過 AS 發放的 TGT 向 Server 發起認證請求，這個過程分為三塊：

The Authentication Service Exchange：Client 與 AS 的互動，

The Ticket-Granting Service (TGS) Exchange：Client 與 TGS 的互動，

The Client/Server Authentication Exchange：Client 與 Server 的互動。

(1)TheAuthentication Service Exchange

KRB_AS_REQ(請求)：

Client->AS：Client 先向 KDC 的 AS 傳送 Authenticator1(內容為Client hash加密的時間戳）

KRB_AS_REP(應答)：

AS-> Client：AS根據使用者名稱在AD中尋找是否在白名單中，然後根據使用者名稱提取到對應的NTLM Hash，然後會生成一個隨機數session key，然後返回給Client由Client的ntlm hash加密的session key-as作為AS資料，再返回TGT（使用KDC中krbtgt的NTLM Hash加密session key和客戶端的資訊，客戶端的資訊裡面包含了時間戳等資訊）

AS驗證的簡述：在 KDC(AD) 中儲存了域中所有使用者的密碼 HASH，當 AS 接收到 Client 的請求之後會根據 KDC 中儲存的密碼來解密，解密成功並且驗證資訊。
驗證成功後返回給 Client兩個東西，一個是由 Client 密碼 HASH 加密的 session key-as 和 TGT（由 KRBTGT HASH 加密的 session key 和 TimeStamp 等資訊）。

(2)TheTicket-Granting Service (TGS) Exchange

KRB_TGS_REQ(請求)：

Client 接收到了加密後的session key-as 和 TGT 之後，先用自身密碼 HASH解密得到session key ，TGT 是由 KDC 中KRBTGT的HASH加密，所以Client 無法解密。這時 Client 再用session key加密的TimeStamp，然後再和TGT 一起傳送給 KDC 中的 TGS（TicketGranting Server）票據授權伺服器換取能夠訪問 Server 的票據。

KRB_TGS_REP(應答)：

TGS 收到 Client 傳送過來的 TGT 和 Session key 加密的 TimeStamp 之後，首先會檢查自身是否存在 Client 所請求的服務。如果服務存在，則用 KRBTGT的HASH解密 TGT。

一般情況下 TGS 會檢查 TGT 中的時間戳檢視 TGT 是否過期，且原始地址是否和 TGT 中儲存的地址相同。

驗證成功之後將返回Client兩個東西，一個是用 session key 加密的 session key-tgs，然後另一個是 Client要訪問的Server的密碼 HASH 加密的 session key-tgs（前面和session key加密生成的）生成就是ST（TGS）

(3)TheClient/Server Authentication Exchange

KRB_AP_REQ(請求)：

Client -> Server 傳送 Authenticator3(session key-tgs 加密 TimeStamp) 和票據 ST(Server 密碼 HASH 加密 session key-tgs)

Client 收到 session key 加密生成的 session key-tgs 和 Server 密碼 HASH 加密 session key-tgs生成的TGS 之後，用 session key 解密得到 session key-tgs，然後把 sessionkey-tgs 加密的 TimeStamp 和 ST（也就是TGS）一起傳送給 Server。

KRB_AP_REP(應答)：

Server-> Client

server 通過自己的密碼解密 ST，得到 sessionkey-tgs, 再用 sessionkey-tgs 解密 Authenticator3 得到 TimeStamp，驗證正確返回驗證成功。