CobaltStrike-DNS隧道设计缺陷 – 作者:yumusb

image相信看到这篇文章的同学已经不需要我去介绍什么是”CobaltStrike”,本文将介绍其DNS隧道交互流程与中间的一些缺陷。(本文所用版本为4.3,在DNS隧道交互中有一些前缀可以根据profile自定义,但是缺陷部分与之前的版本并无差异)

交互流程

主要逻辑在 \beacon\BeaconDNS中的DNSServer.Response respond_nosync方法。该方法主要传入了两个参数:
image.png参数1 为解析的子域名,参数2为解析的类型(CNAME、A等)。
首先判断了解析类型是否为2(NS,这部分可以参考RFC文档 https://datatracker.ietf.org/doc/html/rfc1035#section-3.2.2),此处为4.3版本中的特性,可以用来防止主动探测。

stage分发阶段

接下来进入重要的stage分发阶段:
image.png此处的主要判断了子域名是否以 (“长度为3的字符串”+”stage”)或者(“长度为3的字符串”+”指定的stager_subhost”)开头
stager_subhost变量是从profile配置文件中获取的”.dns-beacon.dns_stager_subhost”字段,该字段可以自主配置。如果符合,则进入stage分发流程。就像这样:image.png此处“mail”就是攻击者自定义的dns_stager_subhost。
image.png未作自定义配置的,默认为”stage”。
此处特征:固定的域名前缀,查询记录为txt,且返回字段有特征可循。
image.png虽然stage的具体值允许自定义的前缀,且经过了编码。但是txt记录的返回字段长度固定为255(除去最后一个不满255),传输过程中会有大量的返回255长度的txt解析。
image.png

上线阶段

stage分发完毕以后(或者直接使用了stageless模式),来到了我们的上线阶段。
image.png上来就是对前缀的一通判断,这些我们后面再说。
重点是此处beacon id的获取阶段。我们重点关注
CommonUtils.isHexNumber(var6)&&CommonUtils.isDNSBeacon(var6)
image.png通过此逻辑,可以获取到beacon id,一个ID对应CS界面中的一台机器。所以此处是CobaltStrike隧道中必定存在的一环。而isDNSBeacon方法,我们也可以当作判定CobaltStrikeDNS隧道的重要依据。
image.png判定测试
image.png

数据传输阶段

也就是我们刚看到的一通判断:
image.png此处逻辑4.3版本与之前的略有不同。4.3以后新增加了从profile中取值的部分,而之前的版本为固定的cdn.、www6.、api.、www.、post.
这些字段为传输阶段的固定前缀。就像这样:
image.png

可以用来做什么?

检测

可以依据这些固定的特征完善检测规则。本人做了一个简单的demo,欢迎测试 https://detectcs.xn--9tr.com/

抹去特征

当然,红方队员也可以根据这些特征去抹除,不过固定的isDNSBeacon算法,需要对底层进行修改才能保证上线正常,想要改掉对逆向水平要求较高。

搅屎

根据isDNSBeacon算法,我们可以写一个搅屎脚本。就像这样:
image

来源:freebuf.com 2021-07-06 21:46:17 by: yumusb

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论