利用 CloudFront 中继 Cobalt Strike 流量

0x00 前言

本文主要分享一下如何利用 CloudFront 中继 Cobalt Strike 流量。

可以说这是一个非常古老的技术了，继各大云厂商（AWS、Azure、GCP、AliCloud）纷纷 fix 掉 Domain Fronting 的问题之后，我们只能找一些中小云厂商（名字我就不说了，说一个没一个）继续做 Domain Fronting。

效果只能说是一般般，因为本质上托管在这些中小型云厂商的资产在网络流量、域名侧的信誉度上相较 AWS 而言其实是大打折扣的，通俗的说就是大家都用 AWS 那内网看到 AWS 的流量也就见怪不怪了，如果出现了比较偏门的云厂商的网络流量，那反倒是个异常事件。

Domain Fronting 也是有检测方法的，对比 Host 和 TLS SNI 来判断是否为潜在的 Domain Fronting，但这不是本文的重点，不展开聊了。

如果我说错了，或者师傅们有更好的路子，还请多多指正和分享。

回到本文的主题，既然利用 CloudFront 中继 Cobalt Strike 流量已经是一个非常古老的技术了，那为啥今天还要聊这个话题呢，原因主要有一下两点：

1. 虽然古老，但仍然有用

2. 我最近也在写一些自动化构建 Red Team 基础设施的文章，为了保证这个系列文章的完整性，所以先搞一些前菜

CDN 的原理都大同小异，该方法理论上也适用于其他 CDN 服务提供商，有兴趣的师傅可以测试试试。（有一个坑点是，AWS 中国区的 CloudFront 服务出于域名备案合规的角度考虑没有办法直接访问 CloudFront 的 endpoint，只能将已备案域名 CNAME 到其 endpoint 上，通过这个已备案域名进行访问。）

0x01 为什么利用 CloudFront 中继 Cobalt Strike 流量仍然是有价值的？

1. No need for a categorized domain for C2 traffic （不需要 C2 流量的分类域。实话说这句话我没看懂，啥叫分类的域名？懂行的师傅帮忙科普一下...）

2. C2 流量在某种程度上与 CDN 流量融为一体

3. 很多企业将 CloudFront 设为白名单

4. 由于源 IP 是隐藏的，因此不需要频繁的替换 C2 基础设施

5. C2 流量采用 HTTPS 通信

0x02 本文重点

1. 配置 Cobalt Strike 的 Teamserver

2. 注册一个新的域名并将其解析至 Cobalt Strike 的 Teamserver

3. 为域名生成 HTTPS 证书

4. 创建 CloudFront distribution 并将其指向我们注册的域名

5. 生成 CS profile 利用 HTTPS 证书以及我们创建的 CloudFront

6. 生成 Cobalt Strike Payload 进行测试

0x03 配置 Cobalt Strike 的 Teamserver

AWS 上启一台 EC2（Debian Linux），并安装 Java 依赖：

`apt-get update && apt-get upgrade -y && apt-get install -y openjdk-11-jdk   `

安装并更新 Cobalt Strike：

`tar -xvf cobaltstrike-dist.tgz && cd cobaltstrike && ./update   `

0x04 注册一个新的域名并将其解析至 Cobalt Strike 的 Teamserver

这步没啥说的，找个域名服务提供商，注册个域名，配下 A 记录指向 Teamserver 即可。（这里有个小 tips，就是 AWS EC2 默认包含一个 DNS Name，我们可以将其设置为 CloudFront 的 Source，这样连域名都不用注册了。）

0x05 为域名生成 HTTPS 证书

可以采用 Let's Encrypt 生成免费的 HTTPS 证书。

本文中我们采用 HTTPsC2DoneRight.sh 生成 HTTPS 证书以及适用于 Cobalt Strike 的 C2 Profile。

安装命令如下：

`apt-get install -y git lsof   cd && wget https://raw.githubusercontent.com/killswitch-GUI/CobaltStrike-ToolKit/master/HTTPsC2DoneRight.sh && chmod +x HTTPsC2DoneRight.sh && ./HTTPsC2DoneRight.sh   `

安装过程中，会报如下错误：

