windows認證協定主要有以下兩種:
- 基于ntlm的認證方式,主要用在早期的windows工作組環境中,認證的過程也相對比較簡單、
- 另一種是基于Kerberos的認證方式,主要用在域環境中
NTLM認證
正在上傳…重新上傳取消
以下步驟刻畫了 NTLM 非互動式認證過程， 第一步中提供了使用者的 NTLM 認證資訊，該步是使用者互動式認證（Logon）過程的一部分。
- （互動式登入到某客戶機）使用者使用：域名、使用者名、密碼，登陸到某台用戶端。用戶端計算并存儲使用者密碼的加密散列值（Hash），然後将真實的密碼丢掉（即不儲存使用者真實的密碼）
- 用戶端将使用者名以純文字的方式發送到要通路的伺服器
- 伺服器産生一個 16 位元組的随機數并将該随機數發送給用戶端，該随機數通常稱為：挑戰（Challenge）
- 用戶端使用使用者密碼的散列值加密伺服器發送過來的 Challenge，并将結果發回給伺服器， 該步驟通常稱為：應答 （Response）
- 伺服器将下面三項内容發送到域控制器 （Domain Controller）
- 使用者名
- 發送給用戶端的 Challenge
- 從用戶端收到的 Response
7.域控制器使用 使用者名 從安全賬号管理資料庫 （Security Account Manager database）中獲得使用者密碼的散列值， 并使用獲得的密碼散列值來加密 Challenge
8.域控制器比較步驟（6）中計算得到的加密後的 Challenge值與步驟（4）中用戶端加密得到的 Response，如果兩者一緻，則認證通過
NTLM是一種基于挑戰（challenge）/響應（response）消息互動模式的認證過程,從整個認證過程來看,安全确實不怎麼到位,也就是說入侵者隻需要拿到一個系統管理者的hash,直接給dc認證就好了,反正賬戶名和域名都知道,早期的pass the hash (psexec)确實就是通過這種方式來進行的,如果本地管理者的賬号密碼相同,其實不用密碼一樣可以被認證,我們所要做的就是不斷通過這種方式來嘗試拓展内網的其他機器,直到控制整個域,但後來的kb2871997,似乎改變了一些現狀,但也可能隻是似乎
總結：
- 使用者登入用戶端電腦
- (type 1)用戶端向伺服器發送type 1(協商)消息,它主要包含用戶端支援和伺服器請求的功能清單。
- (type 2)伺服器用type 2消息(質詢)進行響應，這包含伺服器支援和同意的功能清單。但是，最重要的是，它包含伺服器産生的Challenge。
- (type 3)用戶端用type 3消息(身份驗證)回複質詢。使用者接收到步驟3中的challenge之後，使用使用者hash與challenge進行加密運算得到response，将response,username,challeng發給伺服器。消息中的response是最關鍵的部分，因為它們向伺服器證明用戶端使用者已經知道帳戶密碼。
- 伺服器拿到type 3之後，使用challenge和使用者hash進行加密得到response2與type 3發來的response進行比較。如果使用者hash是存儲在域控裡面的話，那麼沒有使用者hash，也就沒辦法計算response2。也就沒法驗證。這個時候使用者伺服器就會通過netlogon協定聯系域控，建立一個安全通道,然後将type 1,type 2，type3 全部發給域控(這個過程也叫作Pass Through Authentication認證流程)
- 域控使用challenge和使用者hash進行加密得到response2，與type 3的response進行比較
參考：https://klionsec.github.io/2016/08/10/ntlm-kerberos/
https://blog.csdn.net/qq_26886929/article/details/53905654