7.內網滲透之windows認證機制

文章參考自三好學生域滲透系列文章

看了內網滲透第五篇文章，發現若是想要真正瞭解PTT，PTH攻擊流程，還須要瞭解windows的認證機制，包括域內的kerberos協議。

windows認證機制

在域滲透中，橫向移動最重要是對windows認證協議的理解

首先介紹一下windows密碼的Hash:

早期SMB協議在網絡上傳輸明文口令，後來出現"LAN Manager Challenge/Response"驗證機制，簡稱LM，因爲容易被破解，微軟提出了windows NT挑戰/響應機制，稱之爲NTLM。如今已經有了更新的NTLM v2以及Kerberos驗證體系。windows加密過的密碼口令，咱們稱之爲hash，windows的系統密碼hash默認狀況下通常有兩部分組成：LM-hash，NTLM-hash 。

NTML hash:

在windows系統中比較常見的是從系統導出來的NTLM hash，經過Hashcat可以破解出明文密碼。NTLM hash一般是指windows系統下Securtiy Account Manager中保存的用戶密碼hash。在滲透測試中，一般可從windows系統中的SAM文件和域控的NTDS.dit文件中得到全部用戶的hash，經過mimikatz讀取lsass.exe進程能得到已登錄用戶的NTLM hash。

NET-NTLM hash:

一般是指網絡環境下NTLM認證中的hash

NTLM認證採用質詢/應答（Challenge/Response）的消息交換模式，流程以下：

1. 客戶端向服務器發送一個請求，請求中包含明文的登陸用戶名。服務器會提早存儲登陸用戶名和對應的密碼hash

2. 服務器接收到請求後，生成一個16位的隨機數(這個隨機數被稱爲Challenge),明文發送回客戶端。使用存儲的登陸用戶密碼hash加密Challenge，得到Challenge1

3. 客戶端接收到Challenge後，使用登陸用戶的密碼hash對Challenge加密，得到Challenge2(這個結果被稱爲response)，將response發送給服務器

4. 服務器接收客戶端加密後的response，比較Challenge1和response，若是相同，驗證成功

在以上流程中，登陸用戶的密碼hash即NTLM hash，response中包含Net-NTLM hash

更多NTLM認證的資料可參考：

http://davenport.sourceforge.net/ntlm.html

在NTLM認證中，NTLM響應分爲NTLM v1，NTLMv2，NTLM session v2三種協議，不一樣協議使用不一樣格式的Challenge和加密算法

因此也就存在不一樣協議的Net-NTLM hash，即Net-NTLM v1 hash，Net-NTLM v2 hash

NTLM認證

在工做組中使用的ntlm認證，若是在域中，則使用Kerberos的認證方式

工做組中：

• 客戶端發起認證請求

• 服務端收到認證請求，向客戶端發送隨機數（chanlleng/挑戰）

• 客戶端使用NTLM Hash打亂該隨機數，生成Net-NTLM Hash，發送回服務端 （這裏會形成pth攻擊）

域環境中：

比起工做組，域中多了一個域控的角色

 

• 首先在client輸入username，password和domain，而後client會把password hash後的值先緩存到本地

• 以後，client把username的明文發送給server(DC)

• DC會生成一個16字節的隨機數,即challenge(挑戰碼),再傳回給client

• 當client收到challenge之後，會先複製一份出來，而後和緩存中的密碼hash再一同混合hash一次,混合後的值稱爲response，以後client再將challenge，response及username一併都傳給server

• server端在收到client傳過來的這三個值之後會把它們都轉發給DC

• 當DC接到過來的這三個值的之後，會根據username到域控的帳號數據庫(ntds.dit)裏面找到該username對應的hash，而後把這個hash拿出來和傳過來的challenge值再混合hash

• 將上一步混合後的hash值跟傳來的response進行比較,相同則認證成功，反之，則失敗，固然，若是是本地登陸,全部驗證確定也所有都直接在本地進行了

Kerberos協議

在域環境中，Kerberos協議被用來做身份認證，下圖是詳細的認證過程：

這裏僅介紹幾個名詞：

• KDC(Key Distribution Center)：密鑰分發中內心麪包含兩個服務：AS和TGS
• AS(Authentication Server)：身份認證服務
• TGS(Ticket Granting Server)：票據授予服務
• TGT(Ticket Granting Ticket)：由身份認證服務授予的票據，用於身份認證，存儲在內存，默認有效期爲10小時
• Pass The Ticket：若是咱們可以拿到用戶的TGT，並將其導入到內存，就能夠冒充該用戶得到其訪問權限

詳細認證過程，分爲三個步驟：

第一:從AS服務器中獲取TGT票據 用戶在客戶端輸入帳號和密碼以後，會對密碼進行hash處理，做爲user-secret-key 1. 客戶端將用戶名發送給AS服務器申請服務,在AS服務器中會對用戶名進行驗證，在AS服務器本地數據庫中查詢到該用戶名的密碼，並使用hash生成user-secrect-key. 2. AS服務器向用戶發送兩樣東西： 1） Client/TGS會話密鑰，使用user-secrect-key進行加密 2） TGT，包含TGS會話密鑰，用戶信息，時間戳，TGT有效期。使用TGS密鑰進行加密 3. 用戶接收到消息以後，回使用本地的user-secret-key對消息1)進行解密，若是解密成功，說明用戶提供的憑證是正確的,此時用戶獲得了加密後的TGT。 
第二:從TGS服務器中獲取訪問權限 1. 客戶端向TGS服務器發送信息： 1） 第一步驟中的TGT 2） 認證信息（認證符(Authenticator)），包含用戶id以及時間戳，經過TGS會話密鑰進行加密。 2. TGS服務器收到消息以後，會使用TGS密鑰對消息1）進行解密,獲取到TGS會話密鑰，進而對消息2）進行解密，在對用戶id以及時間戳進行認證，若是認證成功，向客戶端發送消息： 1） client-server-ticket(包含SS會話密鑰，用戶名信息以及時間戳)，使用ss密鑰進行加密 2） ss會話密鑰使用TGS會話密鑰進行加密 3. 客戶端收到信息以後會對消息2）進行解密，得到ss會話密鑰。 
第三：訪問服務 1. 客戶端向ss服務器發送如下消息： 1）第二步驟中的client-server-ticket 2）新的Authenticator，包含用戶信息，時間戳。經過SS會話密鑰進行加密 2. SS服務器收到消息以後，會使用ss密鑰對消息1）進行解密，解密以後使用ss會話密鑰對消息2）解密，解密成功以後會獲得authenticator，認證以後，發送： 1）新時間戳，Client發送的時間戳加1，經過ss會話密鑰進行加密 3. 客戶端收到時間戳以後，解密確認，成功以後發送服務請求 4. ss服務器收到以後提供服務。

到這裏，windows基本認證步驟完成了，橫向移動的手法請移步個人第五篇文章