CobaltStrike-DNS隧道设计缺陷

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

交互流程

主要逻辑在 \beacon\BeaconDNS中的DNSServer.Response respond_nosync方法。该方法主要传入了两个参数：

参数1 为解析的子域名，参数2为解析的类型（CNAME、A等）。 首先判断了解析类型是否为2（NS，这部分可以参考RFC文档 https://datatracker.ietf.org/doc/html/rfc1035#section-3.2.2），此处为4.3版本中的特性，可以用来防止主动探测。

stage分发阶段

接下来进入重要的stage分发阶段：

此处的主要判断了子域名是否以 (“长度为3的字符串”+”stage”)或者(“长度为3的字符串”+”指定的stager_subhost”)开头 stager_subhost变量是从profile配置文件中获取的”.dns-beacon.dns_stager_subhost”字段，该字段可以自主配置。如果符合，则进入stage分发流程。就像这样：

此处“mail”就是攻击者自定义的dns_stager_subhost。

未作自定义配置的，默认为”stage”。 此处特征：固定的域名前缀，查询记录为txt，且返回字段有特征可循。

虽然stage的具体值允许自定义的前缀，且经过了编码。但是txt记录的返回字段长度固定为255（除去最后一个不满255），传输过程中会有大量的返回255长度的txt解析。

上线阶段

stage分发完毕以后（或者直接使用了stageless模式），来到了我们的上线阶段。

上来就是对前缀的一通判断，这些我们后面再说。 重点是此处beacon id的获取阶段。我们重点关注 CommonUtils.isHexNumber(var6)&&CommonUtils.isDNSBeacon(var6)

通过此逻辑，可以获取到beacon id，一个ID对应CS界面中的一台机器。所以此处是CobaltStrike隧道中必定存在的一环。而isDNSBeacon方法，我们也可以当作判定CobaltStrikeDNS隧道的重要依据。

判定测试：

数据传输阶段

也就是我们刚看到的一通判断：

此处逻辑4.3版本与之前的略有不同。4.3以后新增加了从profile中取值的部分，而之前的版本为固定的cdn.、www6.、api.、www.、post. 这些字段为传输阶段的固定前缀。就像这样：

可以用来做什么？

检测

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

抹去特征

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

搅屎

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

精彩推荐