0x00 场景

接触CS也不久，之前只用过最基本的一些功能，但近期的比赛中越来越频繁的遇到拿了Webshell但发现不出网的机器，所以被迫用上了DNS Beacon。

0x01 踩坑

网上的同人文基本上都是这样配置：

看起来挺有道理，但跟着走，走着走着发现掉坑了。
这样配置的话，上线确实可以，但成功上线的是下图中这种类型的beacon(stageless)，文章中却对其没有任何解释，也没有描述不同beacon的原理（其实官方英文文档和视频也在含糊其辞）：

或者同种PS版本的：

这种beacon的特点是payload体积庞大，生成的RAW Payload也是一个完整Shellcode Loader的PE文件（约200KB）而不是一段shellcode（不足1KB），虽然经测试也可以将其整体编码后做免杀，但总觉得别扭且麻烦。而且，在内存中解密出一个完整的PE文件这种行为也会被特别关照吧。

0x02 Beacon

那么上面看到的两种beacon有什么区别呢？查阅官方说明，翻译并归纳总结如下。
CS的马有两大类：一种是和灰鸽子类似的马，本身是带有完整功能的二进制程序；另一种马短小精悍，也是平时自己diy免杀马常用的，分为三个部分——攻击载荷（payload）、传输器（stager）和传输体（stage），传输器通过下载传输体将其拼接成真正可以回连teamserver的马子（payload），从而达到比较出色的伪装效果。
上面图中的那类stageless，顾名思义就是没有stager和stage的马，而是直接以payload为模版生成一个完整的二进制马，当然特征也是最明显的。
而DNS Beacon本质上与HTTP/HTTPS无异，只是将数据封装进了不同的协议而已。这里借用官网的原图说明下DNS Beacon的工作原理：

从上图中可以看到，当我们给CS的teamserver搞了一个域名并配置相应的A记录以及指向自身A记录的NS记录后，DNS请求就会被迭代查询的本地DNS服务器一步一步引向teamserver，teamserver收到了服务端的特殊请求后便可以用封装的加密通信协议与之交互了。
道理很简单，可为啥用起来就很坑呢？

0x03 CS4和前作的区别

DNS Beacon也是CS4中改动比较大的一个，而网上针对它的中文文章确实还比较少，大多数都是3代的教程（好好学英语），而配置还是有挺大区别的。
CS4中的DNS Beacon才是真正纯粹的DNS隧道，前作中大家常用的方式都是以http的形式传递stage，但这种场景并不是我们要用DNS隧道的主要原因，如果你可以走HTTP就证明主机可以联网，干嘛放着大路不走，非要走不太稳定的DNS呢（有特殊隐蔽需求的除外）？
而现在的DNS Beacon则是仅留下了reverse_dns_txt，所有的stage必须都从DNS隧道中下载，这也是为什么上面的配置中只有stageless的可以回连但碰到需要下载stage的就会失败的原因，因为配置本身就有问题呀。

0x04 配置

多说无益，直接看看官方文档中是怎么配置的吧（相关域名可对照上面的官方文档原理图）：

这里一开始没有仔细看，看到了3个DNS HOSTS就以为和网友帖子配的是一样的，但其实不是。人家真正的A记录并没有写在配置里面，这里面的域名都是NS记录！
其实仔细想想也知道，A记录是用来解析IP地址的，通信用流量封装在了DNS请求中，由上级DNS服务器代发，跟teamserver的IP有毛线关系？
因此在域名解析记录中，配一条A记录指向teamserver的IP，再配1条或多条NS记录用来做隧道，域名指向A记录。就像这样：

在CS中配置HOSTS为刚刚建立的NS记录，配置stager域名为其中的一个NS记录（如果只配了
一个就写一样的）：

然后就可以生成带stager的小马或导出shellcode自己做免杀了。

0x05 流量

坑踩过了，原理和配置都搞清楚了，本着科学严谨的态度再做个实验验证下流量。

stageless

首先生成个stageless的大马并执行。一开始在checkin阶段，会有这样一次DNS请求的交互：

CS中随即出现了一个Ghost Beacon：

这里要注意还有个坑，想让它激活还需要在beacon里面输入checkin命令，不然DNS服务器是不会返回激活指令的。一直不chechin，他就会每过一段时间请求一个新的子域名，返回的“IP”都是0.0.0.0。如下图：

对应的，CS上面也会出现相同数量的ghost（也有可能会少几个）。此时在ghost beacon中输入checkin命令，下一次心跳中，服务端就会返回不一样的“IP”（类似唤醒指令），例如checkin命令对应0.0.0.243、还有mode dns对应0.0.0.241等等。不管是什么指令，只要有效就可以激活后门，开始进行通信：

随后的通信便是一些看不懂的子域名：

子域名中看起来的随机字符串其实就是通过A记录中夹带封装的数据，只不过由于数据量很小，只能少量多次发送接收，因此checkin的过程需要等一段时间，并不会像HTTP/HTTPS那样瞬间上线。
通信过后，beacon便正常上线了（注意，由于DNS数据包的来源是代理查询的DNS服务器并不是被控机器的真实出口IP，因此这里不会显示external的IP地址）：

随后执行一条命令，可以发现同一时间的流量中夹杂了TXT记录：

根据官方文档描述，CS4中有三种数据传输模式，A、AAAA、TXT，默认是TXT，因此这里的A记录只是维持心跳和基本的通信，传输数据默认还是走TXT的。

stager

由于stager需要下载stage组成马子的真正功能体，因此在一开始就需要有一个下载数据的过程。
执行的瞬间会产生大量的TXT请求，其中数据是加密后Base64编码的，无从得知其中的内容（想想也知道里面就是stage）。在这个过程中是没有Ghost Beacon
上线的：

静候800多秒，终于上线了：

之后的通信就没有什么特别的了，只是稳定性依然取决于网络情况，如果服务器在国外的话依旧不太稳定。

0x06 关于BUG

经反复测试，目前网上可以下载的那个破解版是有BUG的，checkin命令无效，teamserver服务端并不会响应传回启动指令。
但根据CS官方手册的描述，执行命令的时候会自动进行checkin，经测试在Ghost beacon出现后输入mode dns，就可以成功checkin。后续如果嫌A记录通信缓慢，可以再用mode dns-txt切换回来。

0x07 关于隐蔽通信

DNS隧道除应对TCP不出网的场景外，其本身的隐蔽通信能力也比较哈好，推荐两个基于DNS做隐蔽通信的工具：
chashell
DNSlivery
此外还有个ICMP隧道的工具，思路也可以借鉴：
icmptunnel
但这款工具并没有对封装的流量做任何加密处理，如果要应用在实战中还需要对代码做一些修改。