Windows認證體系解讀

目錄

Windows認證方式

Windows本地認證

NTLM認證方式(工做組環境中)

wiresharek抓包NTLMv2，使用Hashcat爆破

NTLM認證方式(域環境中)

Kerberos認證方式

認證的應用

哈希傳遞攻擊(PtH)

票據傳遞攻擊(PtT)

---

在這以前，咱們先了解幾個基本的概念

SSPI (Security Service Provider Interface 或 Security Support Provider Interface) 安全服務提供接口，這是 Windows 定義的一套接口，該接口定義了與安全有關的功能函數，包含但不限於：

• 身份驗證機制
• 爲其餘協議提供的 Session Security 機制。Session Security 指的是會話安全，即爲通信提供數據完整性校驗以及數據的加、解密功能

SSP (Security Service Provider) 安全服務提供，SSPI 的實現者，微軟本身實現了以下的 SSP，用於提供安全功能，包含但不限於：

• NTLM SSP
• Kerberos
• Digest SSP

由於 SSPI 中定義了與 Session Security 有關的 API。因此，基本上層應用利用任何 SSP 與遠程的服務進行了身份驗證後，此 SSP 都會爲本次鏈接生成一個隨機 key。這個 key 每每被稱爲 Session Key。上層應用在通過身份驗證後，能夠選擇性地使用這個 Key 對以後發往服務端或接收自服務端的數據進行簽名或加密。

不一樣的 SSP，實現的身份驗證機制是不同的。好比 NTLM SSP 實現的就是一種 Challenge based 身份驗證機制。而 Kerberos 實現的就是基於 Ticket 的身份驗證機制。咱們能夠編寫本身的 SSP，而後註冊到操做系統中，讓操做系統支持更多的自定義的身份驗證方法。

Windows認證方式

認證是什麼？

認證就是認可和證實的意思。 就是你能證實你的身份。 好比你要經過網絡訪問一個受保護的資源，服務器須要認證你的身份。 你能夠聲稱你是系統管理員， 可是你怎麼證實你就是系統管理員呢？方法不少，最簡單直接的方法就是證實你知道系統管理員的密碼。    

認證的問題轉化爲： 「你怎麼證實你知道你所聲稱的用戶的密碼？」 這個問題了。 

一個簡單暴力的證實方法是，讓你直接提供所稱用戶的密碼給服務器，而後服務器去數據庫裏面對比，看你提供的密碼對不對。若是對，認證經過，不然失敗。 常見的所謂 Windows Forms 認證，或者叫作 Windows basic 認證就是這種方式， 簡單直接。 可是密碼須要在網絡上傳輸，安全問題就不說了，你懂的。

 怎樣在不直接提供密碼的狀況下，間接證實你知道密碼呢？ 

看起來很神奇，不是嗎。  好比對面有兩我的在互相說話（通訊），說的都是明文，每一句你都能聽懂。他們並無說本身的密碼就相互認證身份了，你聽了半天，殊不知道密碼是什麼。  更神奇的是， 他們認證以後，再說的話你就更聽不懂了（Session Security，會話安全，若是他們協商會話安全以後，後續的通訊都是安全加密的。）

Windows系統有幾種認證體系：NTLM 和 Kerberos。

NTLM(New Technology LAN Manager)哈希算法，Windows新的密碼管理方式。在Windows2000之後，Windows機器都用NTLM算法在本地保存用戶的密碼，密碼的NTLM哈希保存在 %SystemRoot%\System32\config\SAM 文件中。 在滲透測試中，一般可從 Windows系統中的SAM文件 和 域控的 NTDS.dit 文件中得到全部用戶的Hash。也能夠經過 Mimikatz 讀取 lsass.exe 進程得到已登陸用戶的NTLM hash和明文值 。NTLM認證則是利用NTLM哈希進行的認證，主要有 本地認證 和 網絡認證 兩種方式。NTLM認證是Windows早期的認證方式，因向後兼容性而保留了下來。NTLM適用範圍很是廣，既可用於域內的認證服務， 也可用於沒有域的工做組環境。NTLM 有 NTLMv1 和 NTLMv2 兩個版本，目前使用的都是NTLMv2版本。

