無文件Powershell惡意程序使用DNS作為隱蔽信道

思科Talos安全團隊最近發現一款Powershell惡意程序，用DNS進行雙向通信。

前言

DNS是企業網路中最常用的Internet應用層協議。DNS提供域名解析，這樣用戶就可以通過域名而非IP地址來訪問網路資源。許多企業會嚴格監控web流量，但對基於DNS的威脅的防護就比較少。攻擊者也注意到了這點，經常將其他協議封裝進DNS協議中來躲避安全監測。

攻擊者利用DNS協議一般都是要獲取信息。思科Talos團隊最近分析了一個很有趣的惡意程序樣本，利用DNS TXT記錄查詢和響應來創建雙向的C2通道。攻擊者可以通過DNS通信來向感染設備提交命令，並將命令執行結果返回給攻擊者。

這在遠程訪問工具中相當罕見，而且隱蔽性較高。此惡意程序中使用了多階段Powershell腳本，其中許多階段都是完全無文件的，這就說明攻擊者為了避開檢測也是很努力的。

諷刺的是，這款惡意程序的作者在代碼中高調叫板SourceFire，於是就被思科的Talos團隊揪出來了。

正傳

說起來，這個故事緣起於一條推特。

推特用戶@Simpo13在2月24號發布了一則推文，文中提到他正在分析的一段Powershell惡意腳本，其中包含一段base64編碼的字元串「SourceFireSux」（SourceFire sucks的諧音，意為SourceFire爛暴了）。

Simpo的推特圖片

SourceFire正是思科於2013年用27億美元收購的。因此「SourceFireSux」的字眼引起了思科威脅情報團隊Talos的注意，而Talos團隊中也剛好有SourceFire漏洞研究團隊的原班人馬，於是他們決定深挖這段惡意腳本。

他們搜索了推文中提到的base64編碼值「UwBvAHUAcgBjAGUARgBpAHIAZQBTAHUAeAA=」，發現在公共惡意程序分析沙盒Hybrid Analysis中有一個樣本。

另外，他們在對編碼字元串搜索的過程中還定位到了一條Pastebin條目，其中列出了一寫哈希，根據這些，他們找到了一個公共沙盒中的一個惡意Word文件，由此揭開了一個名為「DNSMessenger」 的多階段感染過程。

在這個特殊案例中，團隊先分析了那段被當作VBScript文件提交到公共沙盒中的Powershell文件，他們將之稱為為「第三階段」。他們發現，前面提到的「SourceFireSux」字元串被用作互斥量，如圖1所示。

第一階段惡意Word文檔

前面提到Talos團隊找到了感染鏈的源頭，也就是那個惡意Word文檔。這個文檔是通過釣魚郵件傳播的。有趣的是，這個Word文檔會偽裝成被McAfee保護的「受保護文件」。

因為McAfee的名氣，受害者打開文件並啟用宏的概率也就有所提升。打開後，該文檔便誘使用戶啟用內容。

文檔用Document_Open()調用另一個VBA函數。這個VBA函數就會設置一個長字元串，其中包含一個Powershell命令和將執行的代碼。然後調用Windows管理界面（WMI）的Win32_Process對象的Create方法，執行上述命令。

通過命令行傳遞給Powershell的代碼基本上是base64編碼的，並用gzip壓縮的，只有尾部一小部分沒有編碼。

沒有編碼的這段會被用於解壓縮該代碼，並傳遞給Invoke-Expression Powershell cmdlet（IEX）執行。通過這一步驟，代碼不需要被寫入受感染設備的文件系統，就可以執行。

團隊還發現防病毒軟體對這個樣本的檢測率比較低，為6/54，其中ClamAV能夠成功檢測這個樣本。

第二階段Powershell

第一階段中的IEX執行Powershell腳本後，Talos團隊開始觀察到感染設備上出現了一寫比較有趣的活動。第一階段中描述的Powershell腳本末端有一個函數，定義了第二階段的指令和三階的相關特性。

第二階段中的代碼經過了混淆處理，團隊將這個階段中用到的主函數稱為「pre_logic」，將第三階段中的函數稱為「logic」。

「pre_logic」函數支持兩個switch參數。第一個用於決定在下一個感染步驟中是否要實現持久性。如果選擇實現持久性，第二個switch就會決定第三階段代碼要不要執行。

