KONNI是一種遠(yuǎn)程訪(fǎng)問(wèn)木馬，至少在8年前就被發(fā)現(xiàn)了。使用這款?lèi)阂廛浖某r威脅者已經(jīng)在金蘇基的保護(hù)傘下被確認(rèn)。這個(gè)組織一直試圖發(fā)起攻擊，主要目標(biāo)是俄羅斯和韓國(guó)的政治機(jī)構(gòu)。
近日，研究人員發(fā)現(xiàn)朝鮮APT組織Konni的攻擊活動(dòng)，該組織向俄羅斯大使館外交官發(fā)送以新年問(wèn)候?yàn)橹黝}的電子郵件，以進(jìn)行情報(bào)收集活動(dòng)。在本次攻擊活動(dòng)中，最終的植入程序被稱(chēng)為Konni RAT，其代碼和行為與其以前的版本相似。攻擊中所使用的攻擊鏈與該組織的TTP重疊，包括使用CAB文件作為感染階段以及使用bat文件自動(dòng)安裝Konni RAT并設(shè)為服務(wù)。
攻擊鏈
攻擊通常開(kāi)始于惡意Office文檔地利用，當(dāng)這個(gè)文檔被受害者打開(kāi)時(shí)，一個(gè)多階段攻擊就開(kāi)始了，涉及多個(gè)步驟。但這些步驟只是攻擊者設(shè)法完成提升權(quán)限、逃避檢測(cè)和部署所需文件任務(wù)的方式。正如我們?cè)谥暗囊黄恼轮兴枋龅?，攻擊鏈可以用下圖來(lái)概括：
簡(jiǎn)化后的攻擊鏈
可以看到攻擊是從利用惡意Office文檔開(kāi)始的。當(dāng)這個(gè)文檔被受害者打開(kāi)時(shí)，一個(gè)多階段攻擊就開(kāi)始了，包括各個(gè)步驟。但這些步驟只是攻擊者設(shè)法完成提升權(quán)限、逃避檢測(cè)和部署所需文件任務(wù)的方式。
攻擊的最終目標(biāo)是安裝所謂的“KONNI Rat”，這是一個(gè)由.ini文件支持的.dll文件。簡(jiǎn)而言之，.dll文件包含RAT的功能，.ini文件包含第一個(gè)C&C服務(wù)器的地址。KONNI Rat的一般行為與以前的版本幾乎相同，但我們將在下面介紹一些變化。
不再支持Rundll
在之前的KONNI Rat示例中，有兩個(gè)途徑。一個(gè)處理惡意軟件是否通過(guò)Windows服務(wù)啟動(dòng)，另一個(gè)通過(guò)rundll處理執(zhí)行。下圖顯示了這兩個(gè)過(guò)去的途徑，svchost.exe和rundll32.exe字符串可見(jiàn)：
顯示svchost.exe和rundll32.exe字符串的老式主函數(shù)
但是，新示例不會(huì)顯示這些字符串。實(shí)際上，rundll不再是執(zhí)行示例的有效方式。相反，當(dāng)使用rundll發(fā)生執(zhí)行嘗試時(shí)，會(huì)在早期階段引發(fā)異常。
rundll執(zhí)行產(chǎn)生的異常
在我們分析的早期階段，我們認(rèn)為他們正在使用經(jīng)典的進(jìn)程名稱(chēng)檢查或任何其他常用技術(shù)?，F(xiàn)實(shí)要簡(jiǎn)單得多。實(shí)際的導(dǎo)出只是實(shí)現(xiàn)了SvcMain原型，因此程序在訪(fǎng)問(wèn)其中一個(gè)參數(shù)時(shí)會(huì)在某個(gè)時(shí)候中斷。
在上圖中，我們看到了出現(xiàn)此異常時(shí)設(shè)備的狀態(tài)。此時(shí)的RDI應(yīng)包含指向一個(gè)服務(wù)名稱(chēng)的指針。發(fā)生異常是因?yàn)镾ervice Main函數(shù)滿(mǎn)足一個(gè)原型，而rundll32將期望另一個(gè)不同的原型：
VOID WINAPI SvcMain(DWORD dwArgc,LPTSTR*lpszArgv)
VOID WINAPI runnableExport(HWND hwnd,HINSTANCE hinst,LPSTR lpszCmdLine,int nCmdShow)
基本上，在執(zhí)行過(guò)程中，hinst將被視為lspzArgv，從而導(dǎo)致異常。但為什么攻擊者要?jiǎng)h除該功能呢？有多種好處。
首先，我們還沒(méi)有看到任何最近使用rundll的攻擊。事實(shí)上，在最近的攻擊活動(dòng)中，攻擊者發(fā)起KONNI Rat的唯一方式就是注冊(cè)一個(gè)Windows服務(wù)。因此，在真實(shí)世界的攻擊中并沒(méi)有使用rundll32分支。
但沙盒無(wú)法收集示例的真實(shí)行為還有另一個(gè)重要原因，因?yàn)樗鼰o(wú)法以這種方式執(zhí)行。
字符串現(xiàn)在使用AES保護(hù)
多個(gè)惡意軟件家族保護(hù)他們的字符串，目的就是為了防止字符串分析。KONNI也不例外，他也使用了這種技術(shù)。老式示例使用base64進(jìn)行模糊處理處理。而且，他們使用的是自定義字母表。為了使解碼任務(wù)更加困難，這個(gè)習(xí)慣字母表不時(shí)地發(fā)生變化：
舊的Konni示例包括他們自定義的base64字母，后面跟著模糊處理的字符串
現(xiàn)在，攻擊者在這方面做了一個(gè)重大的改變，使用AES加密來(lái)保護(hù)字符串。新的Konni RAT示例所遵循的算法可以表示如下：
新的KONNI示例現(xiàn)在使用AES加密來(lái)保護(hù)字符串
這一變化背后的原因是顯而易見(jiàn)的。由于用于解密的密鑰是服務(wù)名，不同服務(wù)名運(yùn)行的示例將無(wú)法正常工作。此外，在不知道服務(wù)名稱(chēng)的情況下僅擁有示例變得毫無(wú)用處，因?yàn)檫@些字符串包含有關(guān)示例行為的核心信息。
文件也使用AES進(jìn)行保護(hù)
KONNI Rat在執(zhí)行時(shí)會(huì)使用各種支持文件，其中一個(gè)文件是.ini文件，其中包含主要的C&C服務(wù)器，但還有其他文件，例如應(yīng)該最終刪除的.dat文件，以及用于發(fā)送有關(guān)計(jì)算機(jī)的一些基本信息的臨時(shí)文件。
調(diào)查顯示，所有這些文件都使用AES進(jìn)行了刪除和保護(hù)。巧妙的地方在于，他們重用了用于字符串保護(hù)的算法，使文件布局與受保護(hù)的字符串布局相同，因?yàn)樗鼈兂霈F(xiàn)在原始內(nèi)存中：
新的KONNI示例現(xiàn)在也使用AES加密來(lái)保護(hù)文件
從圖中可以看出，文件本身包含了IV和加密的數(shù)據(jù)。使用的密鑰是從其原始文件名中提取的。在某些情況下，名稱(chēng)與服務(wù)名稱(chēng)匹配，因此.ini和.dat文件中使用的密鑰也是對(duì)服務(wù)名稱(chēng)應(yīng)用SHA256的結(jié)果。
此外，發(fā)送到C&C服務(wù)器的文件使用AES進(jìn)行保護(hù)。IV是使用QueryPerformanceCounter API CALL生成的。文件名由表示數(shù)據(jù)的2個(gè)字母和當(dāng)前時(shí)間戳連接而成，后面跟著擴(kuò)展名。此外，他們將使用這個(gè)新生成的名稱(chēng)作為AES密鑰，因此他們通過(guò)請(qǐng)求將這個(gè)名稱(chēng)發(fā)送到C&C服務(wù)器。
即將發(fā)送到服務(wù)器的請(qǐng)求片段
由于文件名是使用時(shí)間戳自動(dòng)生成的，因此相同的文件將產(chǎn)生不同的請(qǐng)求內(nèi)容，因?yàn)樗鼈兪鞘褂迷撐募用艿?。因此，網(wǎng)絡(luò)簽名也可能無(wú)法檢測(cè)到此惡意活動(dòng)。
其他模糊處理技術(shù)
除了發(fā)現(xiàn)一些僅通過(guò)我們之前描述的方式受到保護(hù)的示例，我們還發(fā)現(xiàn)了其他使用身份不明的封裝程序的示例。我們想分享一些關(guān)于該封裝程序的注釋?zhuān)驗(yàn)槠渌丝赡軙?huì)發(fā)現(xiàn)它在識(shí)別和歸因任務(wù)中很有用。
指令連續(xù)模糊處理
模糊處理程序的流程將使用一系列推送調(diào)用指令對(duì)，其中推送的值將指示程序?qū)⒉扇〉男袆?dòng)。下圖可以更好地解釋其過(guò)程：
推送調(diào)用指令對(duì)
特別值得注意的是，攻擊者在這些對(duì)之間放置了隨機(jī)字節(jié)。這個(gè)愚蠢的技巧會(huì)導(dǎo)致反編譯程序錯(cuò)誤的代碼解釋?zhuān)@些反編譯程序會(huì)假定push指令之后的字節(jié)是下一條指令的一部分。下圖顯示了IDA無(wú)法分析代碼的原因：
與前面的代碼相同，顯示了IDA為何不能表示真正的代碼
模糊處理程序流程
使用的封裝程序會(huì)模糊處理原始程序流程。這是通過(guò)不同的步驟中完成的。第一個(gè)需要的步驟是找到Image Base值，放置在一個(gè)固定位置和RIP（指令指針）值。
EBX將保存RIP值
一旦封裝程序知道這兩個(gè)值，它就會(huì)開(kāi)始從一個(gè)地方跳到另一個(gè)地方，使分析變得更加困難。為此，它將存儲(chǔ)在下一個(gè)地址的某個(gè)寄存器值中以跳轉(zhuǎn)到寄存器中。這些寄存器的值是在jmp指令之后立即計(jì)算的，使用像POP[reg]-jmp[reg]或ADD[reg1,reg2]-jmp[reg1]這樣的結(jié)構(gòu)。請(qǐng)注意，反編譯程序?qū)o(wú)法顯示實(shí)際流程，因?yàn)樘D(zhuǎn)地址是由一個(gè)未定義的寄存器確定的。
顯示最終jmp變?yōu)镽BX的模糊處理代碼
這些簡(jiǎn)單技術(shù)的組合使封裝程序現(xiàn)在處于流的控制中，但靜態(tài)反編譯程序無(wú)法表示代碼將遵循的路徑。最后，封裝程序會(huì)執(zhí)行大量的垃圾指令，并最終執(zhí)行真正有趣的代碼。例如，在IAT構(gòu)建任務(wù)中，原始代碼在GetProcAddress調(diào)用之間將使用不超過(guò)20條指令。但封裝后的代碼可執(zhí)行超過(guò)30000條指令。
但根據(jù)最近的追蹤分析，最近的攻擊不再使用該封裝程序。
總結(jié)
如上所述，KONNI Rat每隔一段時(shí)間就會(huì)更新迭代一次。開(kāi)發(fā)者會(huì)不斷改進(jìn)代碼。在我們看來(lái)，他們的努力旨在打破沙盒規(guī)則，使檢測(cè)更加困難，特別是通過(guò)常規(guī)簽名，因?yàn)榭蓤?zhí)行文件的關(guān)鍵部分現(xiàn)在已加密。
本文翻譯自：https://blog.malwarebytes.com/threat-intelligence/2022/01/konni-evolves-into-stealthier-rat/
