1.简介
本篇将上篇文章的坑补一个，就是windows局域网环境下的攻击手法涉及到的其他协议。
2.windows 名称解析简介
TCP 协议的通信是基于 IP 地址的，“名称解析”就是把需要访问的计算机的名字解析为 IP 地址的过程。
Windows 中的名称类型
在 Windows 操作系统中，有两种名称，分别为：主机名称 和 NetBIOS 名称。
2.1.主机名称
从狭义上来说，主机名称正如它的字面意思一样就是一台主机的名字。从广义来说，它又不仅仅包含计算机的名字，也包含互联网中的域名。
由于域名是以树状的形式所表现的，同时也是主机名称的一种，所以主机名称是有层次的，最大长度为 255 个字符，允许的字符有 A～Z，a～z 和字符“－”。在域名系统中有一种标识一台主机的 DNS 名字的域名叫做 完全限定域名（FQDN），FQDN 是由“.”连接主机名字和主域名后缀组合成的，例如，seclab.hahaha.org 的 FQDN 名称就是 seclab 。
2.2.NetBIOS 名称
在 Windows 系统中的另外一种名称就是 NetBIOS 名称，准确的说 NetBIOS 名称并非是一种名字系统，而是 Windows 操作系统网络的一个编程接口，允许主机之间使用 NetBIOS 名称进行通信，通信过程是建立在 NetBIOS 协议之上的。在安装完 Windows 系统后系统会默认使用计算机的名字做为当前主机的 NetBIOS 名称。它的最大长度为 16 个字符，其中最后一位是不可配置的，用于指定 NetBIOS 的服务类型。如果计算机名称不足 15 位则使用空格补全到 15 位，反之，如果计算机名称超过 15 位 则会截取前 15 位。
使用nbtstat -n命令查看本机的 NetBIOS 名称。
3.Windows 名称解析相关协议
在 Windows 系统中有三种与名称解析相关的协议。
3.1.DNS协议
DNS 协议是一种最主要的也是操作系统首选的进行名称解析的协议，几乎每一种操作系统都支持 DNS 协议，DNS 协议在实现名称解析的过程中，在客户机上没有任何本地的数据库文件，完全依赖于 DNS 服务器，所监听的端口是 UDP/53
DNS数据包结构如下图：
DNS 的名称解析过程如下：
● 读取本机 DNS 缓存（已经包含本机 hosts 文件内容）
● 如果缓存中没有，则会请求网络配置中配置的 DNS 服务器
● 如果 DNS 服务器未作出响应，则请求失败。反之，DNS 服务器则会处理用户请求。
3.2.NetBIOS 协议(NBNS)
NBNS是NetBIOS name service的缩写，是NetBIOS的命名服务，用于将NetBIOS名称映射到IP地址上，是NetBIOS-over-TCP(NBT)协议族的一份子。NBT 服务监听的端口为 UDP/137，会话层协议。其进行名称解析的形式为向当前主机所在的子网域发送广播包。所以，当你使用抓包工具在局域网中抓包时总会收到很多 NBNS 数据包。但由于 NetBIOS 协议进行名称解析是发送的 UDP 广播包。这样做虽然速度快且无需额外的配置，但是广播包不能跨越网域同时也会增加一些网络流量，因此微软在后来推出了 WINS（Windows Internet Name Service）服务器，当计算机配置为使用 WINS 服务器进行名称解析时，客户机将直接和 WINS 服务器进行单播通讯，这样就可以弥补 NetBIOS 协议使用广播进行名称解析的不足。
NetBIOS 协议进行名称解析的过程如下：
● 检查本地 NetBIOS 缓存
● 如果缓存中没有请求的名称且已配置了 WINS 服务器，接下来则会向 WINS 服务器发出请求
● 如果没有配置 WINS 服务器或 WINS 服务器无响应则会向当前子网域发送广播
● 如果发送广播后无任何主机响应则会读取本地的 lmhosts 文件
lmhosts 文件位于C:\Windows\System32\drivers\etc\目录中。
使用nbtstat -c命令查看本机的 NetBIOS 缓存
使用nbtstat -R命令清除本机的 NetBIOS 缓存
NetBios的三种服务：
| Service Name | Port | Protocol | Short Name |
|---|---|---|---|
| NetBIOS Name service | 137 | UDP/TCP | NBNS |
| NetBIOS Datagram | 138 | UDP | NBND |
| NetBIOS Session service | 139 | TCP | NBSS |
解释：
● NetBIOS-Nname Service:为了启动会话和分发数据报，程序需要使用Name Server注册NETBIOS名称，可以告诉其他应用程序提供什么服务，默认监听UDP137端口，也可以使用TCP 137端口。
● Datagram distribution service(数据报分发服务):无连接，负责错误检测和恢复，默认在UDP 138端口。
● Session Server（会话服务）:允许两台计算机建立连接，默认在TCP 139端口。如果连接已建立，则建立会话的计算机会向连接发送"会话请求"包，其中包含建立会话的应用程序的 NetBIOS 名称和将要建立会话的 NetBIOS 名称。TCP 可处理所有会话服务包的流量控制和转载，以及将数据流分割到足够小到足以容纳链接层数据包的数据流。
需要注意的是，windows下WINS解析是默认开启的
每一个网卡会有一个NetBios的表（我的计算机只有一块网卡）:
3.3.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 进行名称解析的过程为：
检查本地 NetBIOS 缓存
如果缓存中没有则会像当前子网域发送广播
当前子网域的其他主机收到并检查广播包，如果没有主机响应则请求失败
工作原理：
当一台主机想要访问到另一台主机时，主机在自己的内部名称缓存中查询名称，如果在缓存中没有找到名称，那么主机就会向自己配置的DNS服务器发送查询请求，如果主机没有收到回应或收到了错误信息，即DNS解析会失败，那么就会转为使用LLMNR链路本地多播名称解析。使用链路本地多播名称解析时，主机会通过 UDP 向局域网内发送多播查询，查询主机名对应的IP，查询范围被限制在本地子网内。本地子网内每台支持LLMNR的主机在收到这个查询请求后，收到该请求的主机会判断自己的主机名是不是这个查询的主机名。如果是，这台主机会回复自己IP地址给请求该查询的主机；如果不是，则丢弃该请求。
4.Windows 系统名称解析顺序
值得注意的是：Windows 2K , XP , 2K3 只支持 DNS 和 NetBIOS。 所以此类版本的 Windows 都是先进行 DNS 名称解析，如果 DNS 解析名称失败，才会进行 NetBIOS 名称解析。
Windows Vista 之后（包括 2K8 ， Win7，Win8.x，Win 10）都支持上述三种协议，在这类 Windows系统中的名称解析顺序为：先进行 DNS 名称解析，如果 DNS 解析名称失败，则会使用 LLMNR 进行名称解析，最后才会使用 NetBIOS 名称解析。
5.利用 Windows 名称解析机制的缺陷进行内网攻击
首先说明一下，在上篇文章中已经展示了通过Inveigh进行投毒+中继的攻击方式，这里仅展示一下获取NTLMv2 hash的过程，其原理就是上述内容。
攻击思路很简单：受害者访问一个不存在的主机的共享，计算机就会先进行 DNS 名称解析，这里DNS 解析名称失败，则会使用 LLMNR 进行名称解析，由于用户进行的操作为dir \\qwewqe\c$，那么计算机就会带着用户的凭证去请求，也就是下图的NTLMv2 hash。所以，我们可以通过Inveigh抓取到NTLMv2 hash。（responder这款工具原理也是如此）
