【技術分享】從Mimikatz 解讀windows 下的協議

一、了解Mimikatz

大家使用這個工具最多的就是提取密碼，可能對其中涉及到的windows協議不了解，mimikatz項目的介紹當中：

mimikatz is a tool I’ve made to learn C and make somes experiments with Windows security.

我們就來從其中來了解下windows 的協議。

二、kerberos協議

我們先來大致使用下mimikatz 的kerberos 模塊。

其中list,tgt和purge

list 列舉出當前會話的所有緩存憑證，tgt列出當前會話的tgt信息：

purge 銷毀所有的緩存憑證：

ptt: pass the ticket 以及golden/silver，中都涉及到了kerberos 協議(V5)的部分，我們就先來看看kerberos 協議的實現。

圖的來源，說明下這張圖：

主要包含了3個部分：1.AS 服務 2.TGS 服務 3.C/S 端

1，2兩個部分一起稱為KEY DISTRIBUTION CENTER簡稱KDC，Client要向Server 請求數據就需要驗證身份，在這個不安全的網絡環境下必須要證明自己。這就需要一個信任度第三方來幫助完成驗證，KDC就是為了這種需求所設計的服務。我們來解析上圖中的流程（wireshark 抓包）：

1. KRB-AS-REQ:Client 通過用自身密碼加密一個時間戳timestamp，向as服務驗證身份，請求TGT。

2.KRB-AS-REP:AS服務使用client 的密碼副本，解密對比是否符合timestamp要求，成功就是認證了client，生成一個短期的as-sessionkey，用client密碼加密成密文1，另外將as-sessionkey+PAC（特權證書，指明了client所具有的權限）使用TGS服務的密碼加密為密文2（這就是TGT），組成了KRB-AS-REP發送給client。

PAC:

KRB-TGS-REQ:client可以利用密碼解密密文1，得到as-sessionkey，但是不能解密TGT（密文2），所以使用as-sessionkey加密時間戳與TGT一起發送到TGS服務，請求與server交流的server-sessionkey。

1. KRB-TGS-REP:TGS解密TGT得到as-sessionkey，在使用as-sessionkey解密時間戳部分，如果時間戳符合要求，就生成server-sessionkey，然后繼續使用as-sessionkey加密server-sessionkey為密文1，利用server的密碼加密server-sessionkey+PAC 為密文2（圖中的service ticket），一同發給client。

2.KRB_AP_REQ:client 利用as-sessionkey 解密得到server-sessionkey，因為不能解密service ticket（4中的密文2），所以就無法偽造，再使用server-sessionkey 加密時間戳，與service ticket 一起發送到server 端，也解決了server可能無法及時接收SessionKey的問題。

1. KRB_AP_REP：server受到KRB_AP_REQ之后，利用server密碼解密ServiceTicket，得到server-sessionkey，然后用server-sessionkey解密Authenticator得到時間戳，成功驗證client的身份。

這樣整個kerberos 協議的流程就完成了，其中都使用到了時間戳，所以域內都要時間同步才可以，整個協議設計的很是巧妙。

我們來說明下其中golden與ptt的使用：

從上圖演示中，可以看出來在一個低權限域用戶提升到管理員了，后面想要執行命令可以用psexec，也是不用輸入密碼的。其中godlen票據導出的時候，sid與krbtgt的ntlm，可以在原來有DC權限的時候，使用lsadump::lsa /patch導出。

golden ticket 就是偽造了TGT，可以看到第二步中需要TGS服務密碼加密，然而TGS就是kerberos的密碼，修改PAC權限，這樣就合法的偽造了TGT，就完成了一個權限提升的過程。

三、MS-DRSR協議

Mimikatz其中一個重要的模塊：lsadump::dcsync ，使用DRSR向DC查詢用戶信息。我們先看一個使用例子：

for /f "tokens=1" %i in (username.txt) do @mimikatz.exe "lsadump::dcsync /user:%i /domain:localtest.com" exit >> info.txt

導出了第一列用戶的hash信息：

SRSR介紹：

The Directory Replication Service (DRS) Remote Protocol is an RPC protocol for replication and management of data in Active Directory.

使用RPC協議，不會產生LOG，但是必須要有：Administrator 和 Domain controller。其中主要的函數：

客戶端通過調用IDL_DRSBind獲取特定DC的DRS_HANDLE，然后調用該DC上的任何其他drsuapi方法，并將DRS_HANDLE作為第一個參數傳遞。直到客戶端調用IDL_DRSUnbind，或直到服務器的DRS_HANDLE無效（例如崩潰），客戶端的DRS_HANDLE仍然可用于進行方法調用。

與DRS_HANDLE關聯的唯一狀態是由IDL_DRSBind建立的狀態。只要DRS_HANDLE保持有效，該狀態就是不變的。因此，如果客戶端通過對IDL_DRSBind使用相同的參數來為同一個DC創建兩個綁定句柄，則drsuapi方法的服務器行為不受客戶端傳遞給該方法的綁定句柄選擇的影響。其中大多都是涉及一些函數調用，例如IDL_DRSGetNT4ChangeLog 這個方法用于支持Active Directory復制到Windows NT 4.0備份域的控制器（BDC）的實現。以及其中關于兩個函數UUID的設置：

更多詳細的過程看這里：https://msdn.microsoft.com/en-us/library/cc228096.aspx。

四、總結

windows 應該是還是現在主流的辦公系統，所以公司中windows 的域對企業就很重要，方便人員協作以及管理，但是如果不做好嚴格的權限控制，以及對服務器及時 的更新，就有可能這個企業內網都會被一舉攻陷。例如ms14-068 和 ms11-013 都是出在windows 協議方面的漏洞，像MS17-010，也是SMB協議方面的問題。所以我們就要對windows 下的協議更加了解，才能挖到0day嘛。這里有一份windows 下的所有協議介紹:

https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/Windows_Protocols.zip