【內網滲透】利用非常規手段突破安全策略上線CS

前言

本文為一篇利用非常規手段突破安全策略的內網滲透記錄

【查看資料】

環境簡述&說明

• web打點getshell，webshell是冰蝎，權限為.net，權限很低，服務器為server 2016，目標不出網！
  
• 裝有殺毒軟體（火絨、微軟自帶的WD），ASMI默認開啟，而且對power shell有特殊策略限制，
  
• Tcp、icmp、DNS協議不通，無法直接與公網的cs服務端建立連接，（內網的cs服務端也無法與其建立連接）公網也無法訪問目標web服務（純內網web服務）
• 極其嚴格的出入站策略

入站規則：只有http允許入站，只有一個80、8080兩http埠能供內網機器正常訪問
出站規則：不允許非8080埠對外通訊，
手繪了一張拓撲圖，將就著看一下，

為什么要上線cs

webshell權限太低，限制性大，需要上線cs提權，因為cs是采用反射dll來加載pe程式，從而在執行一些敏感操作的時候能起到一定的bypass作用，例如mimikatz抓密碼等操作，
像轉儲LSA到本地然后再dumphash都是行不通的，因為webshell權限太低了，轉儲LSA至少得管理員權限，
而且目標網路環境較為苛刻，任何非http協議的通訊都會被防火墻攔截，無法正常建立一個具有互動功能的shell，

坑點一：利用Pystinger反向代理上線cs

在查閱相關資料后，發現網上大部分文章都通過Pystinger來實作內網反向代理，利用http協議將目標機器埠映射至cs服務端監聽埠，能在只能訪問web服務且不出網的情況下可以使其上線cs，

但是這里有個問題，公網cs服務器無法訪問目標的web服務，只有同處于在一個內網的機器才能訪問目標web服務，所以無法直接在服務器上搭建pystinger將目標機埠反向代理至公網cs監聽埠上，
這里采用的解決方法是直接在本機上搭建一個cs服務，然后再進行pystinger反代操作，

1.本地起一個cs服務

2.常規配置reserver型監聽器，監聽埠60020（上面圖中6002少寫了個0…）

3.proxy.aspx上傳至目標服務器，訪問：

4.stinger_server.exe 上傳到目標服務器，執行命令：

start D:\stinger_server.exe 0.0.0.0

5.跳板機本地執行命令：

stinger_client -w http://10.1.1.1:8080/2.aspx-l 0.0.0.0 -p 4002

6.免殺處理一下resever_bind，上傳至目標并執行不上線，執行一下tasklist發現shell.exe已經執行了，就是不上線，pystinger報錯，【網路安全學習資料·攻略】

1. 最后的結果是，報錯，具體原因不知道，可能是目標web環境有問題，可能是reserver型shell通訊有問題，
   遂Pystinger反代上線cs失敗，

坑點二：正向代理+正向shell上線公網CS

既然反向代理行不通，那就用正向代理，然后采用正向shell來連接，
目標機器不出網，本機能出網，可通過本機當作跳板機將目標機器的正向shell帶出來，
原理圖：

常見的http隧道工具Neo-reGeorg、reGeorg（應該這兩款用的比較多）能適用于大多數網路環境，但是在這里就是不行，會出現跳板機直接與cs服務器斷開的情況，而cs的connect正向連接請求是由跳板機的beacon發出的，你只能將beacon代理進socks隧道才能使connect請求能連接正向shell的監聽埠，但因為目標機不出網，在跳板機的beacon進入代理隧道之后是無法連接到處于公網的cs服務端的，所以只能是埠對埠映射，而不能用http協議搭建的socks隧道（我猜的），

所以這里將使用ABPTTS進行http隧道搭建，

• ABPTTS優點 對抗特征檢測十分優秀 創建的隧道十分穩定

1、 配置abptts：

python abpttsfactory.py -o server \\生成服務端腳本，初始化，

2、 上傳server腳本到目標機器

坑點三：檔案上傳

這個地方冰蝎、大馬都傳檔案傳不上去，只能用哥斯拉的大檔案上傳把abptts.aspx傳了上去（后面exe的上傳也是用的哥斯拉的大檔案上傳功能）exe檔案落地也是個坑，在正常環境中，我們可以用certutil、powershell等方法下載exe到目標上，但是這臺機器他不出網，因為出站規則的原因，甚至都無法訪問內網中其他機器的web服務器，最后用哥斯拉的大檔案上傳解決了這個問題，

