域滲透學習（一）WINDOWS認證機制

WINDOWS認證機制

閱讀本文前需要補充的知識：域的基本概念，域環境與工作組環境的區別

何謂域滲透，域滲透就是基于windows域環境的滲透，而域滲透設計到的技術，如哈希傳遞（PTH）票據傳遞（PTT）委派攻擊等，都是基于域環境下的認證機制來實現的，這也是為什么要了解Windows認證機制的原因之一

Windows的認證包括三個部分，用戶直接操作計算機登陸賬戶（本地認證），遠程連接到工作組中的某個設備（網絡認證），登陸到域環境中的某個設備（域認證）

2. 本地認證 

本地認證十分簡單：用戶輸入密碼，系統收到密碼后將用戶輸入的密碼計算成NTLM Hash，然后與sam數據庫（%SystemRoot%\system32\config\sam）中該用戶的哈希比對，匹配則登陸成功，不匹配則登陸失敗

這里提到的NTLM哈希，是一種單向哈希算法，Windows將用戶的密碼計算成NTLM哈希之后才存儲在電腦中，對于這個概念一定要牢牢記住，因為后面NTLM Hash會經常出現

大致的運算流程為：

用戶密碼->HEX編碼->Unicode編碼->MD4 

用python計算密碼’admin’的NTLM哈希：

NTLM Hash的前身是LM Hash，由于存在安全缺陷已經被淘汰，無需做過多的了解,知道有這個東西即可

本地認證中用來處理用戶輸入密碼的進程即lsass.exe,密碼會在這個進程中明文保存，供該進程將密碼計算成NTLM Hash與sam進行比對

我們使用mimikatz來獲取的明文密碼，便是在這個進程中讀取到的

2. 網絡認證 Net NTLM 

網絡認證即在工作組環境下遠程登陸另一臺電腦所采用的認證機制

NTLM協議的認證過程分為三步，也叫挑戰相應機制：

1.協商

2.質詢

3.驗證

協商：雙方確定使用的協議版本，NTLM存在V1和V2兩個版本，具體區別就是加密方式不同，不用管

質詢：挑戰（Chalenge）/響應（Response）認證機制的核心

1.客戶端向服務器端發送用戶信息(用戶名)請求

2.服務器接受到請求后，判斷本地用戶列表是否存在客戶端發送的用戶名，如果沒有返回認證失敗，如果有，生成一個16位的隨機數，被稱之為“Challenge”， 然后使用登錄用戶名對應的NTLM Hash加密Challenge(16位隨機字符)， 生成Challenge1保存在內存中。同時，生成Challenge1后，將Challenge(16位隨機字符)發送給客戶端。

3.客戶端接受到Challenge后，使用自己提供的賬戶的密碼轉換成對應的NTLM Hash，然后使用這個NTLM Hash加密Challenge生成Response，然后將Response發送至服務器端。

驗證：在質詢完成后，驗證結果，是認證的最后一步。

服務端收到客戶端發送的Response后，與之前保存在內存中的Channelge1比較，如果相等認證通過

其中，經過NTLM Hash加密Challenge的結果在網絡協議中稱之為Net NTLM Hash（不能直接用來進行哈希傳遞攻擊，但可以通過暴力破解來獲取明文密碼）

簡單的來說：客戶端向服務器請求使用某個用戶進行驗證，服務端判斷該用戶是否存在，存在的話使用這個用戶密碼的哈希值來加密一個隨機字符串，并且將這個隨機字符串返回給客戶端，客戶端再把自己提供的密碼進行哈希處理后也來加密這串隨機字符串，然后再把結果發送給服務器，服務器把從客戶端發送的加密結果與自己本地的加密結果進行比較，相同的話便通過認證

其中的關鍵點在于：第二步中客戶端發送的是NTLM哈希值與隨機字符串加密的結果，而這個NTLM哈希是由用戶輸入的密碼本地計算得出的，所以在這個步驟中，只要能提供正確的NTLM哈希即使不知道正確的密碼也可通過認證

再舉個簡單的例子，滲透某個站點，通過sql注入獲取到了用戶數據庫，然后發現數據庫中的管理員密碼是md5加密的而且無法解開，但是這時候發現在前端登錄時，也會將你輸入的密碼進行md5加密，也就是說后端是對比兩個md5值是否相同，那我如果知道密碼的md5值就能直接登錄了，干嘛還要去解開呢？

工作組環境和域環境下Net NTLM認證過程因為有DC（域控制器）的參與流程略有差異，不過不影響我們進行哈希傳遞攻擊

3. 域認證（Kerberos） 

域內認證即采用了Kerberos協議的認證機制，與前兩者相比最大的區別是有個一個可信的第三方機構KDC的參與

參與域認證的三個角色：

Client

Server

KDC(Key Distribution Center) = DC(Domain Controller) = AD（Account Database）+ AS（Authenication Service）+ TGS（Ticket Granting Service）

AD，全稱叫account database，存儲域中所有用戶的用戶名和對應的NTLM Hash，可以理解為域中的SAM數據庫，KDC可以從AD中提取域中所有用戶的NTLM Hash，這是Kerberos協議能夠成功實現的基礎。

從物理層面看，AD與AS，TGS，KDC均為域控制器(Domain Controller)。

Kerberos認證協議的基礎概念：

票據（Ticket）：是網絡對象互相訪問的憑證。

TGT（Ticket Granting Ticket）：看英文名就知道，用來生成Ticket的Ticket，Ticket的爹。

KDC負責管理票據、認證票據、分發票據，但是KDC不是一個獨立的服務，它由以下服務組成：

Authentication Service: 簡稱AS，為Client生成TGT的服務，也用來完成對Client的身份驗證

Ticket Granting Service: 為Client生成允許對某個服務訪問的ticket，就是Client從AS那里拿到TGT之后，來TGS這里再申請對某個特定服務或服務器訪問的Ticket，只有獲取到這個Ticket，Client才有權限去訪問對應的服務

Kerbreros認證流程

Kerbroes認證流程有些繁瑣：

Client向KDC發起服務請求，希望獲取訪問Server的權限。KDC得到了這個消息，首先得判斷Client是否是可信賴的， 也就是從AD數據庫中尋找該用戶是否可用來登錄。這就是AS服務完成的工作，成功后，AS返回TGT給Client。

Client得到了TGT后，繼續向KDC請求，希望獲取訪問Server的權限。KDC又得到了這個消息，這時候通過Client 消息中的TGT，判斷出了Client擁有了這個權限，給了Client訪問Server的權限Ticket。（TGS服務的任務）

Client得到Ticket后便可以使用這個Ticket成功訪問Server。但是這個Ticket只能用來訪問這個Server，如果要訪問其他Server需要向KDC重新申請。

Kerberos由于容易讓人看困，后面單獨再拿出一章來講

參考：https://payloads.online/archivers/2018-11-30/1

轉載請注明來自Ares'X Blog