除了兩個switch外，「pre_logic」函數還支持四個參數，這四個參數隨後將傳遞給下一階段的「logic」函數。這些參數決定，下一個感染階段發送DNS TXT記錄查詢時，要使用哪些子域。

隨後，「pre_logic」函數會解壓第三階段中用到的Powershell腳本，就是包含在該腳本當中的一個base64編碼的blob。該函數還會定義後續階段將用到的一些代碼，包括函數調用和參數。

如果 「pre_logic」函數被調用時，選擇了實現持久性，函數將會查詢感染系統，決定如何最好地實現持久性。根據惡意程序運行時使用的用戶賬戶相應的訪問許可權，惡意程序將查詢惡意程序實現持久性最常用的註冊路徑。

如果使用的是管理員許可權賬戶，那麼腳本會查詢並設置：

$reg_win_path: 「HKLM:SoftwareMicrosoftWindowsCurrentVersion」

$reg_run_path: 「HKLM:SoftwareMicrosoftWindowsCurrentVersionRun」

如果使用的是一般用戶帳戶，腳本則會查詢並設置：

$reg_win_path: 「HKCU:SoftwareMicrosoftWindows」

$reg_run_path: 「HKCU:SoftwareMicrosoftWindowsCurrentVersionRun」

然後根據系統所用的Powershell版本，第三階段payload將寫至不同位置。如果受感染系統用的是Powershell 3.0或者更高版本，第三階段payload將寫至「%PROGRAMDATA%Windows」中的ADS流文件中，並命名為「kernel32.dll」。

如果系統用的是較早的Powershell，第三階段payload將被編碼並寫至$reg_win_path指定的位置，鍵名為「kernel32」。

隨後，用來解壓並執行第三階段payload的代碼也會被寫至$reg_win_path分配的註冊表位置，鍵名為「Part」。

這個步驟完成之後，攻擊腳本會再次檢查並確定用戶訪問許可權。如果是管理員許可權，那麼被感染系統中的「_eventFilter」、「CommandLineEventConsumer」和「_filtertoconsumerbinding」等WMI事件訂閱將會被移除。然後該惡意程序會創建自己的WMI永久事件訂閱，篩選出「Win32_LogonSession」事件，並鎖定「CommandLineEventConsumer」。

受感染系統中每創建一個新的登錄會話，之前儲存在ADS中的第三階段payload就會被讀取並執行。第三階段payload默認在30分鐘後運行「onidle」。如果在這個階段開始時，與其執行相關的switch參數被傳遞至「pre_logic」函數，那麼payload就會立即執行。

如上圖所示，該惡意程序還在系統中創建了一個預定任務，任務名為「kernel32」，該任務關係到第三階段payload儲存於ADS還是註冊表。Talos團隊在分析其他與此攻擊有關的樣本發現，不同樣本當中該預定任務可能會有相應的調整。

第三階段Powershell

