还在用winrm吗？浅谈http.sys的使用姿势

编者注：1.本文仅供学习研究，严禁从事非法活动，任何后果由使用者本人负责。2.本文一切操作都在管理员权限之下。

1. 什么是http.sys

http.sys是一个Windows系统的核心组件，能够让任何应用程序通过它提供的接口，以http协议进行信息通讯。微软在Win2003加入了Http.sys，用于侦听http流量并根据URL进行处理，允许任意用户进程共享专用于HTTP流量的TCP端口。也就是说，多个程序可以使用同一端口进行http的监听，而Http.sys充当了nginx的⻆色。通过netsh命令可以对http.sys的命名空间进行一系列操作，比如说IIS服务器，它的最底层就是HTTP.sys驱动。

HTTP.sys有两个特点：

1. 1. 允许端口复用，可以让多个程序使用同一个端口进行监听。

2. 2. 对HOST敏感，可以通过HOST进行分发流量。

系统当中会有一些默认的http.sys的保留注册项，如下：

而目前业内的普遍用法是使用5985端口的WinRM注册项，将其迁移到80端口进行复用,由于winrm服务在系统自带的命名空间当中已经被注册，命名空间与winrm程序之间已经有对应了，所以将winrm开在80端口就可以了，由于存在IIS的服务器，IIS的80端口占用也是在Http.sys之后，所以并不会有什么报错。

#将winRM迁移至80
winrm set winrm/config/Listener?Address=*+Transport=HTTP @{Port="80"}
#将winRM还原为5985
winrm set winrm/config/Listener?Address=*+Transport=HTTP @{Port="5985"}
#客户端连接命令
winrs -r:http://ip -u:user -p:pwd "whoami"
#pwd可为hash

2. 为什么研究它

由于针对Linux已经有比较成熟的端口复用手段，比如使用iptables与socks5脚本相结合，而我们一直只知道存在Windows的http.sys，并且知道这东西能复用，但是不知道如何复用，没有进行工具化。

3. HTTPS 隧道

在一开始，最理想的状态就是通过http.sys起一个HTTPS proxy的服务，让客户端通过HTTP CONNECT method来使用HTTPS代理服务。然而事实却是残酷的。

一起看一下HTTPS Proxy 的包：

可以看出，PATH与HOST都是代理的目标与端口，继续测试。

不难看出，HTTP CONNECT方法是不允许使用/作为uri的，我们再来看下HTTP.sys的注册要求。

矛盾点出现了，HTTP CONNECT不能有/，HTTPSYS必须要/。改协议？改驱动？显然是不可能的，这条路放弃。

4. 网站管理工具

都研究这么久了，放弃http.sys研究定是不甘心的，思考之后我想到了可以通过他得天独厚的优势，做个网站管理工具。于是我开始找相关的项目，最后找到了一个HTTP.sys的Demo：

https://docs.microsoft.com/en-us/windows/win32/http/http-server-sample-application

进行一系列修改，得到了Joker工具。

https://github.com/ZhuriLab/Joker

4.1 基于路径复用

Joker.exe "http://*:{PORT}/{PATH}"

可直接使用一些网站管理工具进行连接，配置如下：

 连接密码随便填写。

4.2 基于HOST进行复用

Joker.exe "http://{HOST}:{PORT}/"

配置如下：

这样，在正常访问80端口的时候为正常业务，在带特殊的host访问80端口的时候则为网站管理程序。

5. 适配Regorg

正当整个研究要结束时，有一个工具在我的脑海里浮现了出来——Regeorg，一款TunnelWebShell工具。他的使用情景也是在不出网的地方进行正向代理，它虽然不能采用CONNECT方法，但是使用GET、POST方法进行数据传输同样也能得到隐藏的目的。

我于是写了一个适配regeorg的demo，也就是开源在Joker当中的JokerTunnel。

使用方法：

1. 1. Server端执行 tunnel.exe <url1> <url2> <url3> ...

2. 2. 使用regeorg客户端连接。

本地测试访问某购物网站速度还可以：

6. RD网关（域环境）

就当研究即将结束的时候，我突然想到这一个问题，是不是所有Windows自带的Web类型的系统服务都是通过HTTP.sys进行端口开放的？若是这样，岂不是可以通过端口复用的方式进行远程桌面连接？话不多说，开始搞。

在Win2019上进行测试，开启RD远程桌面网关，看下http.sys保留注册项的变化。

• 未安装RD网关

• 安装RD网关

当RD网关安装完成后，可以发现http.sys多了两个443端口的注册项，证明了之前的猜想，RD网关确实是通过http.sys启动的，那么下一步就配置一下进行远程桌面与Web的复用。正当我配置RD过程中，服务器管理器显示了这句话：

翻阅过大量文献后，我发现RD Gateway 需要域环境，那就在域环境去搞吧。

6.1 开启RD服务

6.2 配置RD Gateway

进入RD 网关资源策略。

选择认证方式与可登录的组员。

配置网络资源，配置RDGW可以连接到所有域内机器。

6.3 安装SSL

创建自签名证书。

将证书导出，并安装到远程客户端机器（攻击机），远程客户端机器需要将DNS解析到域DNS上或者绑定hosts文件。

6.4 创建服务器场

将需要远程拨上去的机器域名或者ip添加到服务器场。

6.5 远程登录

更改本地的mstsc的配置，配置如下：

远程计算机输入域内机器，进行登录，登录过程中会使用两次凭据，一次为RD网关的凭证，一个是登录目的机器的凭证。

从流量上来看，通过RD网关远程登录的机器，客户机与远程机器是完全没有流量交互的，再看下RD网关的情况。

可以看出，客户机与RD网关完全是通过443进行流量交互的。

而正常情况下，去访问RD网关机器的443端口是一个Web界面。

6.6 总结

RD网关的使用在步骤上整体非常繁琐，我们盘点一下需要的前置条件：

1. 1. 机器在域内。

2. 2. 需要明文的域票据。

3. 3. 步骤繁琐，很难将这些操作转换为命令行命令。

4. 4. 防火墙允许443端口入站。

总体来讲，使用RD网关远程桌面登录进行网站管理，配置步骤会很繁琐，前置条件也较多，若管理员只是为了传输文件或者不需要GUI界面，则Joker的启动方式会更为方便一些。