標題：內網滲透--突破安全策略上線CS

[taibeihacker]

前言​

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

环境简述说明​

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反代操作。

本地起一個cs服務

常規配置reserver型監聽器，監聽端口60020（上面圖中6002少寫了個0.）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報錯。

最後的結果是，報錯，具體原因不知道，可能是目標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服務端的監聽端口創建一個正向監聽器：

生成正向載荷（在生成正向載荷的時候只能選擇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型beaconStager型：只包含简单的加载逻辑部分，stager通过将c2的payload加载进内存从而实现pe加载，这种加载方式也就是反射型DLL加载。Stagerless型：stager+payload全写死在木马中，相比较于Stager型体积更大，特征码更明显。由下圖可以看到，在生成payload的時候沒有正向bind監聽器這個選項，只有Reserver監聽器選項。

既然無法通過混淆加載器的方法來免殺，那就加強殼+定位特徵碼的方法來免殺。国内大部分杀软估计都是基于模糊hash算法的特征码查杀，对代码层强混淆几乎就能绕过大部分杀毒，强壳（ASPack、upx、Safengine、VMPoject，实测Aspack、upx效果不是很好）。主要用到的工具：VirTest5.0+Resource Hacker+SafengineShielden+upxVirTest5.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的桌面。 sekurlsath /user:Administrator /domain:用戶名/ntlm:194f34439dd27846db00c6723036da6b '/run:mstsc.exe /restrictedadmin'194f34439dd27846db00c6723036da6b
Hash传递的好处就是，动静更小，不需要新建用户，留下的痕迹更少，降低攻击者被发现的概率。如下圖：

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