基于Caddy实现的C2前置代理 – RedCaddy

渗透技巧 1年前 (2023) admin
359 0 0

基于Caddy实现的C2前置代理 – RedCaddy

Author:小离-xiaoli

0x01 Intro

  • • 起因:

    • • 发觉每次部署CS,尤其是,都挺麻烦,于是就萌生了写一款能够一键部署好前置代理的工具。

    • • 期间尝试过RedGuard,RedWarden,其中的话,RedGuard一使用自个的profile就报错了,应该是parser没弄好,而RedWarden的话,写得很完美了,但是beacon一多,就会有很大延时(性能下降),但是两款工具都非常好了,RedGuard有自动配置假ssl证书,但是看上去不支持多个端口,作者的思路是通过假host头去进行流量转发,配置依旧不够灵活;RedWarden的话,配置很详细,性能问题除外,其他都很好。

    • • 后面看到了c2modrewrite,该项目的思路就是用apache和nginx这种成熟的http服务去一键生成针对proifle的流量转发配置(主要是识别uri path)就不用像上述两款项目一样重写一个转发器。

    • • 结合上述三款项目的思路,于是就有了现在这个项目.


0x02 设计思路

主要围绕以下5点

  • • Core

  • • Basic blacklists (UA & IP)

  • • Header matcher & Reverse proxy (main)

  • • GeoIP

  • • SSL

扩展围绕以下2点

  • • Teamserver端口保护

  • • 真白名单上线

0x001 First: core

1、首先的话,我们就不手撸一个http服务作为核心了(作者也没那本事),我们可以选中已有的开源http服务作为核心,这里选中了caddy作为核心,主要是配置挺方便,性能也高 

基于Caddy实现的C2前置代理 - RedCaddy

2、Caddy需要修改一下tls部分,使其支持老系统(win7 / windows2008)https上线(但是可惜的是,2003只支持SSL2.0,而caddy本身不支持SSL2.0),以下两个commit是必须 

基于Caddy实现的C2前置代理 - RedCaddy

3、个人经过多次实战测试发现,Caddy的配置文件还需要加上这一段算法支持,才能完全支持老系统上线 

基于Caddy实现的C2前置代理 - RedCaddy

4、为了实现GEOIP和后面的扩展,需要添加两个外部模块(包含在了上述commit中) 

基于Caddy实现的C2前置代理 - RedCaddy

0x002 Second: Basic blacklists

1、基本黑名单是给我们普通模式下防护用的,防止恶意IP,沙箱IP,防止沙箱以及空间测绘之类的,黑名单IP用的是RedGuard + 自己实战抓的沙箱ip,一点点的补充上去 

基于Caddy实现的C2前置代理 - RedCaddy

2、UA头黑名单,这个思路是来自以下文章 [?? Carrying the Tortellini’s golf sticks | APT::WTF – APTortellini’s blog (aptw.tf)]https://aptw.tf/2021/11/25/c2-redirectors-using-caddy.html 

基于Caddy实现的C2前置代理 - RedCaddy

3、还有基本安全配置 

基于Caddy实现的C2前置代理 - RedCaddy

4、结合上述三点,在Caddy配置文件里面可以这样呈现 

基于Caddy实现的C2前置代理 - RedCaddy

0x003 GEOIP

1、从RedWarden学来的思路,我们还可以用GEOIP来限制国家IP上线,本人的话就限制只能CN上线即可 

基于Caddy实现的C2前置代理 - RedCaddy

2、记得要在caddy添加GEOIP模块 

基于Caddy实现的C2前置代理 - RedCaddy

0x004 Header matcher & reverse proxy

1、使用严格的转发策略,要headers完全匹配了,才能上线,caddy对于这块处理,不吃性能;对于用了CDN的,可以把来源头带有x-forwarded-for继续转发给CS,让CS识别为来源IP,没使用CDN的话,就把x-forwarded-for填入来源IP转发给CS即可 

基于Caddy实现的C2前置代理 - RedCaddy

这也意味着CS profile的set trust_x_forwarded_for "true";必须一直开着