Kerberos認證用於域環境中，它是一種基於票據（Ticket）的認證方式。他的整個認證過程涉及到三方：客戶端、服務端和KDC（Key Distribution Center）。在Windows域環境中，由DC(域控)來做爲KDC。

在域環境中，默認先使用kerberos進行認證，當使用kerberos認證出現錯誤時使用NTLM認證。

Access Token(訪問令牌)是用來描述進程或線程安全上下文的對象，令牌所包含的信息是與該用戶帳戶相關的進程或線程的身份和權限信息。當用戶登錄時，系統生成一個Access Token，而後以該用戶身份運行的的全部進程都擁有該令牌的一個拷貝。這也就解釋了A用戶建立一個進程而B用戶沒有該進程的權限。

如今Windows主要用 NTLMv2 和 Kerberos 驗證體系。

無論是 NTLM 仍是 Kerberos 認證，他都是底層的一種認證方式和上層應用無關。NTLM 消息並不和任何傳輸協議綁定，它的認證消息理論上能夠經過任何方式傳遞。好比 NTLM 認證方式應用有 SMB NTLM 認證和 HTTP NTLM 認證。

Windows本地認證

本地登陸時，用戶的密碼存儲在 %SystemRoot%\system32\config\SAM 這個文件裏。當用戶輸入密碼進行本地認證的過程當中，全部的操做都是在本地進行的。他其實就是將用戶輸入的密碼轉換爲NTLM Hash，而後與SAM中的NTLM Hash進行比較。當用戶註銷、重啓、鎖屏後，操做系統會讓winlogon顯示登陸界面，也就是輸入框。當winlogon.exe接收輸入後，將密碼交給lsass進程，這個進程中會存一份明文密碼，將明文密碼加密成NTLM Hash，對SAM數據庫比較認證。(winlogon.exe即Windows Logon Process，是Windows NT用戶登錄程序，用於管理用戶登陸和退出。lsass進程用於微軟Windows系統的安全機制。它用於本地安全和登錄策略。)

好比當用戶輸入密碼123456後，那麼操做系統會將123456轉換爲十六進制，通過Unicode轉換後，再調用MD4加密算法加密，這個加密結果的十六進制就是NTLM Hash

123456 -> hex(16進制編碼) = 313233343536
313233343536 -> Unicode = 610064006d0069006e00
610064006d0069006e00 -> MD4 = 209c6174da490caeb422f3fa5a7ae634

相關文章：Windows中對用戶密碼的處理

NTLM認證方式(工做組環境中)

1. 客戶端須要訪問服務器的某個服務(前提是他得知道服務器的用戶名和密碼)，因此得進行身份認證。因而，客戶端輸入服務器的用戶名和密碼進行驗證，客戶端會緩存服務器密碼的NTLM-Hash值。客戶端發送TYPE 1 Negotiate 協商消息去協商須要認證的主體，用戶(服務器端的用戶名)，機器以及須要使用的安全服務等等信息。
2. 服務端接收到客戶端發送過來的 TYPE 1 消息，會讀取其中的內容，並從中選擇出本身所能接受的服務內容，加密等級，安全服務等等。而後傳入 NTLM SSP，獲得 NTLM_CHALLENGE 消息（被稱爲 TYPE 2 消息，Challenge 挑戰消息），並將此TYPE 2消息發回給客戶端。此TYPE 2消息中包含了一個由服務端生成的16位隨機值，此隨機值被稱爲 Challenge，服務器將該Challenge保存起來
3. 客戶端收到服務端返回的 TYPE 2 消息， 讀取出服務端所支持的內容，並取出其中的隨機值Challenge，用緩存的服務器端密碼的哈希值NTLM-Hash對其進行加密，獲得 Net NTLM-Hash(加密後的Challenge)，而且將Net NTLM-Hash封裝到 NTLM_AUTH 消息中（被稱爲 TYPE 3 消息， Authenticate認證消息），發往服務端
4. 服務器在收到 Type3的消息以後，用本身的密碼的 NTLM-Hash 對 Challenge 進行加密，並比較本身計算出的 Net NTLM-Hash 認證消息和客戶端發送的認證消息是否匹配。若是匹配，則證實客戶端掌握了正確的密碼，認證成功，不然認證失敗。

