前言

本文为一篇利用非常规手段突破安全策略的内网渗透记录

环境简述 &说明

• web 打点 getshell，webshell 是冰蝎，权限为.net，权限很低，服务器为 server 2016，目标不出网！

• 装有杀毒软件（火绒、微软自带的 WD），ASMI 默认开启，而且对 power shell 有特殊策略限制。

• Tcp、icmp、DNS 协议不通，无法直接与公网的 cs 服务端建立连接，（内网的 cs 服务端也无法与其建立连接）公网也无法访问目标 web 服务（纯内网 web 服务）

• 极其严格的出入站策略

  
  

  入站规则：只有 http 允许入站，只有一个 80、8080 两 http 端口能供内网机器正常访问

  
  

  出站规则：不允许非 8080 端口对外通讯。

  
  

  手绘了一张拓扑图，将就着看一下。

为了感谢广大读者伙伴的支持，准备了以下福利给到大家：【一>所有资源获取<一】1、200 多本网络安全系列电子书（该有的都有了）2、全套工具包（最全中文版，想用哪个用哪个）3、100 份 src 源码技术文档（项目学习不停，实践得真知）4、网络安全基础入门、Linux、web 安全、攻防方面的视频（2021 最新版）5、网络安全学习路线（告别不入流的学习）6、ctf 夺旗赛解析（题目解析实战操作）

为什么要上线 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 服务

1. 常规配置 reserver 型监听器，监听端口60020
   

2. 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 服务端的监听端口

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 而去直接调用底层函数就能绕过杀毒的监控。原理不去深度刨析了sekurlsa::pth /user:Administrator /domain:用户名 /ntlm:194f34439dd27846db00c6723036da6b "/run:mstsc.exe /restrictedadmin"194f34439dd27846db00c6723036da6b

Hash 传递的好处就是，动静更小，不需要新建用户，留下的痕迹更少，降低攻击者被发现的概率。如下图

跟上面操作一样，把对方的 3389 端口反向代理至本地，连接之。

最后附上登录的桌面的截图，登上来就是一个 backstab 的报错，这刚好就解释了之前在干火绒的时候，为什么没有 kill 成功（因为程序兼容性问题导致崩溃了）。

结尾

总结一下整个渗透过程中有趣的几个点，整个流程大概花了两天的时间，主要是有几个地方踩坑了。

1. 第一点：写 http 隧道马的时候，用哥斯拉直接编辑新建一个隧道马，但是连接的时候报错，可能是哥斯拉出现了数据断流，导致写进去的文件缺东西了，后来直接把隧道马传上去就不报错了。

2. 第二点：网上的例子大多数都用 pystinger 反代 cs 服务端来处理这种不出网上线 cs 的情况，但是可能因为目标网络环境的不一样导致各种玄学报错，所以 Pystinger 的局限性还是很大的，而且 Pystinger 客户端还不免杀。

3. 第三点：正向 shell 免杀，不多说的，cs 的无阶段木马都是这样，无法通过混淆加载器的方法免杀。

4. 第四点：正向 shell 的提权，cs 插件提权只能反弹一个反射型的 shell，无法反弹正向 shell。

5. 第五点：有趣的是，无阶段木马是能生成 powershell 脚本的，而 powershell 脚本是很好混淆免杀的，但是目标是 server2016，默认开启 AMSI，混淆免杀在它面前形同虚设。（要是目标是 2012、2008 系统就可以通过 powershell 正向 bind 上线）