0x00 前言

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

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

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

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

去年Google宣布，放棄內外網結構，將所有網絡當做外網對待。這種訪問模式要求客戶端是受控的設備，并且需要用戶證書來訪問。訪問有通過認證服務器、訪問代理以及單點登錄等手段，由訪問控制引擎統一管理，不同用戶、不同資源有不同的訪問權限控制，對于用戶所處位置則沒有要求。也就是說，無論用戶在Google辦公大樓、咖啡廳還是在家都是一樣的訪問方式，過去從外網訪問需要的VPN已經被廢棄。而所有員工到企業應用的連接都要進行加密，包括在辦公大樓里面的訪問?？梢哉f，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端口鏡像配置獲取流量，像(http://drops.wooyun.org/tips/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沒有什么好的解決方案。

所以如果某個安全研究人員或者初級團隊使用，會遇到較多的瓶頸。

但是如果你有一個，個人能力合適，人員方向覆蓋較全的團隊，你將會收到一些驚喜。

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