wiresharek抓包NTLMv2，使用Hashcat爆破

抓的數據包：NTLM2(工做組).pcapng

192.168.10.16(WIN7)——>192.168.10.15(WIN2008)

認證失敗的數據包

認證成功的數據包

查看第二個數據包，得到Challenge，爲：77effc5381037df8

查看第三個數據包，得到客戶端加密後的Challenge，爲：ba3237c701d9f397

Net-NTLM Hash格式爲：username::domain:challenge:HMAC-MD5:blob

• username（要訪問服務器的用戶名）：xie
• domain（訪問者主機名或者ip）：WIN7
• challenge（數據包2中服務器返回的challenge值）：77effc5381037df8
• HMAC-MD5（數據包3中的NTProofStr）: b6b777ced0128e3f587fe08b98853e13
• blob（blob對應數據爲NTLMv2 Response去掉NTProofStr的後半部分）：0101000000000000f27fa3a7aa61d501ba3237c701d9f3970000000002000e00570049004e00320030003000380001000e00570049004e00320030003000380004000e00570049004e00320030003000380003000e00570049004e00320030003000380007000800f27fa3a7aa61d50106000400020000000800300030000000000000000100000000200000ca0ee75c65eaa5367775b826f949798912fa871a19e5d17f9b49587485a8e6620a001000000000000000000000000000000000000900240063006900660073002f003100390032002e003100360038002e00310030002e0031003500000000000000000000000000

因此最後，Net-NTLM Hash值爲：

xie::WIN7:77effc5381037df8:b6b777ced0128e3f587fe08b98853e13:0101000000000000f27fa3a7aa61d501ba3237c701d9f3970000000002000e00570049004e00320030003000380001000e00570049004e00320030003000380004000e00570049004e00320030003000380003000e00570049004e00320030003000380007000800f27fa3a7aa61d50106000400020000000800300030000000000000000100000000200000ca0ee75c65eaa5367775b826f949798912fa871a19e5d17f9b49587485a8e6620a001000000000000000000000000000000000000900240063006900660073002f003100390032002e003100360038002e00310030002e0031003500000000000000000000000000

而後，用Hashcat爆破，傳送門——> 使用Hashcat破解NTLMv2 

NTLM認證方式(域環境中)

1. 用戶經過輸入Windows賬號和密碼登陸客戶端主機，客戶端會緩存密碼的哈希值NTLM-Hash。成功登陸客戶端的用戶若是試圖訪問服務器資源，須要向對方發送一個請求，該請求利用 NTLM SSP 生成 NTLM_NEGOTIATE 消息 （被稱爲 TYPE 1 消息，Negotiate 協商消息），並將 TYPE 1 消息發送給服務端中，該TYPE 1消息中包含一個以明文表示的用戶名以及其餘的一些協商信息(認證的主體，機器以及須要使用的安全服務等等信息)
2. 服務端接收到客戶端發送過來的 TYPE 1 消息，會讀取其中的內容，並從中選擇出本身所能接受的服務內容，加密等級，安全服務等等。而後傳入 NTLM SSP，獲得 NTLM_CHALLENGE 消息（被稱爲 TYPE 2 消息，Challenge 挑戰消息），並將此TYPE 2消息發回給客戶端。此TYPE 2消息中包含了一個由服務端生成的16位隨機值，此隨機值被稱爲 Challenge，服務器將該Challenge保存起來。
3. 客戶端收到服務端返回的 TYPE 2 消息， 讀取出服務端所支持的內容，並取出其中的隨機值Challenge，用緩存的密碼的哈希值NTLM-Hash對其進行加密，獲得 Net NTLM-Hash(加密後的Challenge)，而且將Net NTLM-Hash封裝到 NTLM_AUTH 消息中（被稱爲 TYPE 3 消息， Authenticate認證消息），發往服務端
4. 服務器接收到客戶端發送來的 NTLM_AUTH 的 TYPE 3 消息後，取出其中的Net NTLM-Hash值，並向DC域控（Domain Control）發送針對客戶端的驗證請求。該請求主要包含如下三方面的內容：客戶端用戶名、原始的Challenge 和 加密後的Challenge(也就是Net NTLM-Hash)。
5. DC根據用戶名獲取該賬號的密碼哈希值 NTLM-Hash，用密碼哈希值 NTLM-Hash 對原始的Challenge進行加密獲得Net NTLM-Hash。若是加密後的Challenge和服務器發送的一致，則意味着用戶擁有正確的密碼，驗證經過，不然驗證失敗。DC將驗證結果發給服務器。
6. 服務器根據DC返回的結果，對客戶端進行回覆

