本文作為一篇科普文章，闡述了 Windows 系統中的名稱解析機制，同時也提及了幾種利用名稱解析機制的缺陷進行內網攻擊的方式。
TCP 協議的通信是基于 IP 地址的，“名稱解析”就是把需要訪問的計算機的名字解析為 IP 地址的過程。
Windows 中的名稱類型
在 Windows 操作系統中，有兩種名稱，分別為：主機名稱 和 NetBIOS 名稱。
主機名稱
從狹義上來說，主機名稱正如它的字面意思一樣就是一臺主機的名字。從廣義來說，它又不僅僅包含計算機的名字，也包含互聯網中的域名。
由于域名是以樹狀的形式所表現的，同時也是主機名稱的一種，所以主機名稱是有層次的，最大長度為 255 個字符，允許的字符有 A～Z，a～z 和字符“－”。在域名系統中有一種標識一臺主機的 DNS 名字的域名叫做 完全限定域名（FQDN），FQDN 是由“.”連接主機名字和主域名后綴組合成的，例如，seclab.her0in.org 的 FQDN 名稱就是 seclab 。
NetBIOS 名稱
在 Windows 系統中的另外一種名稱就是 NetBIOS 名稱，準確的說 NetBIOS 名稱并非是一種名字系統，而是 Windows 操作系統網絡的一個編程接口，允許主機之間使用 NetBIOS 名稱進行通信，通信過程是建立在 NetBIOS 協議之上的。在安裝完 Windows 系統后系統會默認使用計算機的名字做為當前主機的 NetBIOS 名稱。它的最大長度為 16 個字符，其中最后一位是不可配置的，用于指定 NetBIOS 的服務類型。如果計算機名稱不足 15 位則使用空格補全到 15 位，反之，如果計算機名稱超過 15 位 則會截取前 15 位。常見的 NetBIOS 后綴有 0x20（文件和打印服務）、0x00（工作站服務）、0x03（報信者服務）等。
使用nbtstat -n命令查看本機的 NetBIOS 名稱。
使用nbtstat -A ipaddress命令查看指定 IP 主機的 NetBIOS 名稱。
在 Windows 系統中有三種與名稱解析相關的協議。
Windows 名稱解析之 DNS協議
DNS 協議是一種最主要的也是操作系統首選的進行名稱解析的協議，幾乎每一種操作系統都支持 DNS 協議，同時， DNS 協議支持 IP v4 和 IP v6。DNS 協議在實現名稱解析的過程中，在客戶機上沒有任何本地的數據庫文件，完全依賴于 DNS 服務器，所監聽的端口是 UDP/53 。在客戶機上可以使用ipconfig /displaydns命令來查看本機的 DNS 緩存，使用ipconfig /flushdns命令清除本機的 DNS 緩存。
DNS 的名稱解析過程如下：
Windows 名稱解析之 NetBIOS 協議
除了 DNS 之外，在早先版本的 Windows 中也使用 NetBIOS (network basic input/output system，網絡基本輸入輸出系統)進行名稱解析。本文介紹的 NetBIOS 協議名稱解析是微軟后來定義的 nbt 即 NetBIOS over TCP/IP 的名稱解析類型。
nbt 服務監聽的端口為 UDP/137，其進行名稱解析的形式為向當前主機所在的子網域發送廣播包。所以，當你使用抓包工具在局域網中抓包時總會收到很多 NBNS 數據包。
由于 NetBIOS 協議進行名稱解析是發送的 UDP 廣播包。這樣做雖然速度快且無需額外的配置，但是廣播包不能跨越網域同時也會增加一些網絡流量，因此微軟在后來推出了 WINS（Windows Internet Name Service）服務器，當計算機配置為使用 WINS 服務器進行名稱解析時，客戶機將直接和 WINS 服務器進行單播通訊，這樣就可以彌補 NetBIOS 協議使用廣播進行名稱解析的不足。
綜上所述，NetBIOS 協議進行名稱解析的過程如下：
lmhosts 文件位于C:\Windows\System32\drivers\etc\目錄中。
使用nbtstat -c命令查看本機的 NetBIOS 緩存
使用nbtstat -R命令清除本機的 NetBIOS 緩存
Windows 名稱解析之 LLMNR 協議
DNS 協議的名稱解析雖然高效但是需要在局域網中單獨配置一臺服務器作為 DNS 服務器，NetBIOS 協議的名稱解析在一些情況下也需要單獨配置一臺 WINS 服務器，而且 NetBIOS 協議不支持 IP v6。因此，為了彌補這些不足，微軟在 Windows Vista 之后推出了基于端到端的名稱解析協議 — 本地鏈路多播名稱解析（Link-Local Multicast Name Resolution）簡稱為 LLMNR。
LLMNR 也稱作多播 DNS ，因為其數據包格式類似于 DNS 的數據包。監聽的端口為 UDP/5355，支持 IP v4 和 IP v6 ，并且在 Linux 上也實現了此協議。其解析名稱的特點為端到端，IPv4 的廣播地址為 224.0.0.252，IPv6 的廣播地址為 FF02:0:0:0:0:0:1:3 或 FF02::1:3。
LLMNR 進行名稱解析的過程為：
影響 Windows 系統名稱解析的兩個因素
從上述一小節中，可以發現，并非所有的操作系統版本都支持上述三種協議。
Windows 2K , XP , 2K3 只支持 DNS 和 NetBIOS。 所以此類版本的 Windows 都是先進行 DNS 名稱解析，如果 DNS 解析名稱失敗，才會進行 NetBIOS 名稱解析。
Windows Vista 之后（包括 2K8 ， Win7，Win8.x，Win 10）都支持上述三種協議，在這類 Windows系統中的名稱解析順序為：先進行 DNS 名稱解析，如果 DNS 解析名稱失敗，則會使用 LLMNR 進行名稱解析，最后才會使用 NetBIOS 名稱解析。
還有一種影響 Windows 系統名稱解析的一個因素就是當前主機的網絡節點模式。可以使用ipconfig /all命令查看本機的網絡節點模式，如下圖：
圖 1 查看本機網絡節點模式
網絡節點模式最主要會影響 NetBIOS 名稱解析過程，是優先查詢 WINS 服務器還是先在子網域中進行廣播。具體的及節點模式描述如下：
Windows 使用廣播來進行名稱注冊和名稱解析，依據網關的配置，一個 B 節點客戶機發送的數據包不能夠超出局域網的范圍。但是，B 節點并不適合于大型網絡，實際上微軟修改了標準的 B 節點類型，當 Windows 嘗試解析名稱時，首先檢查 LMHOSTS 名稱緩存，如果此行不通，Windows 就會發送廣播，如果廣播依然失敗的話，那Windows 才會檢查實際的 LMHOSTS 文件。
這種方法并不使用廣播，而是在計算機啟動時，在網絡中的 WINS 服務器上注冊它們的名稱，當計算機需要解析名稱時，它會發送一個解析請求給 WINS 服務器。這種方法只在 WINS 服務器正常運行時有效，如果 WINS 服務器失敗，則無法進行名稱解析。
Windows 聯合使用 B 節點和 P 節點，并且默認使用 B 節點，如果 M 節點不能利用廣播進行名稱解析，它就使用 P 節點的 WINS 服務器來完成工作。
同樣也是聯合使用 B 節點和 P 節點，但工作方式相反，如果使用 WINS 服務器方式不能成功，則使用 B 節點的工作來完成工作。此節點模式也是目前 Windows 系統默認使用的節點模式。
常見的利用 Windows 名稱解析機制的缺陷進行攻擊的技術有 DNS Spoof ，NBNS Poison ，LLMNR Poison ， ICMP Redirection。
可以使用 SpiderLabs 出的 Responder，或者 ZARP 工具包進行上述攻擊。
LLMNR Poison 攻擊環境如下：
攻擊者在啟動 Responder 后，當受害者去訪問一個在當前局域網中不存在的主機時就會觸發 LLMNR Poison 攻擊，如下圖所示：
圖 1 ： 受害者主機 PING 一臺局域網中并不存在的主機
圖 2 ：Responder 會響應 LLMNR 的廣播包并進行了 Poison 攻擊
圖 3 ：在受害者的主機中 NetBIOS 緩存中已經加入了被 Poison 攻擊的主機 IP 記錄
上述攻擊演示中，已經證實了 LLMNR Poison 攻擊的效果，可以利用讓受害者訪問不存在的主機的共享進行 LLMNR Poison 攻擊，這樣可以獲得受害者主機的 HASH ，拿到 HASH 就可以進行暴力破解了，如果是弱口令的話，就可以爆破出密碼。同樣也可以利用讓受害者訪問不存在的 HTTP 服務器進行 401 認證拿到客戶端的 HASH，如下圖所示：
圖 4 ：受害者訪問一個不存在的主機的共享
圖 5 ：LLMNR Poison 攻擊拿到了 SMB 驗證過程中的 HASH
圖 6 ：使用 john 對 HASH 進行暴力破解
https://support.microsoft.com/en-us/kb/119493
https://en.wikipedia.org/wiki/Link-Local_Multicast_Name_Resolution
https://support.microsoft.com/en-us/kb/163409
https://support.microsoft.com/en-us/kb/160177
http://read.newbooks.com.cn/info/132528.html