Kerberos認證流程和黃金、白銀票據

域認證體系 - Kerberos

　　Kerberos 是一種網絡認證協議，其設計目標是通過密鑰系統為客戶機 / 服務器應用程序提供強大的認證服務。該認證過程的實現不依賴於主機操作系統的認證，無需基於主機地址的信任，不要求網絡上所有主機的物理安全，並假定網絡上傳送的數據包可以被任意地讀取、修改和插入數據。

　　在以上情況下， Kerberos 作為一 種可信任的第三方認證服務，是通過傳統的密碼技術(如:共享密鑰)執行認證服務的。

　　Kerberos 主要是用在 域環境下的身份認證協議。

域認證所參與的角色 (三只狗頭)

　　Kerberos的標志是三只狗頭，狗頭分別代表以下角色：

　　1.Client客戶端。

　　2.Server服務端。

　　3.KDC(Key Distribution Center) = DC(Domain Controller)，其中包含了AS（Authentication Service）和TGS（Ticket Granting Service）。

　　其中KDC默認安裝在域控上，負責管理票據、認證票據、分發票據。其中AS負責為client生成TGT的服務，TGS負責為client生成某個服務的ticket。

　　另外還需要介紹一個類似於本機SAM的一個數據庫：AD，全稱叫account database，存儲所有client的白名單，只有存在於白名單的client才能順利申請到TGT。此AD並非活動目錄AD（Active Directory）。

域認證粗略流程 

　　kerberos認證其實就是客戶端與服務端無法識別對方身份，而KDC起到了這個中間人的作用，客戶端向KDC發起請求，KDC認證通過后，會發給客戶端票據，客戶端使用票據即可成功訪問服務端資源。此過程大致可以分為3個部分。

　　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申請。 

Kerberos認證流程

　　上面說到了簡化版的Kerberos認證流程，基本上分為兩步。第一步，客戶端向KDC請求獲得他想要訪問的服務的服務授予票據（可以想象成去動物園，想去買一張能夠進入動物園的門票）。第二步，拿着這張服務授予票據（Ticket）去訪問服務端的服務。大致的過程確實可以看作這兩步，但其中還存在一些問題：問題1. KDC怎么知道你（客戶端）就是真正的客戶端？憑什么給你發放服務授予票據（Ticket）呢？問題2. 服務端怎么知道你帶來的服務授予票據（Ticket）就是一張真正的票據呢？

　　這就需要開始細節的描述一下整個Kerberos認證的過程了。

第一次通信 

　　由於客戶端是第一次訪問KDC，此時KDC也不確定該客戶端的身份，所以第一次通信的目的為KDC認證客戶端身份，確認客戶端是一個可靠且擁有訪問KDC權限的客戶端。

　　① 客戶端用戶向KDC以明文的方式發起請求。該次請求中攜帶了自己的用戶名，主機IP，和當前時間戳；

　　② KDC當中的AS（Authentication Server）接收請求（AS是KDC中專門用來認證客戶端身份的認證服務器）后去kerberos認證數據庫中根據用戶名查找是否存在該用戶，此時只會查找是否有相同用戶名的用戶，並不會判斷身份的可靠性；

　　③ 如果沒有該用戶名，認證失敗，服務結束；如果存在該用戶名，則AS認證中心便認為用戶存在，此時便會返回響應給客戶端，其中包含兩部分內容： 

　　　　1.TGT，使用KDC中的krbtgt用戶的NTLM hash加密session key和客戶端的信息。KRBTGT 賬戶，它是在創建域時系統自動創建的一個賬號，你可以暫時理解為他就是一個無法登陸的賬號，在發放票據時會使用到它的密碼 HASH 值，只有DC才能知道該用戶的密碼hash值。

　　　　2.AS（Session_key,客戶端即將訪問的TGS的Name以及TGT的有效時間（一般為8小時），和一個當前時間戳）。其中Session Key是AS隨機生成的秘鑰，並且使用client的NTLM hash進行加密。

　　當client收到AS和TGT之后，因為TGT是使用krbtgt用戶的NTML hash進行加密，所以client無法進行解密TGT。client會解密用自己的NTLM hash加密的AS數據，得到Session Key，TGS信息和時間戳。首先他會根據時間戳判斷該時間戳與自己發送請求時的時間之間的差值是否大於5分鍾，如果大於五分鍾則認為該AS是偽造的，認證至此失敗。

　　如果是一個假的客戶端，那么他是不會擁有真正客戶端的密鑰的，也就無法解密AS，認證失敗。

第二次通信

　　client得到Session Key之后，用Session Key加密自己的客戶端信息，ip，時間戳發送給TGS，同時也發送了原封不動的TGT和想要訪問的server服務。

　　客戶端行為：

　　① 客戶端使用Session Key加密將自己的客戶端信息發送給KDC，其中包括客戶端名，IP，時間戳；

　　② 客戶端將自己想要訪問的Server服務以明文的方式發送給KDC；

　　③ 客戶端將使用TGS密鑰加密的TGT也原封不動的也攜帶給KDC；

