0x01 瞭解Mimikatz
大家使用這個工具最多的就是提取密碼， 可能對其中涉及到的windows協議不瞭解， mimikatz專案的介紹當中：
mimikatz is a tool I’ve made to learn C and make somes experiments with Windows security.
我們就來從其中來瞭解下windows 的協議。
0x02 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 抓包）：
KRB-AS-REQ:Client 通過用自身密碼加密一個時間戳記timestamp， 向as服務驗證身份， 請求TGT。
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。
KRB-TGS-REP:TGS解密TGT得到as-sessionkey， 在使用as-sessionkey解密時間戳記部分， 如果時間戳記符合要求， 就生成server-sessionkey， 然後繼續使用as-sessionkey加密server-sessionkey為密文1， 利用server的密碼加密server-sessionkey+PAC 為密文2（圖中的service ticket）， 一同發給client。
KRB_AP_REQ:client 利用as-sessionkey 解密得到server-sessionkey，因為不能解密service ticket（4中的密文2），所以就無法偽造，再使用server-sessionkey 加密時間戳記，與service ticket 一起發送到server 端，也解決了server可能無法及時接收SessionKey的問題。
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，就完成了一個許可權提升的過程。
0x03 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。
0x04 總結
windows 應該是還是現在主流的辦公系統，所以公司中windows 的域對企業就很重要，方便人員協作以及管理，但是如果不做好嚴格的許可權控制，以及對伺服器及時 的更新，就有可能這個企業內網都會被一舉攻陷。例如ms14-068 和 ms11-013 都是出在windows 協議方面的漏洞，像MS17-010，也是SMB協議方面的問題。所以我們就要對windows 下的協議更加瞭解，才能挖到0day嘛。這裡有一份windows 下的所有協議介紹:
https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/Windows_Protocols.zip
0x05 參考
1.https://github.com/gentilkiwi/mimikatz2.https://msdn.microsoft.com/library/windows/desktop/aa378170.aspx3.https://msdn.microsoft.com/en-us/library/cc228086.aspx4.https://channel9.msdn.com/Events/Open-Specifications-Plugfests/Windows-Identity-and-Exchange-Protocols-Plu登錄安全客 - 有思想的安全新媒體www.anquanke.com/，或下載安全客APP來獲取更多最新資訊吧~
KRB_AP_REQ:client 利用as-sessionkey 解密得到server-sessionkey，因為不能解密service ticket（4中的密文2），所以就無法偽造，再使用server-sessionkey 加密時間戳記，與service ticket 一起發送到server 端，也解決了server可能無法及時接收SessionKey的問題。
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，就完成了一個許可權提升的過程。
0x03 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。
0x04 總結
windows 應該是還是現在主流的辦公系統，所以公司中windows 的域對企業就很重要，方便人員協作以及管理，但是如果不做好嚴格的許可權控制，以及對伺服器及時 的更新，就有可能這個企業內網都會被一舉攻陷。例如ms14-068 和 ms11-013 都是出在windows 協議方面的漏洞，像MS17-010，也是SMB協議方面的問題。所以我們就要對windows 下的協議更加瞭解，才能挖到0day嘛。這裡有一份windows 下的所有協議介紹:
https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/Windows_Protocols.zip
0x05 參考
1.https://github.com/gentilkiwi/mimikatz2.https://msdn.microsoft.com/library/windows/desktop/aa378170.aspx3.https://msdn.microsoft.com/en-us/library/cc228086.aspx4.https://channel9.msdn.com/Events/Open-Specifications-Plugfests/Windows-Identity-and-Exchange-Protocols-Plu登錄安全客 - 有思想的安全新媒體www.anquanke.com/，或下載安全客APP來獲取更多最新資訊吧~