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 流量已经是一个非常古老的技术了，那为啥今天还要聊这个话题呢，原因主要有一下两点：
-
虽然古老，但仍然有用
-
我最近也在写一些自动化构建 Red Team 基础设施的文章，为了保证这个系列文章的完整性，所以先搞一些前菜
CDN 的原理都大同小异，该方法理论上也适用于其他 CDN 服务提供商，有兴趣的师傅可以测试试试。（有一个坑点是，AWS 中国区的 CloudFront 服务出于域名备案合规的角度考虑没有办法直接访问 CloudFront 的 endpoint，只能将已备案域名 CNAME 到其 endpoint 上，通过这个已备案域名进行访问。）
0x01 为什么利用 CloudFront 中继 Cobalt Strike 流量仍然是有价值的？
-
No need for a categorized domain for C2 traffic （不需要 C2 流量的分类域。实话说这句话我没看懂，啥叫分类的域名？懂行的师傅帮忙科普一下...）
-
C2 流量在某种程度上与 CDN 流量融为一体
-
很多企业将 CloudFront 设为白名单
-
由于源 IP 是隐藏的，因此不需要频繁的替换 C2 基础设施
-
C2 流量采用 HTTPS 通信
0x02 本文重点
-
配置 Cobalt Strike 的 Teamserver
-
注册一个新的域名并将其解析至 Cobalt Strike 的 Teamserver
-
为域名生成 HTTPS 证书
-
创建 CloudFront distribution 并将其指向我们注册的域名
-
生成 CS profile 利用 HTTPS 证书以及我们创建的 CloudFront
-
生成 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。
证书生成成功：
0x06 创建 CloudFront distribution 并将其指向我们注册的域名
此处选择支持“GET、HEAD、OPTIONS、PUT、POST、PATCH、DELETE”的 HTTP 方法其他配置默认即可。
这里有一个坑点，是 CloudFront 的 Feature 更新了，我们要禁用缓存策略，并设置为完整的请求包转发，方可正常上线。
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>
0x08 生成 Cobalt Strike Payload 进行测试
可以成功上线：
0x09 后记
纸上得来终觉浅，绝知此事要躬行，最终达到的效果：
-
C2 Server 的 HTTPS/443 端口仅接受从 CloudFront 进来的流量，其他途径访问该端口时，端口处于关闭状态（奥，这里还有个知识点，就是要将后端 teamserver 的安全组要设置为仅接受从 CloudFront 进来的入站流量。） -
C2 Server 的 SSH 和 Cobalt Strike Team server 服务仅能从内部访问，避免暴露到互联网
0x10 References
-
Using CloudFront to Relay Cobalt Strike Traffic - https://www.blackhillsinfosec.com/using-cloudfront-to-relay-cobalt-strike-traffic/ -
Cobalt Strike Java Dependency - https://www.cobaltstrike.com/help-java-dependency -
安全研究 | 隐藏你的C2域名 - https://www.freebuf.com/articles/network/240649.html -
Malleable Command and Control - https://www.cobaltstrike.com/help-malleable-c2 -
Apache on Debian 10 (buster) - https://certbot.eff.org/lets-encrypt/debianbuster-apache
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论