上傳完成之后的abptts.aspx地址：http://10.1.1.1:8080/abptts.aspx
訪問一下abptts.aspx，頁面回顯一長串密文說明abptts客戶端正常

3、 啟動http隧道

Python abpttsclient.py -c server/config.txt -u "http://10.1.1.1:8080/abptts.aspx"-f 127.0.0.1:7777/127.0.0.1:1111

這里的127.0.0.1:7777是本機埠，127.0.0.1:1111是目標機的埠
意思是將目標機的1111埠通過http隧道映射至本機的7777埠，你向本地的7777埠發送的請求都將轉發至目標機的1111埠，

坑點四：正向Bind免殺

Cs的正向shell介紹（beacon tcp）

正向shell的作用原理是，bind在目標機器上開放一個監聽埠，等待其他主機來訪問這個監聽埠，子Beacon從父Beacon接受請求，而不是直接與cs服務端通訊，
而反向shell則是，由目標發起請求訪問cs服務端的監聽埠

1.創建一個正向監聽器：

2.生成正向載荷（在生成正向載荷的時候只能選擇stageless Beacon ）：

為什么使用正向shell：

假若目標機器的出站規則十分嚴格且目標也不出網，反向shell在這種情況下則無法正常與cs服務端保持通訊，
假若采用正向shell的話，在無論他的入站規則多嚴格，他也不會去阻止本地埠之間的通訊，這樣就能繞過嚴格的出入站規則策略，

• 通訊程序：

Cs服務端（公網）–> 跳板機（父baecon）–> 7777埠–> 目標8080埠（http隧道）–> 目標1111埠（子baecon）

• Bypass分析

在目標機的防火墻眼中是本地的8080埠與本地的1111埠通訊，而攻擊機與目標的8080埠則是正常被允許的互動行為，從而bypass了出入站策略，

正向Bind免殺

上面有提到過目標上有火絨和WD兩款殺毒，直接上傳正向shell肯定是會被秒殺的，本地測驗報毒，

Reserver_Bind免殺較為簡單，直接生成shellcode，通過分離免殺等方法加載shellcode，
但是正向shell不能生成shellcode，它屬于stageless型Beacon，而stageless型Beacon無法生成shellcode，所以無法通過常規的分離式免殺來繞過殺毒，

• 提一下stager與stagerless的區別： stager和stagerless型beacon
• Stager型：只包含簡單的加載邏輯部分，stager通過將c2的payload加載進記憶體從而實作pe加載，這種加載方式也就是反射型DLL加載，
• Stagerless型：stager+payload全寫死在木馬中，相比較于Stager型體積更大，特征碼更明顯，
  由下圖可以看到，在生成payload的時候沒有正向bind監聽器這個選項，只有Reserver監聽器選項，

• 既然無法通過混淆加載器的方法來免殺，那就加強殼+定位特征碼的方法來免殺，
• 國內大部分殺軟估計都是基于模糊hash演算法的特征碼查殺，對代碼層強混淆幾乎就能繞過大部分殺毒，強殼（ASPack、upx、Safengine、VMPoject，實測Aspack、upx效果不是很好），
  主要用到的工具：VirTest5.0+ Resource Hacker +SafengineShielden+upx
• VirTest5.0： 自動化定位特征碼，因為不會匯編，所以就直接用010Editor修改特征碼的十六進制來破環特征碼，

• 其他修改特征碼的方法: 替換匯編函式、調換指令順序、置零跳轉， 注意：在修改完特征碼之后，要測驗exe還能不能正常運行，
• SafengineShielden 反LPK注入、反除錯器附加、反記憶體轉儲選上，復雜度拉滿，虛擬機檢測不要打勾，

• 最后加一層upx殼(upx殼視情況而定，有時候加了upx殼反而會被殺)，Resource Hacker加入一個任意圖示檔案，成功過掉火絨，

目標機運行正向shell