192.168.10.16(WIN7)——>192.168.10.152(WIN2003)          域控：192.168.10.15(WIN2008)

Kerberos認證方式

Kerberos其實是一種基於票據（Ticket）的認證方式。客戶端要訪問服務器的資源，須要首先購買服務端承認的ST服務票據。也就是說，客戶端在訪問服務器以前須要預先買好票，等待服務驗票以後才能入場。可是這張票不能直接購買，須要一張TGT認購權證（Ticket Granting Ticket)。也就是說，客戶端在買票以前必須先得到一張TGT認購權證。這張TGT認購權證和ST服務票據均由KDC發售。

簡寫	全拼
DC	Domain Controller：域控
KDC	Key Distribution Center：密鑰分發中心，由域控擔任
AD	Active Directory：活動目錄，裏面包含域內用戶數據庫
KAS	Kerberos Authentication Service：Kerberos認證服務
TGT	Ticket Granting Ticket：票據中心授予的認購權證
TGS	Ticket Granting Service：票據授予服務
ST	Service Ticket：ST服務票據

如何得到認購權證？

首先，咱們來看看客戶端如何得到 TGT認購權證。TGT是KDC的KAS認證服務（Kerberos Authentication Service）發放的。

一、當某個用戶經過輸入域賬號和密碼試圖登陸某臺主機的時候，本機的Kerberos服務會向KDC的KAS認證服務發送一個認證請求。該請求主要包括兩部份內容，明文形式的用戶名 和 用用戶祕鑰加密原始Authenticator後獲得的加密後Authenticator(Authenticator是客戶端和服務端能夠用於驗證對方身份的一個東西)。

二、當KDC接收到請求以後，經過AD活動目錄查詢該用戶名獲得該用戶的信息。經過查詢獲得的密碼信息對Authenticator進行解密獲得 原始的 Authenticator。若是解密後 的Authenticator 和已知的 Authenticator 一致，則證實請求者提供的密碼正確，即肯定了登陸者的真實身份。KAS成功認證對方的身份以後，會先生成一個 用用戶密碼加密後的用於確保該用戶和KDC之間通訊安全的Logon Session Key會話祕鑰。KAS接着爲該用戶建立 TGT認購權證。TGT主要包含兩方面的內容：用戶相關信息 和 原始Logon Session Key，而整個TGT則經過KDC本身的密鑰進行加密。最終，被不一樣密鑰加密的Logon Session Key 和 TGT返回給客戶端。

如何得到ST服務票據？

通過上面的步驟，客戶端獲取了進入同域中其餘主機入場券的 TGT認購權證 和 Logon Session Key，而後用本身的密鑰解密Logon Session Key獲得 原始的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和訪問的服務器名(實際上是服務)。