2、对于Host头伪造,只能伪造证书SAN里面有的域名,星号则意味着你能随便伪造xxx.jd.com之类的host头,因为caddy会对host头去认证回你自己的证书 

基于Caddy实现的C2前置代理 - RedCaddy

0x005 SSL证书伪造

1、原先是用carboncopy的思路,使用python库去伪造SSL证书,后面在实战过程中遇到了很多奇奇怪怪的问题,上不了线,Caddy提示证书有问题之类的情况(mkcert项目也一样的情况) 

基于Caddy实现的C2前置代理 - RedCaddy

2、后面使用了这个帖子,使用openssl生成一张假的证书即可 [How to create an HTTPS certificate for localhost domains (github.com)]https://gist.github.com/cecilemuller/9492b848eb8fe46d462abeb26656c4f8

3、self-signed-cert.py 

基于Caddy实现的C2前置代理 - RedCaddy

4、同时会生成store文件,直接在cs用就可以了 

基于Caddy实现的C2前置代理 - RedCaddy

0x006 扩展1:Teamserver Guard

1、善用CGI模块,即可做出一个白名单模式去保护Teamserver后端,使用特殊头 + 特殊链接访问触发添加iptables接受来源ip流量,才能访问到teamserver连接端口 

基于Caddy实现的C2前置代理 - RedCaddy

2、特殊URL可以随机生成,给自己的队友知道就好了,得益于反向代理的强大,我们可以把它放在和cs回连的端口,如图,443也是CS上线交互的端口 

基于Caddy实现的C2前置代理 - RedCaddy

3、后端脚本 

基于Caddy实现的C2前置代理 - RedCaddy

4、效果如下,触发之前无法访问到teamserver,之后就可以,有效防止爆破,如图当前是不能访问到50050 

基于Caddy实现的C2前置代理 - RedCaddy

After 

基于Caddy实现的C2前置代理 - RedCaddy

0x007 扩展2:真白名单上线模式

1、实现:目标机器触发请求到前置代理,前置代理执行脚本发送信息到钉钉机器人问你是否上线,期间会有60秒冗余时间让你选择,60秒内,目标机器的流量将会进入拒绝模式,防止蓝队人员进行扫描,爆破,在60秒内,你在钉钉将会收到上线信息,如果超过60秒,该IP的流量将不会继续拦截(依旧不能上线CS),意味着你还能继续发送上线申请

如图所示,超时了没有点击上线的,提示链接过期 

基于Caddy实现的C2前置代理 - RedCaddy

允许 

基于Caddy实现的C2前置代理 - RedCaddy

拒绝 

基于Caddy实现的C2前置代理 - RedCaddy

2、可以使用go写一个敲门的东西触发请求(用完记得删),落地到受害者机器上执行 

基于Caddy实现的C2前置代理 - RedCaddy

3、同时这几种状态的IP地址,都会被记录下来,deny和others的,一般都是蓝队人员的ip了,意味着他们抓到了你的敲门工具 

基于Caddy实现的C2前置代理 - RedCaddy

4、后端脚本,bash脚本负责初始化,然后后面交给python脚本处理,60秒过后放行(依旧不能上线CS) 

基于Caddy实现的C2前置代理 - RedCaddy

5、Python脚本,在进入60秒内,会起一个随机端口 + 随机uri的链接用作接收信号,发送到钉钉(本人不会用钉钉的outgoing方法,临时想到这种歪门邪道) 

基于Caddy实现的C2前置代理 - RedCaddy

6、flask端收到信号后,会立即关闭服务 

基于Caddy实现的C2前置代理 - RedCaddy

7、钉钉提醒(机器人关键字whitelist) 

基于Caddy实现的C2前置代理 - RedCaddy

8、IP记录 

基于Caddy实现的C2前置代理 - RedCaddy

9、白名单模式并不是万能的,如果你需要套CDN的话,那就没得办法了,因为来源ip都是随机的

0x03 封装

1、要封装成一键生成Caddy配置文件的脚本,首先用到的是来自RedWarden的CobaltStrike Malleable Parser,用来读取CS Profile,获取http-stager / get /post (默认),但是我自己用的profile还合并了 http-get / post (geacon),应对这种复杂的profile,只有RedWarden的parser写得很好 

