0x00 前言

成都創(chuàng)新互聯(lián)公司-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設、高性價比沙河網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式沙河網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設找我們，業(yè)務覆蓋沙河地區(qū)。費用合理售后完善，十多年實體公司更值得信賴。

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

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

windows域與扁平化網(wǎng)絡結構對比圖

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

去年Google宣布，放棄內外網(wǎng)結構，將所有網(wǎng)絡當做外網(wǎng)對待。這種訪問模式要求客戶端是受控的設備，并且需要用戶證書來訪問。訪問有通過認證服務器、訪問代理以及單點登錄等手段，由訪問控制引擎統(tǒng)一管理，不同用戶、不同資源有不同的訪問權限控制，對于用戶所處位置則沒有要求。也就是說，無論用戶在Google辦公大樓、咖啡廳還是在家都是一樣的訪問方式，過去從外網(wǎng)訪問需要的VPN已經(jīng)被廢棄。而所有員工到企業(yè)應用的連接都要進行加密，包括在辦公大樓里面的訪問。可以說，Google的這種模式已經(jīng)徹底打破了內外網(wǎng)之別。(援引于http://www.freebuf.com/news/67346.html)

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

該方案就是把思路更多的放在網(wǎng)絡基礎設備上，如Router，Switch等基礎網(wǎng)絡設備。攻擊方式，就像NSA的TAO系統(tǒng)一樣，檢查流量，控制流量，最后利用流量。

0x01 滲透初探

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

關于試驗用目標，有幾點要求，首先是在一個工作組環(huán)境中，(其次)擁有較多的主機或者較大網(wǎng)絡。經(jīng)過不斷尋找，成功滲透進一個滿足我需求的內網(wǎng)。

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

然后開始針對網(wǎng)絡設備進行攻擊。利用正向反彈工具，將我的kali接入了內網(wǎng)，定向攻擊網(wǎng)關設備。利用snmp的弱口令，直接獲取了三層交換的控制權限。

ipconfig /all結果截圖：

執(zhí)行snmpwalk讀取密碼：

成功讀取到密碼

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

這里需要多說一下，我并沒有直接進行固件級別的EXP測試，因為在exploit-db上的路由器固件的遠程命令執(zhí)行exp并不多，有很多的exp并沒有公開，并且由于自己沒有構造EXP的能力，遂放棄通過EXP獲取權限的思路。

0x02 收集分析網(wǎng)絡基礎信息

通過正向代理訪問網(wǎng)關，成功telnet連接到設備：

然后立即查看所有配置：

查看版本信息：

查看設備的IP地址：

查看活動主機：

獲取完基本信息之后，進行簡單分析，華為的9306，三層交換機，查看到的下轄的用戶不多，只有160多個，可能不準確，因為該時間段為非辦公生活時間段。然后梳理流量線路，朝著外網(wǎng)方向，繼續(xù)探索，又獲取一臺ruijie ES2000GS的控制權限，之后的機器不允許訪問，無法繼續(xù)往下拓展，總結如下

華為的9306應該是一層樓的或者一棟樓的匯聚，ruijie ES2000GS應該是一棟樓或者一個小園區(qū)的出口，校園核心的雙交換網(wǎng)絡或者出口路由器都不能被telnet訪問。之所以這樣分析，因為在已經(jīng)控制的機器上暫未發(fā)現(xiàn)任何一個公網(wǎng)IP地址;鏈接數(shù)、活躍主機數(shù)量都處于一個較低的量級;發(fā)現(xiàn)了nat的配置，但是并沒有公網(wǎng)映射;所以只能這樣簡單的判斷。

0x03 獲取內網(wǎng)用戶詳細信息

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

協(xié)議安全性PAT穿透

GRE不加密否

PPTP加密是

L2TP不加密是

IP-SEC加密否

L2TP over IPSEC加密是

由于已經(jīng)控制的設備沒有公網(wǎng)IP地址，沒有控制實現(xiàn)NAT功能的網(wǎng)絡出口設備，就必須選擇能穿越PAT的隧道。所以就只能在L2TP ，L2TP over IPSEC，PPTP中選擇一個，最終選擇了L2TP。因為銳捷經(jīng)過測試發(fā)現(xiàn)不支持PPTP時，L2TP over IPSEC配置建立隧道導致設備不穩(wěn)定，可能是設備自身的原因，在本地模擬環(huán)境測試時正常。

準備配置L2TP隧道，在本地的模擬環(huán)境上進行了部署，都能連通。但是到了設備上，報錯說不支持命令，并且virtual-ppp接口無法添加配置，至今未找到原因。最后直接圖形化配置完成，銳捷提供了L2TP VPN的圖形化配置界面，很簡單。

在想分析流量的時候，出現(xiàn)一個問題，原計劃是使用ip flow，但是該協(xié)議是cisco私有協(xié)議，銳捷與華為都不支持，并且筆者對華為的IP STEAM不熟悉，沒有很好的解決方案，在準備進行完整引導流量的準備時，發(fā)現(xiàn)銳捷的網(wǎng)關設備，可以生成流量報表。

對統(tǒng)計好的流量大概分析后，對內網(wǎng)的流量有了一個大概的認識，HTTPS流量占了日常網(wǎng)頁流量的很大部分，并且發(fā)現(xiàn)了內網(wǎng)有較大規(guī)模部署360安全大禮包。

然后定向劫持一些騰訊的http網(wǎng)頁，利用小工具，將beef代碼插入到網(wǎng)頁中，進行基本信息的獲取。由于較多網(wǎng)頁為HTTPS，并沒有完善方案，所以收集到的信息很少。

這里需要多說一句，我劫持流量的方式是利用MQC或者添加路由，進行抓取，引導流量。沒有使用Switch端口鏡像配置獲取流量，像(http://drops.wooyun.org/tips/649)該文章說的方式。并且在這里最大程度的反對大家使用這種方案!因為在cisco，juniper和huawei設備上，端口鏡像將會導致DST端口或者VLAN失去承載正常業(yè)務數(shù)據(jù)的功能。簡單說就是，進行端口鏡像配置，流量被鏡像到的端口將不再具有正常通信功能。如果不是經(jīng)過嚴密討論設計之后得出的方案，還是勸大家別去考慮該方法。

然后利用一些能找到的一些EXP，進行掛馬。開始沒有上線的，將馬換成powershell empire的exe之后，終于有了一臺上線的。分析可能是由于EXP和木馬沒有進行免殺，并且機器上有安裝360或者一些其它的殺軟，直接導致EXP與木馬被殺。

因為只是驗證性的滲透，使用的木馬和EXP全部是網(wǎng)上公開的，并且沒有準備特定場景的定向釣魚，所以只能獲取個別機器的控制權限。但是如果經(jīng)過一些準備，在完全控制了用戶流量這種情景下，種馬不會特別難。

之后我試圖進行內網(wǎng)控制擴展，即嘗試滲透本園區(qū)之外的機器。結果兩臺設備上沒有運行任何路由協(xié)議，路由配置就一條默認路由指向出口，其他的路由都是本地直連路由。

之前準備的方案是進行路由協(xié)議的劫持，或者稱為路由表的優(yōu)化更為確切，就是利用協(xié)議特性，將我變成必經(jīng)之路，獲取內網(wǎng)其他區(qū)域的流量。該設計方案并不關心路由協(xié)議，不論是OSPF，EIGRP，RIPv2或者是混合網(wǎng)絡，只要他和其他機器之間運行著某種路由協(xié)議，就能完成路由的劫持。很遺憾，這個環(huán)境中不能實地測試了。

在嘗試進一步明確內網(wǎng)設備信息，進行了簡單的tracert查找，進一步明確了網(wǎng)絡鏈路結構。在擴展?jié)B透的時候受阻，核心路由器只給我回復icmp的信息，不允許我訪問其他的任何端口，對于這情況，目前沒有有效的方案。

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

到此，測試就告一段落，清理滲透痕跡撤出，并沒有近一步嘗試擴展控制。如果繼續(xù)，進行一段時間的數(shù)據(jù)包監(jiān)聽等行為，一定能有所突破。

0x04 總結

最近一直在研究流量的引導，控制，利用，以適應于各種滲透環(huán)境。

所以這是我想到對抗這種環(huán)境特殊內網(wǎng)的方案，我認為可以使用這種思路，用在之前滲透的所有目標上，如果有逆向開發(fā)人員，漏洞人員的配合，滲透測試將會在內網(wǎng)中如魚得水。

這種思路經(jīng)過簡單的變形，放大，會是一種極為方便的滲透思路，我這里舉一例：

flag在一個內網(wǎng)的一臺機器上，利用傳統(tǒng)針對目標的滲透，無法獲取到內網(wǎng)權限。然后該怎么辦?

獲取目標網(wǎng)絡信息，所屬IP地址，然后，攻陷該運營商。然后利用流量控制目標1，突然發(fā)現(xiàn)目標2也在該運營商范圍下，順勢拿下目標2，以此類推，目標3，目標4.。。。。。。。

發(fā)現(xiàn)目標10不在該運營商范圍內，利用BGP劫持公網(wǎng)路由信息。然后順勢擴展目標11，目標12.。。。。。。

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

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

由于該滲透是通過注入等操作進入內網(wǎng)，然后SNMP獲取路由器權限，隧道并沒有使用IPSEC加密，這三個步驟不可能逃過行為流量檢測。

關于木馬回連：

木馬回連的地址，全部使用update.microsoft.com域名，在網(wǎng)絡設備上，做通網(wǎng)該IP地址的流量進行定向劫持到VPS。將本地機器接入VPS，并且將VPN的IP地址設置為該域名解析的地址。這樣就成功使得木馬上線。

使用的是empire木馬，他的的流量使用SSL加密。關于EMPIRE的上線時間，并沒有做特別設置，因為方便測試。在已控的網(wǎng)關與用戶個人機器上看到的只會是用戶與 update.microsoft.com該域名地址的ssl通信。但是在最外層的路由器上可以看到通網(wǎng)VPS的流量。所以說只要規(guī)避之前所說的敏感點，該方案會具備較高的隱蔽性。

并且沒有敏感的內網(wǎng)滲透行為，例如利用一個用戶賬戶，登陸不該登陸的機器，訪問不該訪問的位置，打開不屬于自己的文件夾。所有設備的發(fā)現(xiàn)沒有靠掃描(第一步除外)。關于flag，只是通過捕獲用戶，檢查用戶訪問位置，是否能訪問flag文件夾。重復過程，直到抓到訪問flag的用戶。

所以如果木馬等工具能不被安防設備或者軟件查殺，該滲透方案具有較高隱蔽性。由于該內網(wǎng)中沒有行為檢測設備或者我沒有控制到，不能進一步判斷。在設計之初，就考慮到頂級安全行為檢測設備。由于非開發(fā)，沒有考慮在機器端防護的部分。

最后說下這個思路的弊端

如果沒有一個很成熟的釣魚等方案，例如下載exe時做302跳轉;劫持安全部門網(wǎng)頁，提供安全更新;Router與Switch沒有配置漏洞可以利用。那么該思路極其依賴漏洞的使用，例如需要Router與Switch遠程命令執(zhí)行漏洞來控制網(wǎng)絡設備;flash，瀏覽器等軟件的本地命令執(zhí)行漏洞。

需要操作路由器來對路由表進行優(yōu)化與流量的引導，至少得對路由器，路由協(xié)議，交換機有深入或者較為深入的了解。

對HTTPS沒有什么好的解決方案。

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

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

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

分享題目：內網(wǎng)滲透思路探索之新思路的探索與驗證
網(wǎng)頁網(wǎng)址：http://uogjgqi.cn/article/cdpcigg.html