上傳正向bind，在冰蝎上執行 D:/beacon_se.exe，可以看到木馬在目標機上開啟了1111埠，我們通過http隧道去連接這個位于目標機1111埠上的正向bind，【網路安全學習資料·攻略】

本機（跳板）正向連接shell

本機（攻擊者）上線cs作為跳板機，然后在本機shell中執行

connect 127.0.0.1 7777

成功正向上線 10.1.1.1，但是上線的shell權限極低，mimikatz無法運行，因為正向shell的原因，就算提權成功也無法直接反彈shell，而且因為目標系統是2016，插件中的常見提權腳本都會提權失敗，

PrintSpoofer提權

上傳PrintSpoofer.exe至目標主機，

執行如下命令，以system的權限運行我的正向shell，那么我將得到一個system權限的shell，而不是asp的低權限shell，

C:\Windows\Temp\PrintSpoofer -c D:/1111_se.exe

Netstat -ano確認一下有沒有在本地開放一個1111埠，

正向shell正常運行，跳板機再次連接正向bind，

connect 127.0.0.1 7777

成功提權，滲透至此已基本結束戰斗，得到一個system權限的正向shell，mimikatz抓密碼，無明文，但能拿到hash，【網路安全學習資料·攻略】

繞過殺毒添加用戶&&登錄桌面

Net1改名添加用戶，報錯，必然是被火絨攔截了，上殺器直接驅動層干殺軟，

本地實驗能干掉，但是不知道為什么在目標上就實作不了，

換思路：火絨、360等國內殺毒攔截添加用戶命令往往只針對net、net1這倆行程，并沒有hook底層函式，所以我們只需要不去執行net、net1而去直接呼叫底層函式就能繞過殺毒的監控，
原理不去深度刨析了，網上有文章，

• Windows API 添加管理員用戶 專案地址：https://github.com/newsoft/adduser
  繞過殺毒添加上了一個用戶，接下來就是常規操作，用列印機漏洞提權，利用sys權限切換到adminsitrator用戶的桌面，
• hash傳遞攻擊 再或者就是hash傳遞，直接上adminsitrator的桌面，

sekurlsa::pth /user:Administrator /domain:用戶名 /ntlm:194f34439dd27846db00c6723036da6b "/run:mstsc.exe /restrictedadmin"194f34439dd27846db00c6723036da6b

Hash傳遞的好處就是，動靜更小，不需要新建用戶，留下的痕跡更少，降低攻擊者被發現的概率，
如下圖：

跟上面操作一樣，把對方的3389埠反向代理至本地，連接之，
最后附上登錄的桌面的截圖，登上來就是一個backstab的報錯，這剛好就解釋了之前在干火絨的時候，為什么沒有kill成功（因為程式兼容性問題導致崩潰了），

總結

總結一下整個滲透程序中有趣的幾個點，整個流程大概花了兩天的時間，主要是有幾個地方踩坑了，

第一點： 寫http隧道馬的時候，用哥斯拉直接編輯新建一個隧道馬，但是連接的時候報錯，可能是哥斯拉出現了資料斷流，導致寫進去的檔案缺東西了，后來直接把隧道馬傳上去就不報錯了，
第二點： 網上的例子大多數都用pystinger反代cs服務端來處理這種不出網上線cs的情況，但是可能因為目標網路環境的不一樣導致各種玄學報錯，所以Pystinger的局限性還是很大的，而且Pystinger客戶端還不免殺，
第三點： 正向shell免殺，不多說的，cs的無階段木馬都是這樣，無法通過混淆加載器的方法免殺，
第四點： 正向shell的提權，cs插件提權只能反彈一個反射型的shell，無法反彈正向shell，
第五點： 有趣的是，無階段木馬是能生成powershell腳本的，而powershell腳本是很好混淆免殺的，但是目標是server2016，默認開啟AMSI，混淆免殺在它面前形同虛設，（要是目標是2012、2008系統就可以通過powershell正向bind上線）

結尾

本還可以嘗試msf的正向bind，自帶混淆器，效果可能更好，
本次滲透是在獲得授權的真實環境中進行的，
在利用pystinger反向代理套反向shell失敗的情況下，改用正向代理中套正向shell來上線不出網主機，

最后

關注我，持續更新！私我獲取【網路安全學習資料·攻略】