第二階段中執行的第三階段Powershell，主要是用一些略顯傻氣的函數名和變數名進行混淆的（比如${script:/==///==\__/==}，而不是$domains）。整個腳本從頭到尾也都是base64編碼的。

Talos團隊反混淆之後發現，腳本中包含許多硬編碼域名，然後將隨機選出其中一個，用於後續的DNS查詢。有點必須要注意的是，第三、四階段的Powershell腳本，都包含兩組域，只有在樣本使用第二組域名出現問題時才會使用第一組域名。

第三階段Powershell腳本中的「Logic」函數會從腳本中的第二組域中隨機選擇一個C2域，並用這個域進行初始查找。如果這個初始DNS TXT記錄請求的返回值為空，或者說查找失敗，那麼將調用「do_lookup」函數，並從第一組域中隨即選取一個域。

第三階段腳本還會使用一些特定的子域，與初始DNS TXT記錄查詢中使用的域相結合。惡意程序用響應的TXT記錄內容，來決定下一步動作。

比如說，第一個子域為「www」，並且TXT記錄查詢響應結果包含「www」，就會指示腳本繼續。其他指令則會被認為「空」或者「停止」。

惡意程序收到初始DNS響應後，就會迭代至下一個子域，即「mail」。惡意程序會在另一個DNS TXT記錄查詢中使用這個域，來嘗試獲取與當前階段相關的第四階段payload。

這個DNS請求得到響應後，將獲取第四階段payload，儲存在TXT記錄中，如圖10和圖11所示。因為第四階段payload比較大，這次傳輸過程用了TCP。

下圖是Wireshark對上述payload的分析

與第四階段相關的代碼隨後會被清理並傳遞至Invoke-Expression Powershell cmdlet （IEX），並在第三階段的語境中執行。

第四階段payload並不能自主執行，如果僅嘗試執行第四段payload，就會失敗，因為第四段payload依賴於第三段Powershell腳本中的解碼函數。

這個函數還有其他幾個功能。這個函數會用DNS查詢響應結果中獲得的代碼，定義一個包含該代碼的字元串變數。然後，第三階段中的解碼函數會被調用，並將解碼的字元串傳遞給IEX，來擴展Powershell環境。

這一步完成後，將調用新擴展環境中的一個函數，來執行第四階段代碼，並設置特定參數。這些參數包含後續將用到的第四階段C2域名和將執行的程序，即Windows命令行處理器（cmd.exe）。

這一步相當有意思，因為這樣，第四階段payload其實是從未被真正寫至感染系統的文件系統中。

第四階段Powershell

如前文所述，四階Powershell payload是由三階中的「dec」函數解碼。第四階段payload尾部調用了其中的「cotte」函數，該函數提供了其他一些參數，包括將用到的C2域和將執行的程序（cmd.exe）。

當執行cmd.exe時，函數會將STDIN、STDOUT和STDERR重定向，允許payload在命令行處理器中讀寫。

提供給這個函數調用的域將用來生成DNS查詢，用於主要的C2操作。與前面的腳本一致，第四階段payload當中也有兩組硬編碼域，但貌似只會用到第二組。

主C2伺服器每發回301個DNS響應，樣本就會單獨發送一個DNS TXT解析請求到前面提到的第二組中隨機選擇的域。

這個C2請求會決定此惡意程序應不應該在受感染系統上繼續運行。跟前面步驟當中類似，這個請求也是發送給次級C2域中的「web」子域的。

如果次級C2伺服器返回包含字元串「stop」的TXT記錄，此惡意程序就會停止活動。

受感染系統向主C2伺服器發送「SYN」消息，建立主C2通道。

這一步完成後，先前從Windows命令行處理器中捕獲到的STDOUT和STDERR輸出會通過「MSG」消息發出。

藉此，攻擊者發送的命令能夠被命令處理器直接執行，攻擊者全靠DNS TXT請求和響應就能接收命令的輸出結果。下文將詳細描述此通信過程。

將DNS查詢請求解碼，我們就能看到發送給C2伺服器的是命令行處理器的輸出結果。

攻擊者就這樣建立了一個互動的C2信道，來執行系統命令，並獲取命令的輸出結果。

C2通信

惡意Word文檔中與此感染鏈相關的C2域註冊於2017年2月8日。與Hybrid Analysis中的Powershell樣本相關的域註冊於2017年2月18日。其中許多域註冊時使用的郵箱地址如下：

valeriy[.]pagosyan[@]yandex[.]com

其他域時通過NameCheap代理註冊服務註冊的。

根據Umbrella的分析，與Powershell樣本使用的域有關的大部分DNS活動集中出現於2017年2月22日至2月25日。Word文檔使用的域則少有活動，其少量的活動集中於2月11日。

此惡意程序中的所有C2通信都是通過DNS TXT查詢和響應完成的。要有互動的「MSG」查詢，就必須要建立C2信道，而C2信道建立的先決條件是「SYN」查詢。這些消息是由以下元素組成的：

$session_id – 感染設備產生的四位數字，這個數字一直保持不變，而且所有的後續DNS查詢和響應中都包含了這個數字。

$sequence_num – 感染設備產生的四位數字，在C2通信過程中定期變化，變化後的新值會被添加至下一個查詢中。

$acknowledgement_num – 「SYN」消息響應中產生的四位數字，值似乎不會變化，而且必須包括在所有後續的「MSG」查詢中。

DNS查詢和響應中的第5和第6個位元組決定了消息類型，可能是以下值中的任意一個：

00 – 『SYN』 message

01 – 『MSG』 message

02 – 『FIN』 message

其中，用於發送執行命令和返回命令輸出的「MSG」查詢是十六進位編碼的，每30個位元組用點分隔。

下圖就是整個C2通信的過程。注意在通信過程中，可能有許多個「MSG」查詢和響應，這取決於攻擊者想要在感染設備上執行的命令。

下圖展示了不同的消息及其響應是如何形成的。

結論

從本文的例子中，我們可以看出，攻擊者為了躲避檢測，可以做到這種地步。

本文的例子還說明，除了需要監測和過濾HTTP/HTTPS、SMTP/POC3等網路協議，DNS協議也應該得到應有的重視。

企業網路中的DNS流量可以被攻擊者利用，來建立雙向的C2通信通道，而DNS監控和過濾類產品可有效攔截此類攻擊。

IoC

哈希：

f9e54609f1f4136da71dbab8f57c2e68e84bcdc32a58cc12ad5f86334ac0eacf (SHA256)

f82baa39ba44d9b356eb5d904917ad36446083f29dced8c5b34454955da89174 (SHA256)

340795d1f2c2bdab1f2382188a7b5c838e0a79d3f059d2db9eb274b0205f6981 (SHA256)

7f0a314f15a6f20ca6dced545fbc9ef8c1634f9ff8eb736deab73e46ae131458 (SHA256)

be5f4bfa35fc1b350d38d8ddc8e88d2dd357b84f254318b1f3b07160c3900750 (SHA256)

9b955d9d7f62d405da9cf05425c9b6dd3738ce09160c8a75d396a6de229d9dd7 (SHA256)

fd6e7fc11a325c498d73cf683ecbe90ddbf0e1ae1d540b811012bd6980eed882 (SHA256)

6bf9d311ed16e059f9538b4c24c836cf421cf5c0c1f756fdfdeb9e1792ada8ba (SHA256)

C2域

algew[.]me

aloqd[.]pw

bpee[.]pw

bvyv[.]club

bwuk[.]club

cgqy[.]us

cihr[.]site

ckwl[.]pw

cnmah[.]pw

coec[.]club

cuuo[.]us

daskd[.]me

dbxa[.]pw

dlex[.]pw

doof[.]pw

dtxf[.]pw

dvso[.]pw

dyiud[.]com

eady[.]club

enuv[.]club

eter[.]pw

fbjz[.]pw

fhyi[.]club

futh[.]pw

gjcu[.]pw

gjuc[.]pw

gnoa[.]pw

grij[.]us

gxhp[.]top

hvzr[.]info

idjb[.]us

ihrs[.]pw

jimw[.]club

jomp[.]site

jxhv[.]site

kjke[.]pw

kshv[.]site

kwoe[.]us

ldzp[.]pw

lhlv[.]club

lnoy[.]site

lvrm[.]pw

lvxf[.]pw

mewt[.]us

mfka[.]pw

mjet[.]pw

mjut[.]pw

mvze[.]pw

mxfg[.]pw

nroq[.]pw

nwrr[.]pw

nxpu[.]site

oaax[.]site

odwf[.]pw

odyr[.]us

okiq[.]pw

oknz[.]club

ooep[.]pw

ooyh[.]us

otzd[.]pw

oxrp[.]info

oyaw[.]club

pafk[.]us

palj[.]us

pbbk[.]us

ppdx[.]pw

pvze[.]club

qefg[.]info

qlpa[.]club

qznm[.]pw

reld[.]info

rnkj[.]pw

rzzc[.]pw

sgvt[.]pw

soru[.]pw

swio[.]pw

tijm[.]pw

tsrs[.]pw

turp[.]pw

ueox[.]club

ufyb[.]club

utca[.]site

vdfe[.]site

vjro[.]club

vkpo[.]us

vpua[.]pw

vqba[.]info

vwcq[.]us

vxqt[.]us

vxwy[.]pw

wfsv[.]us

wqiy[.]info

wvzu[.]pw

xhqd[.]pw

yamd[.]pw

yedq[.]pw

yqox[.]pw

ysxy[.]pw

zcnt[.]pw

zdqp[.]pw

zjav[.]us

zjvz[.]pw

zmyo[.]club

zody[.]pw

zugh[.]us

cspg[.]pw

*參考來源：

talosintelligence

，本文作者：白熊，轉載請註明來自FreeBuf

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！