0x01 Windows本地認證
a. 概述
Windows本地認證采用sam hash比對的形式來判斷用戶密碼是否正確。
計算機本地用戶的所有密碼被加密存儲在%SystemRoot%\system32\config\SAM文件中，當我們登錄系統的時候,系統會自動地讀取SAM文件中的“密碼”與我們輸入的密碼進行比對，如果相同，證明認證成功.。
本地認證的過程其實就是Windows把用戶輸入的密碼憑證和sam里的加密hash比對的過程。
b. 加密方式
Windows對用戶密碼憑證有兩種加密算法，NTLM和LM。
1. LAN Manager Hash（LM）
LM Hash(LAN Manager Hash) 是windows最早用的加密算法，由IBM設計。LM Hash 使用硬編碼秘鑰的DES，且存在缺陷。早期的Windows系統如XP、Server 2003等使用LM Hash，而后的系統默認禁用了LM Hash並使用NTLM Hash。
作為早期的算法，LM Hash存在着諸多問題：
- 密碼長度不會超過14字符，且不區分大小寫
- 如果密碼長度小於7位，后一組哈希的值確定，可以通過結尾為
aad3b435b51404ee來判斷密碼長度不超過7位- 分組加密極大程度降低了密碼的復雜度
- DES算法強度低
2. NT LAN Manager Hash（NTLM）
為了解決LM Hash的安全問題，微軟於1993年在Windows NT 3.1中引入了NTLM協議。
Windows 2000 / XP / 2003 在密碼超過14位前使用LM Hash，在密碼超過14位后使用NTLM Hash。而之后從Vista開始的版本都使用NTLM Hash。
NTLM Hash的計算方法為：
- 將密碼轉換為16進制，進行Unicode編碼
- 基於MD4計算哈希值
3. 內部認證流程
本地認證中用來處理用戶輸入密碼的進程即lsass.exe，密碼會在這個進程中明文保存，供該進程將密碼計算成NTLM Hash與sam進行比對我們使用mimikatz來獲取的明文密碼，便是在這個進程中讀取到的。
0x02 Windows網絡認證
a. 概述
網絡認證即在工作組環境下遠程登陸另一台電腦所采用的認證機制。
假設A主機與B主機屬於同一個工作組環境，A想訪問B主機上的資料，需要將一個存在於B主機上的賬戶憑證發送至B主機，經過認證才能夠訪問B主機上的資源。只能點對點，是比較落后的認證方式，沒有信托機構。
例如：FTP、SMB
b. 協議出現
早期SMB協議在網絡上傳輸明文口令。后來出現LAN Manager Challenge/Response驗證機制，簡稱LM。因為相應加密算法比較脆弱很容易就被破解。
微軟提出了 Windows挑戰響應驗證機制，稱之為NTLM。現在已經有了更新的 NTLMv2以 Kerberos驗證體系。
c. 挑戰響應機制
NTLM協議的認證過程分為三步：
- 協商
- 質詢
- 驗證
1. 協商
雙方確定使用的協議版本，NTLM存在V1和V2兩個版本，具體區別就是加密方式不同
2. 質詢（核心）
-
客戶端向服務器端發送用戶信息（用戶名）請求
-
服務器接受到請求后，判斷本地用戶列表是否存在客戶端發送的用戶名，如果沒有返回認證失敗，如果有，生成一個16位的隨機數，被稱之為“Challenge”， 然后使用登錄用戶名對應的NTLM Hash加密Challenge(16位隨機字符)， 生成Challenge1保存在內存中。同時，生成Challenge1后，將Challenge(16位隨機字符)發送給客戶端。
-
客戶端接受到Challenge后，使用自己提供的賬戶的密碼轉換成對應的NTLM Hash，然后使用這個NTLM Hash加密Challenge生成Response，然后將Response發送至服務器端。
3. 驗證
服務端收到客戶端發送的Response后，與之前保存在內存中的Channelge1比較，如果相等認證通過。
d. 相關知識點
經過NTLM Hash加密Challenge的結果在網絡協議中稱之為Net NTLM Hash。
網絡中沒有傳輸與密碼本身相關的任何數據。
NTML v2
- Challage：NTLM v1的 Challenge有8位, NTLM v2的 Challenge為
16位。 - Net-NTLM Hash：NTLM v1的主要加密算法是DES，NTLM v2的
主要加密算法是HMAC-MD5。
Pass The Hash（哈希傳遞）
在域環境中，用戶登錄計算機時使用的大都是域賬號，大量計算機在安裝時會使用相同的本地管理員賬號和密碼，因此，如果計算機的本地管理員賬號和密碼也是相同的，攻擊者就能使用哈希傳遞攻擊的方法登陸內網中的其他計算機。
使用條件
- 哈希傳遞需要被認證的主機能夠訪問到服務器
- 哈希傳遞需要被傳遞認證的用戶名
- 哈希傳遞需要被傳遞認證用戶的 NTLM Hash
利用工具
- Smbmap
- CrackMapExec
- Smbexec
- Metasploit
0x03 Acitve Directory（活動目錄）
a. 概述
活動目錄（Active Directory）是指域環境中提供目錄服務的組件。
目錄用於存儲有關網絡對象的信息。
目錄服務是指幫助用戶快速、准確地從目錄中找到其所需要的服務。
活動目錄實現了目錄服務，為企業提供了網絡環境的集中式管理機制。
b. 功能
活動目錄(Active Directory)主要提供以下功能：
- 服務器及客戶端計算機管理：管理服務器及客戶端計算機賬戶，所有服務器及客戶端計算機加入域管理並實施組策略。
- 用戶服務：管理用戶域賬戶、用戶信息、企業通訊錄（與電子郵件系統集成）、用戶組管理、用戶身份認證、用戶授權管理等，按省實施組管理策略。
- 資源管理：管理打印機、文件共享服務等網絡資源。
- 桌面配置：系統管理員可以集中的配置各種桌面配置策略，如：用戶使用域中資源權限限制、界面功能的限制、應程序執行特征限制、網絡連接限制、安全配置限制等。
- 應用系統支撐：支持財務、人事、電子郵件、企業信息門戶、辦公自動化、補丁管理、防病毒系統等各種應用系統。
c. 域認證體系 - Kerbroes
1. 概述
Kerberos是一種網絡認證體系，其設計目標是通過密鑰系統為客戶機/服務器應用程序提供強大的認證服務。
該認證過程的實現不依賴於主機操作系統的認證，無需基於主機地址的信任，不要求網絡上所有主機的物理安全，並假定網絡上傳送的數據包可以被任意的讀取、修改和插入數據。在以上情況下，Kerberos作為一種可信任的第三方認證服務，是通過傳統的密碼技術執行認證服務的。
2. 域認證角色
- Client
- Server
- KDC（域控制器）
- AD（account database）：存儲Client白名單
- AS（Authentication Service）：為Client生成TGT服務
- TGT（Ticket Granting Service）：為Client生成某個服務的ticket
3. 認證流程
- KDC(Key Distribution Center)：密鑰分發中心，里面包含兩個服務：AS和TGS
- AS(Authentication Server)：身份認證服務
- TGS(Ticket Granting Server)：票據授予服務,該服務提供的票據也稱為 TGS 或者叫白銀票據
- TGT(Ticket Granting Ticket)：由身份認證服務授予的票據(黃金票據)，用於身份認證，存儲在內存，默認有效期為10小時
詳解kerberos認證流程此篇文章講的十分詳細，建議參考。
第一次通信
為了獲得能夠用來訪問服務端服務的票據，客戶端首先需要來到KDC獲得服務授予票據（Ticket）。由於客戶端是第一次訪問KDC，此時KDC也不確定該客戶端的身份，所以第一次通信的目的為KDC認證客戶端身份，確認客戶端是一個可靠且擁有訪問KDC權限的客戶端，過程如下：
① 客戶端用戶向KDC以明文的方式發起請求。該次請求中攜帶了自己的用戶名，主機IP，和當前時間戳；
② KDC當中的AS（Authentication Server）接收請求（AS是KDC中專門用來認證客戶端身份的認證服務器）后去kerberos認證數據庫中根據用戶名查找是否存在該用戶，此時只會查找是否有相同用戶名的用戶，並不會判斷身份的可靠性；
③ 如果沒有該用戶名，認證失敗，服務結束；如果存在該用戶名，則AS認證中心便認為用戶存在，此時便會返回響應給客戶端，其中包含兩部分內容：
- 第一部分內容稱為TGT，他叫做票據授予票據，客戶端需要使用TGT去KDC中的TGS（票據授予中心）獲取訪問網絡服務所需的Ticket（服務授予票據），TGT中包含的內容有kerberos數據庫中存在的該客戶端的Name，IP，當前時間戳，客戶端即將訪問的TGS的Name，TGT的有效時間以及一把用於客戶端和TGS間進行通信的Session_key(CT_SK)。整個TGT使用TGS密鑰加密，客戶端是解密不了的，由於密鑰從沒有在網絡中傳輸過，所以也不存在密鑰被劫持破解的情況。
- 第二部分內容是使用客戶端密鑰加密的一段內容，其中包括用於客戶端和TGS間通信的Session_key(CT_SK),客戶端即將訪問的TGS的Name以及TGT的有效時間，和一個當前時間戳。該部分內容使用客戶端密鑰加密，所以客戶端在拿到該部分內容時可以通過自己的密鑰解密。如果是一個假的客戶端，那么他是不會擁有真正客戶端的密鑰的，因為該密鑰也從沒在網絡中進行傳輸過。這也同時認證了客戶端的身份，如果是假客戶端會由於解密失敗從而終端認證流程。
至此，第一次通信完成。
第二次通信
此時的客戶端收到了來自KDC（其實是AS）的響應，並獲取到了其中的兩部分內容。此時客戶端會用自己的密鑰將第二部分內容進行解密，分別獲得時間戳，自己將要訪問的TGS的信息，和用於與TGS通信時的密鑰CT_SK。首先他會根據時間戳判斷該時間戳與自己發送請求時的時間之間的差值是否大於5分鍾，如果大於5分鍾則認為該AS是偽造的，認證至此失敗。如果時間戳合理，客戶端便准備向TGS發起請求，其次請求的主要目的是為了獲取能夠訪問目標網絡服務的服務授予票據Ticket（進入動物園需要的門票）。 在第二次通信請求中，客戶端將攜帶三部分內容交給KDC中的TGS，第二次通信過程具體如下所述：
客戶端行為：
① 客戶端使用CT_SK加密將自己的客戶端信息發送給KDC，其中包括客戶端名，IP，時間戳；
② 客戶端將自己想要訪問的Server服務以明文的方式發送給KDC；
③ 客戶端將使用TGS密鑰加密的TGT也原封不動的也攜帶給KDC；
TGS行為：
① 此時KDC中的TGS（票據授予服務器）收到了來自客戶端的請求。他首先根據客戶端明文傳輸過來的Server服務IP查看當前kerberos系統中是否存在可以被用戶訪問的該服務。如果不存在，認證失敗結束。如果存在，繼續接下來的認證。
② TGS使用自己的密鑰將TGT中的內容進行解密，此時他看到了經過AS認證過后並記錄的用戶信息，一把Session_KEY即CT_SK，還有時間戳信息，他會現根據時間戳判斷此次通信是否真是可靠有無超出時延。
③ 如果時延正常，則TGS會使用CK_SK對客戶端的第二部分內容進行解密（使用CT_SK加密的客戶端信息），取出其中的用戶信息和TGT中的用戶信息進行比對，如果全部相同則認為客戶端身份正確，方可繼續進行下一步。
④ 此時KDC將返回響應給客戶端，響應內容包括：
- 第一部分：用於客戶端訪問網絡服務的使用Server密碼加密的ST（Servre Ticket），其中包括客戶端的Name，IP，需要訪問的網絡服務的地址Server IP，ST的有效時間，時間戳以及用於客戶端和服務端之間通信的CS_SK（Session Key）。
- 第二部分：使用CT_SK加密的內容，其中包括CS_SK和時間戳，還有ST的有效時間。由於在第一次通信的過程中，AS已將CT_SK通過客戶端密碼加密交給了客戶端，且客戶端解密並緩存了CT_SK，所以該部分內容在客戶端接收到時是可以自己解密的。
至此，第二次通信完成。
第三次通信
此時的客戶端收到了來自KDC（TGS）的響應，並使用緩存在本地的CT_SK解密了第二部分內容（第一部分內容中的ST是由Server密碼加密的，客戶端無法解密），檢查時間戳無誤后取出其中的CS_SK准備向服務端發起最后的請求。
客戶端：
① 客戶端使用CK_SK將自己的主機信息和時間戳進行加密作為交給服務端的第一部分內容，然后將ST（服務授予票據）作為第二部分內容都發送給服務端。
服務端：
① 服務器此時收到了來自客戶端的請求，他會使用自己的密鑰，即Server密鑰將客戶端第二部分內容進行解密，核對時間戳之后將其中的CS_SK取出，使用CS_SK將客戶端發來的第一部分內容進行解密，從而獲得經過TGS認證過后的客戶端信息，此時他將這部分信息和客戶端第二部分內容帶來的自己的信息進行比對，最終確認該客戶端就是經過了KDC認證的具有真實身份的客戶端，是他可以提供服務的客戶端。此時服務端返回一段使用CT_SK加密的表示接收請求的響應給客戶端，在客戶端收到請求之后，使用緩存在本地的CS_ST解密之后也確定了服務端的身份（其實服務端在通信的過程中還會使用數字證書證明自己身份）。至此，第三次通信完成。此時也代表着整個kerberos認證的完成，通信的雙方都確認了對方的身份，此時便可以放心的進行整個網絡通信了。
