0x00 前言

---

在安全發展初期，企業和一些個人使用防毒軟體進行安全防護，如卡巴斯基，symantec等，安全人員使用免殺這項技術來對抗殺軟的檢查。現如今，安防軟體採用各種手段來保護內網安全，如網路流量分析，軟體行為分析，網路行為分析等，提高了內網的安全性。

同時在滲透過程中經常遇到一種內網結構，由數臺mac，linux和windows個人機組成的混合內網，一種扁平化結構。

windows域與扁平化網路結構對比圖

這種扁平化的網路難以管理和維護。並且給安全測試人員帶來了困擾。滲透這些網路，就不能使用傳統域滲透思路，進入域，獲取域管理員許可權，控制域控。

去年Google宣佈，放棄內外網結構，將所有網路當做外網對待。這種訪問模式要求客戶端是受控的裝置，並且需要使用者證書來訪問。訪問有透過認證伺服器、訪問代理以及單點登入等手段，由訪問控制引擎統一管理，不同使用者、不同資源有不同的訪問許可權控制，對於使用者所處位置則沒有要求。也就是說，無論使用者在Google辦公大樓、咖啡廳還是在家都是一樣的訪問方式，過去從外網訪問需要的VPN已經被廢棄。而所有員工到企業應用的連線都要進行加密，包括在辦公大樓裡面的訪問。可以說，Google的這種模式已經徹底打破了內外網之別。（援引於http://www.freebuf.com/news/67346.html）

所以針對傳統網路結構以及包括這種無內網的網路結構提出一種新的滲透思路，同時能對流量行為檢測有一定的規避作用。受到google的啟發，如果滲透也不再關注內外網結構，不再專注於內網滲透，把對於外網的思路完整的放在滲透中，自始至終，一直使用外網滲透方式，是否就能滲透特殊的網路並且能在一定程度上逃避網路行為檢測。開始探索，提出一個完整的滲透方案

該方案就是把思路更多的放在網路基礎裝置上，如Router，Switch等基礎網路裝置。攻擊方式，就像NSA的TAO系統一樣，檢查流量，控制流量，最後利用流量。

0x01 滲透初探

---

基於這樣的滲透思路，開始嘗試尋找試驗目標。

關於試驗用目標，有幾點要求，首先是在一個工作組環境中，（其次）擁有較多的主機或者較大網路。經過不斷尋找，成功滲透進一個滿足我需求的內網。

目標是一個學校，滲透的過程比較平常，注入，上shell，反彈不成功，正向反彈，控制伺服器，沒有太多的亮點。

然後開始針對網路裝置進行攻擊。利用正向反彈工具，將我的kali接入了內網，定向攻擊閘道器裝置。利用snmp的弱口令，直接獲取了三層交換的控制許可權。

ipconfig ／all結果截圖：

執行snmpwalk讀取密碼：

成功讀取到密碼

注：kali的snmpwalk 不能利用proxychains走socks5代理，攻擊內網機器，暫不清楚原因。

這裡需要多說一下，我並沒有直接進行韌體級別的EXP測試，因為在exploit-db上的路由器韌體的遠端命令執行exp並不多，有很多的exp並沒有公開，並且由於自己沒有構造EXP的能力，遂放棄透過EXP獲取許可權的思路。

0x02 收集分析網路基礎資訊

---

透過正向代理訪問閘道器，成功telnet連線到裝置：

然後立即檢視所有配置：

檢視版本資訊：

檢視裝置的IP地址：

檢視活動主機：

獲取完基本資訊之後，進行簡單分析，華為的9306，三層交換機，檢視到的下轄的使用者不多，只有160多個，可能不準確，因為該時間段為非辦公生活時間段。然後梳理流量線路，朝著外網方向，繼續探索，又獲取一臺ruijie ES2000GS的控制許可權，之後的機器不允許訪問，無法繼續往下擴充，總結如下

華為的9306應該是一層樓的或者一棟樓的匯聚，ruijie ES2000GS應該是一棟樓或者一個小園區的出口，校園核心的雙交換網路或者出口路由器都不能被telnet訪問。之所以這樣分析，因為在已經控制的機器上暫未發現任何一個公網IP地址；連結數、活躍主機數量都處於一個較低的量級；發現了nat的配置，但是並沒有公網對映；所以只能這樣簡單的判斷。

