0×00 前言

由于Cloudflare会检查HTTPs请求中的SNI和Host字段能否对应上，所以在Cloudflare利用Domain fronting几乎是不可能的，不过@digininja的这篇文章好像是测试了Cloudflare暂时还不会检查ESNI，有兴趣的可以试试用这个方法。至于这个算不是算是Domain fronting，可见@digininja和@grittygrease之间的几番交流。

0×01 准备工作

两台VPS服务器，一个域名

先画一下C2基础设施的构造：

0×02 配置Team Server

为了达到比较好的OpSec，我这里使用iptable禁止任何外部地址访问Team Server的端口50050，只能用VPN通过localhost访问C2服务器，同时禁止外部地址访问C2服务器的80端口和443端口（分别用作http beacon和https beacon监听器），仅接受来自Nginx转向器的转发过来的请求。

启动Cobalt Strike Team Server：

分别测试80，443，50050端口的可访问情况：

从Nginx转向器发起请求：

从本地发起请求：

0×03 Nginx 转向器

为了待会添加Cloudflare Worker的反向代理就把SSL证书也申请了，让Nginx能同时接受http beacon和https beacon。因为team server启动的时候没有指定Malleable-C2-Profile，所以Cobalt Strike生成的payload请求所带的user-agent是随机生成的。这里就先不通过user-agent来判断请求是否来自beacon载荷，仅做转发。

Nginx配置：

先测试一下转发到9999端口：

第一个是proxy_pass https://localhost:9999;，第二个是proxy_pass https://localhost:9999;

结果：

连接到Team Server测试下是否能正常投递载荷：

先测试下能否访问/a：

Weblog接收到请求：

虚拟机上测试上线：

能成功下载载荷并执行上线，但是Wireshark能观察到一次对Nginx转向器域名的DNS解析请求，以及beacon频繁与Nginx转向器通信的可疑http流量。

0×04 添加Cloudflare Worker

Cloudflare必须要用户有在Cloudflare添加域名，才能够使用它所提供的Worker服务，至少我这个新注册的Cloudflare帐号时是添加了这个测试使用的域名以后才能继续。

创建Worker

Worker的创建千万要注意这个取的名字会出现在这里 xxxxxxxx.<Worker的名字>.worker.dev，而且不能再次更改了，只有一次机会。

注册一个名为microsoftupdate的Worker，那么该Worker得到的子域名就是：microsoftupdate.worker.dev

创建一个Worker script：

写入转发请求的js脚本，并设置一个四级域名保存并部署：

直接使用Cloudflare Worker提供的debug工具测试：

测试/a路径：

添加Malleable-C2-Profile

这次为Team Server加上Malleable-C2-Profile，将Host都更改为Cloudflare分配到的子域名，更改User-Agent为Mozilla/5.0 (MSIE 9.0; Windows NT 6.1; EN_GB)，同时也为http-stager也添加上上述user-agent请求头。

更新Nginx配置：

由于Cobalt Strike默认的脚本投递路径就是/a，所以这里指定了/a转发给C2服务器，不然powershell没法下载到载荷。

编辑监听器，将Host改为Cloudflare Worker子域名：

Attack-> Web Drive-by -> Scripted Web Delivery，将Host更改成Cloudflare Worker子域名：

下载并执行载荷：

Web log：

执行命令：

Wireshark：

Stager发出的Get请求：

此时beacon通信的IP均是Cloudflare Worker的edge server其实也就是CDN节点，在Security Trails里能搜到许多与该ip关联的域名。不足之处是beacon通讯全是加密的http请求，噪音非常大，由于我的Cobalt Strike没法启用ssl投递载荷，就没有测试使用https的beacon通信了。如果改用https，Wireshark抓包仅能在下载第一阶段载荷观察到一次对bing-settings-data.microsoftupdate.workers.dev的解析请求，以后的通信就都是发生在受害者与Cloudflare之间的TLS了，更加的隐蔽。理想状态下，应该有第三台专门用于投递载荷的机器，在投递完成后即可撤出。此外，由于Cloudflare的节点ip都是公开的，所以可以爬取所有Cloudflare节点ip后让Nginx转发器仅接受来自Cloudflare节点转发过来的请求，从而降低搜索引擎抓取并记录到nginx转发器指纹的风险。

参考

https://digi.ninja/blog/cloudflare_example.php

https://github.com/Siujoeng-Lau/Workers-Proxy

原文地址：https://www.freebuf.com/sectool/232555.html