基于Caddy实现的C2前置代理 - RedCaddy

2、指定转发链文件,流量从哪进来,转发到哪,如下图所示,流量从443进来,转发到192.168.128.64:10001(c2 backend,默认的话一般写你 ifconfig看到的ip),同时关键字warden表示该端口同时用作Teamserver端口保护的开关(反向代理),50050表示你的teamserver端口 

基于Caddy实现的C2前置代理 - RedCaddy

白名单模式下的转发链,https后面直接接入关键字warden不接IP,表示这个端口将会是作为Teamserver + beacon上线的白名单开关 

基于Caddy实现的C2前置代理 - RedCaddy

3、封装脚本如下(vps ip填写你真实的vps ip)

黑名单模式(默认)(适用来钓鱼之类的冲锋动作) 

基于Caddy实现的C2前置代理 - RedCaddy

白名单模式 

基于Caddy实现的C2前置代理 - RedCaddy

同时会在当前目录生成teamserver-guard文件夹,放在协作平台给队友就好了 

基于Caddy实现的C2前置代理 - RedCaddy

4、生成的caddyfile在core目录下即可看到了,还有假证书也在core目录下 

基于Caddy实现的C2前置代理 - RedCaddy

0x05 演示

1、生成假证书,复制store和pass文件到cs目录 

基于Caddy实现的C2前置代理 - RedCaddy

2、获取本地ip,并且配置转发链(这边演示用的是白名单模式) 

基于Caddy实现的C2前置代理 - RedCaddy

3、生成配置文件,指定好vps真实的外部IP,还有dingtalk的bot token 

基于Caddy实现的C2前置代理 - RedCaddy

4、运行 

基于Caddy实现的C2前置代理 - RedCaddy

5、去到cs,修改profile里面的store文件密码,还有teamserver脚本

pass.txt 获取 keystore密码 

基于Caddy实现的C2前置代理 - RedCaddy

修改profile 

基于Caddy实现的C2前置代理 - RedCaddy

修改teamserver 端口和keystore的密码 

基于Caddy实现的C2前置代理 - RedCaddy

6、启动CS 

基于Caddy实现的C2前置代理 - RedCaddy

7、没触发teamserver添加白名单前 

基于Caddy实现的C2前置代理 - RedCaddy

8、触发后 

基于Caddy实现的C2前置代理 - RedCaddy

9、cs配置 

基于Caddy实现的C2前置代理 - RedCaddy

10、白名单模式下,你需要手动查看 caddyfile获取到白名单敲门的信息 

基于Caddy实现的C2前置代理 - RedCaddy

request-go.exe 

基于Caddy实现的C2前置代理 - RedCaddy

基于Caddy实现的C2前置代理 - RedCaddy

11、没触发白名单请求之前 

基于Caddy实现的C2前置代理 - RedCaddy

12、触发 

基于Caddy实现的C2前置代理 - RedCaddy

13、Linux同理,如图,1443使用的是geacon的profile,用来给geacon上线用 

基于Caddy实现的C2前置代理 - RedCaddy

基于Caddy实现的C2前置代理 - RedCaddy

基于Caddy实现的C2前置代理 - RedCaddy

0x04 Outro

  • • 项目链接:https://github.com/XiaoliChan/RedCaddy 希望有看完的大哥觉得还不错的话可以给小弟我点个star

  • • 目前白名单模式只支持DingTalk机器人提醒,后续的话也许会添加TG Bot

  • • 基本上,如果你有一个调好的Profile,配置一个CS(单IP),也挺快的,5到6分钟左右就搞定了,IP黑了就立马换,也懒得去想那么多

  • • 黑名单模式(默认)下,本人还没有测过合法域名 + 证书上线,有需要的可以自行测一测


原文始发于微信公众号(Gcow安全团队):基于Caddy实现的C2前置代理 – RedCaddy

版权声明:admin 发表于 2023年5月15日 下午8:29。
转载请注明:基于Caddy实现的C2前置代理 – RedCaddy | CTF导航

相关文章

暂无评论

您必须登录才能参与评论!
立即登录
暂无评论...