0x03 獲取內網使用者詳細資訊

---

為了獲取這個詳細資訊，就必須要對內網流量進行分析，為了完成這個目的，需要在內網路由器，與公網的Ubuntu之間建立了一個隧道。在準備階段，預備了以下幾種隧道協議部署方案：

協議	安全性	PAT穿透
GRE	不加密	否
PPTP	加密	是
L2TP	不加密	是
IP-SEC	加密	否
L2TP over IPSEC	加密	是

由於已經控制的裝置沒有公網IP地址，沒有控制實現NAT功能的網路出口裝置，就必須選擇能穿越PAT的隧道。所以就只能在L2TP ，L2TP over IPSEC，PPTP中選擇一個，最終選擇了L2TP。因為銳捷經過測試發現不支援PPTP時，L2TP over IPSEC配置建立隧道導致裝置不穩定，可能是裝置自身的原因，在本地模擬環境測試時正常。

準備配置L2TP隧道，在本地的模擬環境上進行了部署，都能連通。但是到了裝置上，報錯說不支援命令，並且virtual－ppp介面無法新增配置，至今未找到原因。最後直接圖形化配置完成，銳捷提供了L2TP VPN的圖形化配置介面，很簡單。

在想分析流量的時候，出現一個問題，原計劃是使用ip flow，但是該協議是cisco私有協議，銳捷與華為都不支援，並且筆者對華為的IP STEAM不熟悉，沒有很好的解決方案，在準備進行完整引導流量的準備時，發現銳捷的閘道器裝置，可以生成流量報表。

對統計好的流量大概分析後，對內網的流量有了一個大概的認識，HTTPS流量佔了日常網頁流量的很大部分，並且發現了內網有較大規模部署360安全大禮包。

然後定向劫持一些騰訊的http網頁，利用小工具，將beef程式碼插入到網頁中，進行基本資訊的獲取。由於較多網頁為HTTPS，並沒有完善方案，所以收集到的資訊很少。
這裡需要多說一句，我劫持流量的方式是利用MQC或者新增路由，進行抓取，引導流量。沒有使用Switch埠映象配置獲取流量，像（/tips/?id=649）該文章說的方式。並且在這裡最大程度的反對大家使用這種方案！因為在cisco，juniper和huawei裝置上，埠映象將會導致DST埠或者VLAN失去承載正常業務資料的功能。簡單說就是，進行埠映象配置，流量被映象到的埠將不再具有正常通訊功能。如果不是經過嚴密討論設計之後得出的方案，還是勸大家別去考慮該方法。

然後利用一些能找到的一些EXP，進行掛馬。開始沒有上線的，將馬換成powershell empire的exe之後，終於有了一臺上線的。分析可能是由於EXP和木馬沒有進行免殺，並且機器上有安裝360或者一些其它的殺軟，直接導致EXP與木馬被殺。
因為只是驗證性的滲透，使用的木馬和EXP全部是網上公開的，並且沒有準備特定場景的定向釣魚，所以只能獲取個別機器的控制許可權。但是如果經過一些準備，在完全控制了使用者流量這種情景下，種馬不會特別難。

之後我試圖進行內網控制擴充套件，即嘗試滲透本園區之外的機器。結果兩臺裝置上沒有執行任何路由協議，路由配置就一條預設路由指向出口，其他的路由都是本地直連路由。

之前準備的方案是進行路由協議的劫持，或者稱為路由表的最佳化更為確切，就是利用協議特性，將我變成必經之路，獲取內網其他區域的流量。該設計方案並不關心路由協議，不論是OSPF，EIGRP，RIPv2或者是混合網路，只要他和其他機器之間執行著某種路由協議，就能完成路由的劫持。很遺憾，這個環境中不能實地測試了。

在嘗試進一步明確內網裝置資訊，進行了簡單的tracert查詢，進一步明確了網路鏈路結構。在擴充套件滲透的時候受阻，核心路由器只給我回復icmp的資訊，不允許我訪問其他的任何埠，對於這情況，目前沒有有效的方案。