`Skipping bootstrap because certbot-auto is deprecated on this system.   Your system is not supported by certbot-auto anymore.   Certbot cannot be installed.   Please visit https://certbot.eff.org/ to check for other alternatives.   `

解决方法如下：

`apt-get install snapd   sudo snap install core; sudo snap refresh core   sudo apt-get remove certbot   sudo ln -s /snap/bin/certbot /usr/bin/certbot   `

然后将 func_install_letsencrypt 修改为如下内容，再次执行 HTTPsC2DoneRight.sh 即可。

`func_install_letsencrypt(){     echo '[Starting] cloning into letsencrypt!'     # git clone https://github.com/certbot/certbot /opt/letsencrypt     echo '[Success] letsencrypt is built!'     # cd /opt/letsencrypt     echo '[Starting] to build letsencrypt cert!'     certbot --apache -d $domain -n --register-unsafely-without-email --agree-tos     if [ -e /etc/letsencrypt/live/$domain/fullchain.pem ]; then       echo '[Success] letsencrypt certs are built!'     else       echo "[ERROR] letsencrypt certs failed to build.  Check that DNS A record is properly configured for this domain"       exit 1     fi   }   `

执行完成之后，会生成一个 Amazon-based CS profile。

image

证书生成成功：

image

0x06 创建 CloudFront distribution 并将其指向我们注册的域名

此处选择支持“GET、HEAD、OPTIONS、PUT、POST、PATCH、DELETE”的 HTTP 方法其他配置默认即可。

image

image

这里有一个坑点，是 CloudFront 的 Feature 更新了，我们要禁用缓存策略，并设置为完整的请求包转发，方可正常上线。

image

0x07 生成 CS profile 利用 HTTPS 证书以及我们创建的 CloudFront

由于很多 CS profile 都已经被安全设备识别并标记，因此本节我们生成一个新的 CS profile 以更好的满足我们的需求。

这里直接采用 Malleable-C2-Randomizer 进行生成。

`cd && git clone https://github.com/bluscreenofjeff/Malleable-C2-Randomizer && cd Malleable-C2-Randomizer      python malleable-c2-randomizer.py -profile Sample\ Templates/pandora.profile -notest   `

将 amazon.profile 中 https-certificate 块的内容复制到新生成的 pandora__NuCZ1FlL.profile 下。

从 OpSec 的角度考虑，需要改变 payload 默认 spawn 的进程，此处添加如下 post-ex 代码片段，将其 spawn 到 mstsc.exe 进程。

`post-ex {                   set spawnto_x86 "%windir%\\syswow64\\mstsc.exe";           set spawnto_x64 "%windir%\\sysnative\\mstsc.exe";   }   `

同时将 C2 Profile 中的两处 Host 替换为 CloudFront 的 endpoint。

关闭生成证书的过程中用于测试的 apache2 服务，避免与我们的 Listener 冲突。

`service apache2 stop   `

启动 Cobalt Strike 的 Team Server

`./teamserver <IP OF CS SERVER> <PASSWORD FOR SERVER> <PATH TO PANDORA PROFILE> <C2 KILL DATE>   `

image

0x08 生成 Cobalt Strike Payload 进行测试

image

可以成功上线：

image

0x09 后记

纸上得来终觉浅，绝知此事要躬行，最终达到的效果：

1. C2 Server 的 HTTPS/443 端口仅接受从 CloudFront 进来的流量，其他途径访问该端口时，端口处于关闭状态（奥，这里还有个知识点，就是要将后端 teamserver 的安全组要设置为仅接受从 CloudFront 进来的入站流量。）

2. C2 Server 的 SSH 和 Cobalt Strike Team server 服务仅能从内部访问，避免暴露到互联网

0x10 References

1. Using CloudFront to Relay Cobalt Strike Traffic - https://www.blackhillsinfosec.com/using-cloudfront-to-relay-cobalt-strike-traffic/

2. Cobalt Strike Java Dependency - https://www.cobaltstrike.com/help-java-dependency

3. 安全研究 | 隐藏你的C2域名 - https://www.freebuf.com/articles/network/240649.html

4. Malleable Command and Control - https://www.cobaltstrike.com/help-malleable-c2

5. Apache on Debian 10 (buster) - https://certbot.eff.org/lets-encrypt/debianbuster-apache