摘自https://www.colabug.com/2018/0917/4557747/ 寫的太好了
LM Hash、NTLM Hash、Net-NTLM Hash的區別與聯系
LM Hash
LM Hash是一種較古老的Hash，在LAN Manager協議中使用，非常容易通過暴力破解獲取明文憑據。Vista以前的Windows OS使用它，Vista之后的版本默認禁用了LM協議，但某些情況下還是可以使用。
NTLM Hash
Vista以上現代操作系統使用的Hash。通常意義上的NTLM Hash指存儲在SAM數據庫及NTDS數據庫中對密碼進行摘要計算后的結果，這類Hash可以直接用於PtH，並且通常存在於 lsass 進程中，便於 SSP 使用
Net-NTLM Hash
Net-NTLM Hash用於網絡身份認證（例如ntlm認證中），目前分為兩個版本：
- Net-NTLMv1
- Net-NTLMv2
通常我們使用Responder等工具獲取到的就是NetNTLM，這類hash並不能直接用來PtH，但可以通過暴力破解來獲取明文密碼
Net-NTLM出現在NTLM認證過程中，其計算過程依賴NTLM Hash
參考資料： https://medium.com/@petergombos/lm-ntlm-net-ntlmv2-oh-my-a9b235c58ed4
NTLM認證
本文提到的NTLM認證特指Microsoft NTLM Protocol。
工作組環境
NTLM認證 是一種在網絡上進行認證的安全協議，其主要過程粗略地分為三步：
- 客戶端發起認證請求
- 服務端收到認證請求，向客戶端發送隨機數（chanlleng/挑戰）
- 客戶端使用NTLM Hash打亂該隨機數，生成Net-NTLM Hash，發送回服務端
上面的過程發生在工作組環境中，在域環境中使用NTLM Pass-Through認證，核心過程與工作組沒有太大區別：
主要區別在於Server會將認證信息使用netlogon協議發送給域控制器，由域控制器完成檢驗並返回認證結果
參考資料： http://davenport.sourceforge.net/ntlm.html
網絡登錄與非網絡登錄
網絡登陸
在網絡登錄過程中不使用憑證輸入對話框來收集數據，而會使用到預先生成的憑據。
非網絡登陸
分為網絡明文登陸和交互式登陸等。這些登錄類型在認證期間將用戶明文密碼發送到服務器。 服務器可以在LSASS中緩存這個密碼或其處理后的值，並使用它來驗證其他資源。
網絡登錄與NTLM認證
NTLM認證出現在網絡登錄中，而遠程服務器不緩存用戶憑據，這也與ntlm認證的特性相吻合。 Double-Hop的問題也與網絡/非網絡登錄的性質有關。
PtH攻擊原理
注意：本文所指均為狹義上的Pass-the-Hash，即一種在NTLM認證中使用NTLM Hash進行認證的手段
在上面的三步過程中，我們發現並沒有使用到用戶提供的明文密碼，而是使用NTLM Hash來計算NetNTLM Hash。Hash傳遞攻擊就發生在NTLM認證的第三步，我們能使用獲取到的NTLM Hash來完成一次完整的認證。
PtH操作演示
靶機ip：
攻擊機ip：
以mimikatz為例，在攻擊機上以管理員身份運行mimikatz：
在攻擊之前我們需要知道目標賬戶名以及hash值，這里我們假設獲取到了ntlm hash：
我們使用mimikatz來pth：
這里需要domain，user，ntlm以及打開的程序四個參數。默認情況下打開cmd。 我們知道，pth只是一種無明文認證的手段，我們還需要針對具體的服務進行攻擊，這里以smb服務為例。通常我們訪問一個unc路徑時，不考慮double-hop的情況下，如果沒有指定windows會自動用當前用戶的憑據進行ntlm認證，例如命令dir \Targetaaa。由於windows某些ssp會在lsass中緩存hash值，並使用它們來ntlm認證，那么理論上我們如果在lsass中添加包含目標賬戶的hash的合法數據結構，就可以在使用類似dir這些命令時用目標賬戶進行認證，這也是mimikatz中pth功能的原理。 上一步里面我們已經用mimikatz修改了內存中的hash值，那么我們就能利用彈出的cmd來測試一下是否能網絡登錄目標系統，訪問c$共享。 這里使用的exist用戶是非內置管理員用戶，盡管c$共享允許管理員組成員訪問，但由於uac對網絡登錄的限制，導致直接訪問會被Access Died：
出於演示的需要，我們把靶機上的UAC級別設置為從不通知並重啟,再次pth：
能成功訪問c$共享。
緩解手段及其局限性或可能的繞過方式
試圖緩解PtH的危害可以從兩個方面入手（當然不僅僅是這兩方面）：
- 禁止NTLM認證
- 防止NTLM Hash被獲取到
第一種方式當然是一勞永逸地阻止了PtH，但是NTLM認證已經被微軟使用了很長時間，完全禁止可能會破壞已部署的一些環境，在實際應用中阻力較大。 由於NTLM認證的天然缺陷，微軟似乎很難改變其行為，因此更多地把防御放在了阻止Hash被獲取到這種思路。下面我們來介紹微軟發布的一些補丁以及它們可能的繞過方式。
kb2871997
kb2871997在緩解PtH上做出了不少努力，其為windows增加的特性值得深入研究。它在win server 2012 R2及以上版本已默認集成。 根據 微軟公告 ，安裝kb2871997后會有這么些行為：
刪除lsass的明文憑證
我們前面提到過，lsass進程會緩存用戶憑據，有明文有Hash，這取決於使用的ssp類型以及補丁情況。
上圖中msv、tspkg、wdigest、kerberos這幾個ssp都獲取到了憑據，它們分別用於Terminal Server認證（RDSH），ntlm認證，摘要認證以及kerberos認證。我們能看到只有msv沒有明文密碼。從前文中對ntlm認證過程的描述，我們可以發現除了第一步客戶端要求用戶輸入明文密碼，之后的認證過程再也沒有出現過明文密碼。這也就是說，ssp只需要計算ntlm hash並放在內存中就行了。 我們看到摘要認證wdigest在windows 2008 中緩存了明文密碼。摘要認證類似於ntlm認證，也使用了挑戰-響應機制，但它與ntlm認證較大的區別在於客戶端計算響應時，需要使用到明文密碼，為了實現SSO，需要將明文密碼放在內存中方便進行計算，因此客戶端一方的ssp理論上必須在內存中緩存明文密碼，這也是為什么我們能抓到明文密碼的原因；與之相比，NTLM SSP使用的單向函數如NTOWFv2只需要計算一次並放置在內存中，之后計算響應只需要這個hash值即可。
kb2871997會刪除除了wdigest ssp以外其他ssp的明文憑據，但對於wdigest ssp只能選擇禁用。用戶可以選擇將HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersWDigestUseLogonCredential更改為0來禁用。
安裝kb2871997之后我們使用mimikatz抓取內存中的密碼：
wdigest ssp默認仍然在內存中存儲明文密碼，更改注冊表后注銷，重新登錄，再次抓取：
wdigest已經抓不到明文密碼以及密碼hash。
這僅僅是增大了從內存中獲取ntlm hash的難度，但並不能阻止從注冊表等其他地方獲取。
能夠禁止用戶網絡登錄
下圖中，工作組環境可以在本地安全策略->用戶權限分配->拒絕從網絡訪問這台計算機配置是否允許用戶或用戶組網絡登錄：
理論上UAC無法限制RID為500的用戶網絡登錄，但打補丁並配置好禁止administrator(RID==500)網絡登錄，測試結果如下：
處理方式太過粗暴，可能會影響用戶正常需求。
添加“受限管理員模式”
受限管理員模式能阻止主機緩存內存中遠程驗證用戶的憑據。 我們來做兩個測試
- 測試一： RDP客戶端使用微軟自家的mstsc，服務端未打kb2871997，不加任何參數啟動：
- 啟動連接，客戶端要求我們輸入用戶名和密碼：
- 登錄成功后，使用mimikatz獲取內存中的密碼：
- 我們能夠獲取到明文密碼，ntlmssp的NTLM Hash也能獲取到，這里就不再截圖了。
測試二：客戶端使用mstsc /restrictedadmin，也即受限管理員模式啟動，服務端支持受限管理員模式：
我們發現mstsc提示將使用我們到windows登錄憑據進行連接。 如果客戶端和服務端有相同用戶名和密碼的賬戶，可以直接連接成功，沒有彈出要求輸入憑據的對話框。連接成功后，使用mimikatz獲取內存中的密碼：
我們發現遠程桌面會話沒有緩存用戶憑據，這其實就是受限管理員模式的特性。 下面我們來聊聊為什么會出現這種情況：
- 遠程桌面默認無約束委派用戶憑據，以達到完全在遠程服務器上代表用戶的目的。當我們連接到遠程桌面服務器上，可以使用dir命令連接其他的smb服務器並使用我們的憑據認證，這是因為客戶端進行遠程桌面連接的時候會發送用戶的明文密碼，這個密碼可以用於計算NTLM Hash並緩存在遠程桌面服務器上。
- 受限管理員模式下，遠程桌面客戶端會首先使用客戶端機器上已緩存的NTLM Hash進行認證，不需要用戶輸入用戶名和密碼，也就不會把明文密碼委派到目標；即便緩存的hash認證失敗，用戶必須輸入明文密碼，mstsc也不會直接發送明文密碼，而是計算出所需的值后再發送。這種模式下，登錄到遠程桌面服務器上並使用dir命令向其他smb服務器認證時，將使用空用戶(用戶名 )登錄，幾乎都會登陸失敗。
從上面兩種模式對比可以看出，客戶端直接發送明文密碼到服務端，可能會被mimikatz從內存中獲取到；而受限管理員模式則能避免發送明文，服務端內存中也不會緩存用戶憑據。
“受限管理員模式”的初衷是為了保護遠程桌面服務端，即當服務端被攻陷時，使用受限管理員模式可以在一定程度上保護客戶端用戶的憑據不被mimikatz等工具獲取到。因此，這個保護措施並不是直接針對PtH，效果也是有限的。 實際上受限管理員模式本身就會增加新的攻擊路徑，即可以以PtH的方式向遠程桌面服務器發起認證。也就是說，在實際應用中，我們可以利用mimikatz的sekurlsa::pth來啟動mstsc，使用受限管理員模式來無明文密碼登錄，當然也有些其他的RDP客戶端可以實現利用密碼Hash來認證，例如FreeRDP。
Protected Users
受保護用戶是一個新的域全局安全組，對於該組的成員，Windows 8.1設備或Windows Server 2012 R2主機不會緩存受保護用戶不支持的憑據。如果這些組的成員登錄到運行早於Windows 8.1的Windows版本的設備，則該組的成員沒有其他保護。
登錄到Windows 8.1設備和Windows Server 2012 R2主機的受保護用戶組的成員不能再使用：
- 默認憑據委派（CredSSP） – 即使啟用了“ 允許委派默認憑據”策略，也不會緩存純文本憑據
- Windows摘要 – 即使啟用明文憑據也不會進行緩存
- NTLM – NTOWF未緩存
- Kerberos長期密鑰 – Kerberos票證授予票證（TGT）在登錄時獲取，無法自動重新獲取
- 離線登錄 – 未創建緩存的登錄驗證程序
如果域功能級別是Windows Server 2012 R2，則該組的成員不能再：
- 使用NTLM身份驗證進行身份驗證
- 在Kerberos預身份驗證中使用數據加密標准（DES）或RC4密碼套件
- 通過使用無約束或約束委派來委派
- 更新用戶票證（TGT）超過最初的4小時生命周期
在域賬戶未加入Protected Users組時，我們使用mimikatz獲取內存中的憑據：
我們可以看到ntlmssp緩存了emanon賬戶的密碼hash。我們將此用戶加入Protected Users:
注銷，重新登錄，再次使用mimikatz抓取密碼：
emanon用戶的ntlm hash已經無法獲取到，但機器賬戶DM1$以及本地用戶的hash仍然能獲取到，這也說明Protected Users保護范圍是有限的。 網上有些文章提到了Pass-the-Key（Overpass-the-hash），Protected Users對這種攻擊方式也有一定緩解功能。PtK是在域中攻擊kerberos認證的一種方式，據稱可以在NTLM認證被禁止的情況下用來實現類似PtH的功能（畢竟是針對kerberos認證，其實與NTLM認證沒什么關系）。關於這種攻擊方式可以查看本節的參考，這里不再贅述。我們比較關心使用mimikatz來Pass-the-Key所需要的信息，其中必須有的是請求tgt所需的用戶hash，這可以使用mimikatz中的sekurlsa::ekeys來獲取：
經測試，域功能級別為windows server 2012 R2（未測試低等級），將域用戶加入Protected Users用戶組后無法通過ekeys命令獲取Hash。當然，機器賬戶還是能夠獲取到。
Protected Users是一個域安全組，僅能在域中保護用戶，並且阻止抓取用戶Hash並沒有直面PtH這種攻擊方式，域用戶憑據仍可能通過注冊表Cache、釣魚攻擊等方式獲取到。
參考資料： https://www.blackhat.com/docs/us-14/materials/us-14-Duckwall-Abusing-Microsoft-Kerberos-Sorry-You-Guys-Don’t-Get-It-wp.pdf
Additional LSA Protection
LSA（包括本地安全機構服務器服務（LSASS）進程）驗證用戶是否進行本地和遠程登錄，並實施本地安全策略。Windows 8.1操作系統為LSA提供額外保護，以防止未受保護的進程讀取內存和代碼注入。啟用此功能后無法把debugger attach到進程上。在win8.1及2012 r2以上有效，啟用的方法是reg add HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa /v RunAsPPL /t REG_DWORD /d 1 之后重啟。 重啟之后，使用mimikatz抓取內存中的密碼：
使用lsadump::lsa /inject:
同樣無法獲取到密碼hash
繞過方式
mimikatz能夠通過加載其驅動程序來繞過LSA Protection。在實際使用中需要注意mimikatz同目錄下需要有驅動程序mimidrv.sys 命令：
privilege::Debug
!+
!processprotect /process:lsass.exe /remove
測試:
參考資料： https://adsecurity.org/?page_id=1821
Microsoft本地管理員密碼解決方案（LAPS）
LAPS是用於管理計算機本地用戶密碼的一個客戶端擴展（CSE），在域中依賴比較少，核心在於組策略支持。 LAPS一個重要功能是隨機化所有域成員本地管理員密碼，密碼按照較強的密碼策略生成，定期修改。這使得用相同憑據橫向滲透變得很困難。
本地管理員密碼明文存儲在AD中，僅有管理員及獲得管理員委派的賬戶能訪問到。
LAPS和僅僅增大了橫向滲透的難度，並且配置上出錯也可能導致前功盡棄。LAPS配置上可能出現的一個問題是向非授權用戶授予“All Extended Rights”權限，這導致如果我們獲取該賬戶，就能訪問AD中的密碼。
參考資料： https://github.com/leoloobeek/LAPSToolkit
Credentials Guard
Credentials Guard是win10中引入的新功能，據稱能保護NTLM密碼哈希值，Kerberos票證授予票證和應用程序存儲的憑據。該進程是唯一能使用明文憑據的進程，它的原理大概是這樣： 當NTLM認證過程中需要用到例如ntlm hash這類憑證的時候（第三步），將Credentials Guard視為黑箱，由lsass等進程輸入生成NetNTLM所需的信息（第二步收到的challenge等等），由CG處理並輸出結果，而CG本身內存禁止讀取，使得mimikatz這一類工具無從下手：
繞過方式
對付Credentials Guard有一些曲線救國的方法：
SSP的二進制形式是DLL，提供用來處理身份認證的接口（SSPI）。如果我們無法從內存中直接獲取憑據，那么通過注冊一個ssp來處理用戶登錄時輸入的憑據也是一種辦法。mimikatz直接在內存中加載自定義的ssp dll，能夠在用戶登錄時獲取到明文憑據。 演示： mimikatz 內存注入ssp
鎖屏等待用戶再次登錄后，查看system32下的文件
NetNTLM Downgrade Attack
NetNTLM有兩個版本——v1和v2。v1相比v2更加脆弱，因此如果我們能將NetNTLMv2降級為v1，破解的效率會更高；如果能降級到NetLM，那么爆破成功率就變得極高。
在 這篇文章 中提到了一種迂回獲取憑據的方式，核心思想是修改注冊表使Windows允許在網絡認證中發送算法較弱的NetHash例如NetNTLMv1，而實際上我們可以直接與NTLM SSP交互而不必產生網絡流量，並能獲取到NetNTLMv1用於降低破解的難度。
Credentials Guard運行時，我們雖然不能直接從內存獲取到NTLM Hash，但利用上面提到的思路獲取NetNTLM Hash是有可能的。
Internal-Monologue.ps1使用演示：
參考資料： https://blog.nviso.be/2018/01/09/windows-credential-guard-mimikatz/ https://github.com/eladshamir/Internal-Monologue https://technet.microsoft.com/en-us/library/2006.08.securitywatch.aspx
總結
由於NTLM認證本身具有缺陷性，導致攻擊者可以在不知道明文密碼，只知道密碼Hash的情況下完成認證。這個缺陷就目前來看無法修復，微軟也只能建議使用更安全的kerberos協議來代替ntlm協議，而其發布的補丁也並沒有觸及PtH這種攻擊思想的本質，僅僅是增大了攻擊的難度或者粗暴地禁止NTLM認證，因此依然存在繞過的可能。