4.、TGS接收到請求以後，經過本身的祕鑰解密TGT並獲得原始Logon Session Key，而後經過Logon Session Key解密Authenticator，進而驗證了對方的真實身份。TGS完成對客戶端的認證以後，會生成一個用Logon Session Key加密後的用於確保客戶端-服務器之間通訊安全的Service Session Key會話祕鑰。而後爲該客戶端生成ST服務票據。ST服務票據主要包含兩方面的內容：客戶端用戶信息 和 原始Service Session Key，整個ST經過服務器密碼派生的祕鑰進行加密。最終兩個被加密的Service Session Key和ST回覆給客戶端。

如何用ST服務票據雙向認證？

五、客戶端接收到TGS回覆後，經過緩存的Logon Session Key解密獲得原始Service Session Key，同時它也獲得了進入服務器ST服務票據。該Serivce Session Key和ST服務票據會被客戶端緩存。客戶端訪問某服務器資源，將ST服務票據和Service Session Key加密的Authenticator發送給服務端。

六、服務器收到客戶端發來的ST服務票據。可是，服務端如何確保客戶端發來的ST服務票據是經過TGS購買，而不是本身僞造的呢？這很好辦，不要忘了ST是經過服務器本身密碼派生的祕鑰進行加密的。具體的操做過程是這樣的，服務器在接收到請求以後，先經過本身密碼派生的祕鑰解密ST，並從中提取Service Session Key。而後經過提取出來的Service Session Key解密Authenticator，進而驗證了客戶端的真實身份。實際上，到目前爲止，服務端已經完成了對客戶端的驗證，可是，整個認證過程尚未結束。談到認證，不少人都認爲只是服務器對客戶端的認證，實際上在大部分場合，咱們須要的是雙向驗證（Mutual Authentication），即訪問者和被訪問者互相驗證對方的身份。如今服務器已經能夠確保客戶端是它所聲稱的那麼用戶，客戶端尚未確認它所訪問的不是一個釣魚服務呢。爲了解決客戶端對服務器的驗證，服務端須要將解密後的Authenticator再次用Service Session Key進行加密，併發揮給客戶端。客戶端再用緩存的Service Session Key進行解密，若是和以前的內容徹底同樣，則能夠證實本身正在訪問的服務器和本身擁有相同的Service Session Key。雙向認證事後，開始了服務資源的訪問。

下面是完成的Kerberos認證的過程：

認證的應用

在域環境下，可使用 Kerberos 或者 NTLM認證來實現對用戶的身份認證。在不少企業的內部網絡中(基本都是域環境)，都是使用Kerberos認證或NTLM認證，在Windows 2000之後，在域環境下，Kerberos是默認的認證方式。由於因爲NTLM認證存在安全風險，因此用Kerberos認證的較多。Kerberos較之NTLM更高效、更安全，同時認證過程也相對複雜。

在非域環境下，通常都是使用NTLM進行認證。SMB服務和不少Web程序都是使用NTLM來實現對用戶的身份認證。

哈希傳遞攻擊(PtH)

從上面的NTLM認證咱們能夠知道，實現身份認證，並不須要密碼的原文，而只要擁有密碼的NTLM哈希值便可。因而，咱們能夠千方百計經過其餘手段截獲到其餘人的NTLM哈希值，即可以經過此NTLM哈希值來以該用戶的身份認證，實現冒名登陸。這就是NTLM Relay攻擊，也就是Pass-the-Hash（PtH）哈希傳遞攻擊。傳送門——> 哈希傳遞攻擊(Pass-the-Hash,PtH)

票據傳遞攻擊(PtT)

票據傳遞攻擊（PtT）是一種使用Kerberos票據代替明文密碼或NTLM哈希的方法。PtT最多見的用途多是使用黃金票據和白銀票據，經過PtT訪問主機至關簡單。傳送門——> 票據傳遞攻擊(Pass the Ticket,PtT)

 

參考文章：【Windows】認證及抓密碼

                  http://www.cnblogs.com/artech/archive/2011/01/25/NTLM.html

                  http://www.cnblogs.com/artech/archive/2011/01/24/kerberos.html

                  http://www.javashuo.com/article/p-bqnqaunz-mq.html

相關文章：滲透技巧——利用netsh抓取鏈接文件服務器的NTLMv2 Hash