這是一種比較無奈的情況，應該也就是大家一直對Router或者Switch沒啥興趣的原因。這類裝置，如果精心配置了安全，那麼除了EXP外，其他的控制思路都會十分的艱難。在這臺裝置上沒有嘗試已經公開的EXP。因為針對核心裝置，EXP會引起的崩潰可能會導致機器癱瘓，重啟，產生巨大的影響。

到此，測試就告一段落，清理滲透痕跡撤出，並沒有近一步嘗試擴充套件控制。如果繼續，進行一段時間的資料包監聽等行為，一定能有所突破。

0x04 總結

---

最近一直在研究流量的引導，控制，利用，以適應於各種滲透環境。
所以這是我想到對抗這種環境特殊內網的方案，我認為可以使用這種思路，用在之前滲透的所有目標上，如果有逆向開發人員，漏洞人員的配合，滲透測試將會在內網中如魚得水。

這種思路經過簡單的變形，放大，會是一種極為方便的滲透思路，我這裡舉一例：

flag在一個內網的一臺機器上，利用傳統針對目標的滲透，無法獲取到內網許可權。然後該怎麼辦？
獲取目標網路資訊，所屬IP地址，然後，攻陷該運營商。然後利用流量控制目標1，突然發現目標2也在該運營商範圍下，順勢拿下目標2，以此類推，目標3，目標4.。。。。。。。
發現目標10不在該運營商範圍內，利用BGP劫持公網路由資訊。然後順勢擴充套件目標11，目標12.。。。。。。

該示例沒有計算投入，並且需要大量的技術支援。但是收益一樣客觀。有人說BGP劫持被監控，實際上是，精心設計的BGP劫持，不會被發現，只是需要精心設計。

再結合例項，談一下關於滲透行為的敏感性

由於該滲透是透過注入等操作進入內網，然後SNMP獲取路由器許可權，隧道並沒有使用IPSEC加密，這三個步驟不可能逃過行為流量檢測。

關於木馬回連：

木馬回連的地址，全部使用update.microsoft.com域名，在網路裝置上，做通網該IP地址的流量進行定向劫持到VPS。將本地機器接入VPS，並且將VPN的IP地址設定為該域名解析的地址。這樣就成功使得木馬上線。
使用的是empire木馬，他的的流量使用SSL加密。關於EMPIRE的上線時間，並沒有做特別設定，因為方便測試。在已控的閘道器與使用者個人機器上看到的只會是使用者與 update.microsoft.com該域名地址的ssl通訊。但是在最外層的路由器上可以看到通網VPS的流量。所以說只要規避之前所說的敏感點，該方案會具備較高的隱蔽性。
並且沒有敏感的內網滲透行為，例如利用一個使用者賬戶，登陸不該登陸的機器，訪問不該訪問的位置，開啟不屬於自己的資料夾。所有裝置的發現沒有靠掃描（第一步除外）。關於flag，只是透過捕獲使用者，檢查使用者訪問位置，是否能訪問flag資料夾。重複過程，直到抓到訪問flag的使用者。
所以如果木馬等工具能不被安防裝置或者軟體查殺，該滲透方案具有較高隱蔽性。由於該內網中沒有行為檢測裝置或者我沒有控制到，不能進一步判斷。在設計之初，就考慮到頂級安全行為檢測裝置。由於非開發，沒有考慮在機器端防護的部分。

最後說下這個思路的弊端

如果沒有一個很成熟的釣魚等方案，例如下載exe時做302跳轉；劫持安全部門網頁，提供安全更新；Router與Switch沒有配置漏洞可以利用。那麼該思路極其依賴漏洞的使用，例如需要Router與Switch遠端命令執行漏洞來控制網路裝置；flash，瀏覽器等軟體的本地命令執行漏洞。
需要操作路由器來對路由表進行最佳化與流量的引導，至少得對路由器，路由協議，交換機有深入或者較為深入的瞭解。
對HTTPS沒有什麼好的解決方案。

所以如果某個安全研究人員或者初級團隊使用，會遇到較多的瓶頸。
但是如果你有一個，個人能力合適，人員方向覆蓋較全的團隊，你將會收到一些驚喜。

下一步，我將研究如何對抗這種方案。