　　TGS行為：

　　① 此時KDC中的TGS（票據授予服務器）收到了來自客戶端的請求。他首先根據客戶端明文傳輸過來的Server服務IP查看當前kerberos系統中是否存在可以被用戶訪問的該服務。如果不存在，認證失敗結束。如果存在，繼續接下來的認證。

　　② TGS使用krbtgt用戶的的密鑰將TGT中的內容進行解密，此時他看到了經過AS認證過后並記錄的用戶信息，一把Session_KEY即CT_SK，還有時間戳信息，他會現根據時間戳判斷此次通信是否真是可靠有無超出時延。　　

　　③ 如果時延正常，則TGS會使用Session_KEY對客戶端的第一部分內容進行解密（使用Session_KEY加密的客戶端信息），取出其中的用戶信息和TGT中的用戶信息進行比對，如果全部相同則認為客戶端身份正確，方可繼續進行下一步。 

　　④ 此時KDC將返回響應給客戶端，包括用server NTML hash加密的Server Ticket，其中包括客戶端的Name，IP，需要訪問的網絡服務的地址Server IP，Server Ticket的有效時間，時間戳以及用於客戶端和服務端之間通信的 Server Session Key。

第三次通信

　　Server Ticket客戶端無法解密，因為使用server服務端的NTLM hash進行加密的，客戶端通過將server ticket發送給服務端，服務端用自己的hash解密Server Ticke和Server Session Key去對比信息和時間長度。

　　最終確認該客戶端就是經過了KDC認證的具有真實身份的客戶端，是他可以提供服務的客戶端。此時服務端返回一段使用CT_SK加密的表示接收請求的響應給客戶端，在客戶端收到請求之后，使用緩存在本地的CS_ST解密之后也確定了服務端的身份。

　　至此，第三次通信完成。此時也代表着整個kerberos認證的完成，通信的雙方都確認了對方的身份，此時便可以放心的進行整個網絡通信了。 

白銀票據(Silver Tickets)

白銀票據特點:

　　1.不需要與KDC進行交互

　　2.需要目標服務的NTLM Hash

　　在第三步認證中的Ticket的組成:

　　　　Ticket=Server Hash(Server Session Key+Client info+End Time)

　　　　當擁有Server Hash時，我們就可以偽造一個不經過KDC認證的一個Ticket。

　　　　PS:Server Session Key在未發送Ticket之前，服務器是不知道Server Session Key是什么的。所以，一切憑據都來源於Server Hash。

偽造白銀票據(Silver Tickets)

　　首先需要導出Server Hash： 

C:\files>mimikatz.exe "privilege::debug” "sekurlsa::logonpasswords" "exit" > log.txt

　　偽造票據: 

mimikatz “kerberos::golden /domain:<域名> /sid:<域 SID> /target:<目標服務器主機名> /service:<服務類型> /rc4:<NTLM Hash> /user:<用戶名> /ptt" exit

　　Other：

　　kerberos::list #列出票據　　

　　kerberos::purge # 清除票據

　　由於白銀票據需要目標服務器的Hash，所以沒辦法生成對應域內 所有服務器的票據，也不能通過TGT申請。因此只能針對服務器 上的某些服務去偽造。

白銀票據(Silver Tickets)防御

　　1.盡量保證服務器憑證不被竊取

　　2.開啟PAC (Privileged Attribute Certifificate) 特權屬性證書保護 功能，PAC主要是規定服務器將票據發送給kerberos服務，由 kerberos服務驗證票據是否有效。

　　開啟方式：將注冊表中 HKEY_LOCAL_MACHINE\SYSTEM \ CurrentControlSet\Control\Lsa\Kerberos\Parameters 中的 ValidateKdcPacSignature 設置為1。

黃金票據(Golden Tickets)

黃金票據特點:

　　1.需要與DC通信

　　2.需要krbtgt用戶的hash

　　PS:這里的krbtgt hash就是之前講的KDC Hash

黃金票據(Golden Tickets) - 偽造

　　偽造票據：

mimikatz “kerberos::golden /domain:<域名> /sid:<域SID> /rc4:<KRBTGT NTLM Hash> /user:<任意用戶名> /ptt" exit

Tickets 總結

　　黃金票據：從攻擊面來看，獲取krbtgt用戶的hash后，可以在域中進行持久性的隱藏，並且日志無法溯源，但是需要拿到DC權限， 使用黃金票據能夠在一個域環境中長時間控制整個域。從防御角度來看，需要經常更新krbtgt的密碼，才能夠使得原有的票據失效。最根本的辦法是不允許域管賬戶登錄其他服務器。

　　白銀票據:從攻擊面來看，偽造白銀票據的難度比偽造黃金票據的難度較小，因為一個域中的服務器如果對外的話，非常容易被入侵， 並且容易被轉儲Server。從防御角度來看，需要開啟PAC認證，但這會降低認證效率，增加 DC的負擔，最根本的還是要加固服務器本身對外的服務。