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算法 我们可以写一个搅屎脚本。就像这样：