.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
KONNI是一種遠程訪問木馬，至少在8年前就被發現了。使用這款惡意軟件的朝鮮威脅者已經在金蘇基的保護傘下被確認。這個組織一直試圖發起攻擊，主要目標是俄羅斯和韓國的政治機構。
近日，研究人員發現朝鮮APT組織Konni的攻擊活動，該組織向俄羅斯大使館外交官發送以新年問候為主題的電子郵件，以進行情報收集活動。在本次攻擊活動中，最終的植入程序被稱為Konni RAT，其代碼和行為與其以前的版本相似。攻擊中所使用的攻擊鏈與該組織的TTP重疊，包括使用CAB 文件作為感染階段以及使用bat 文件自動安裝Konni RAT 並設為服務。
攻擊鏈攻擊通常開始於惡意Office文檔地利用，當這個文檔被受害者打開時，一個多階段攻擊就開始了，涉及多個步驟。但這些步驟只是攻擊者設法完成提升權限、逃避檢測和部署所需文件任務的方式。正如我們在之前的一篇文章中所描述的，攻擊鏈可以用下圖來概括：
簡化後的攻擊鏈
可以看到攻擊是從利用惡意Office文檔開始的。當這個文檔被受害者打開時，一個多階段攻擊就開始了，包括各個步驟。但這些步驟只是攻擊者設法完成提升權限、逃避檢測和部署所需文件任務的方式。
攻擊的最終目標是安裝所謂的“KONNI Rat”，這是一個由.ini 文件支持的.dll 文件。簡而言之，dll 文件包含RAT 的功能，ini 文件包含第一個CC 服務器的地址。 KONNI Rat 的一般行為與以前的版本幾乎相同，但我們將在下面介紹一些變化。
不再支持Rundll在之前的KONNI Rat示例中，有兩個途徑。一個處理惡意軟件是否通過Windows服務啟動，另一個通過rundll處理執行。下圖顯示了這兩個過去的途徑，svchost.exe和rundll32.exe字符串可見：
顯示svchost.exe 和rundll32.exe 字符串的老式主函數
但是，新示例不會顯示這些字符串。實際上，rundll 不再是執行示例的有效方式。相反，當使用rundll 發生執行嘗試時，會在早期階段引發異常。
rundll 執行產生的異常
在我們分析的早期階段，我們認為他們正在使用經典的進程名稱檢查或任何其他常用技術。現實要簡單得多。實際的導出只是實現了SvcMain 原型，因此程序在訪問其中一個參數時會在某個時候中斷。
在上圖中，我們看到了出現此異常時設備的狀態。此時的RDI 應包含指向一個服務名稱的指針。發生異常是因為Service Main 函數滿足一個原型，而rundll32 將期望另一個不同的原型：
VOIDWINAPISvcMain(DWORDdwArgc,LPTSTR*lpszArgv)
VOIDWINAPIrunnableExport(HWNDhwnd,HINSTANCEhinst,LPSTRlpszCmdLine,intnCmdShow)基本上，在執行過程中，hinst 將被視為lspzArgv，從而導致異常。但為什麼攻擊者要刪除該功能呢？有多種好處。
首先，我們還沒有看到任何最近使用rundll的攻擊。事實上，在最近的攻擊活動中，攻擊者發起KONNI Rat的唯一方式就是註冊一個Windows服務。因此，在真實世界的攻擊中並沒有使用rundll32分支。
但沙盒無法收集示例的真實行為還有另一個重要原因，因為它無法以這種方式執行。
字符串現在使用AES保護多個惡意軟件家族保護他們的字符串，目的就是為了防止字符串分析。 KONNI也不例外，他也使用了這種技術。老式示例使用base64進行模糊處理處理。而且，他們使用的是自定義字母表。為了使解碼任務更加困難，這個習慣字母表不時地發生變化：
舊的Konni 示例包括他們自定義的base64 字母，後面跟著模糊處理的字符串
現在，攻擊者在這方面做了一個重大的改變，使用AES加密來保護字符串。新的Konni RAT 示例所遵循的算法可以表示如下：
新的KONNI 示例現在使用AES 加密來保護字符串
這一變化背後的原因是顯而易見的。由於用於解密的密鑰是服務名，不同服務名運行的示例將無法正常工作。此外，在不知道服務名稱的情況下僅擁有示例變得毫無用處，因為這些字符串包含有關示例行為的核心信息。
文件也使用AES進行保護KONNI Rat 在執行時會使用各種支持文件，其中一個文件是.ini 文件，其中包含主要的CC 服務器，但還有其他文件，例如應該最終刪除的.dat 文件，以及用於發送有關計算機的一些基本信息的臨時文件。
調查顯示，所有這些文件都使用AES進行了刪除和保護。巧妙的地方在於，他們重用了用於字符串保護的算法，使文件佈局與受保護的字符串佈局相同，因為它們出現在原始內存中：
新的KONNI示例現在也使用AES加密來保護文件
從圖中可以看出，文件本身包含了IV和加密的數據。使用的密鑰是從其原始文件名中提取的。在某些情況下，名稱與服務名稱匹配，因此.ini 和.dat 文件中使用的密鑰也是對服務名稱應用SHA256 的結果。
此外，發送到CC 服務器的文件使用AES 進行保護。 IV 是使用QueryPerformanceCounter API CALL 生成的。文件名由表示數據的2個字母和當前時間戳連接而成，後面跟著擴展名。此外，他們將使用這個新生成的名稱作為AES密鑰，因此他們通過請求將這個名稱發送到CC服務器。
即將發送到服務器的請求片段
由於文件名是使用時間戳自動生成的，因此相同的文件將產生不同的請求內容，因為它們是使用該文件名加密的。因此，網絡簽名也可能無法檢測到此惡意活動。
其他模糊處理技術除了發現一些僅通過我們之前描述的方式受到保護的示例，我們還發現了其他使用身份不明的封裝程序的示例。我們想分享一些關於該封裝程序的註釋，因為其他人可能會發現它在識別和歸因任務中很有用。
指令連續模糊處理模糊處理程序的流程將使用一系列推送調用指令對，其中推送的值將指示程序將採取的行動。下圖可以更好地解釋其過程：
推送調用指令對
特別值得注意的是，攻擊者在這些對之間放置了隨機字節。這個愚蠢的技巧會導致反編譯程序錯誤的代碼解釋，這些反編譯程序會假定push 指令之後的字節是下一條指令的一部分。下圖顯示了IDA 無法分析代碼的原因：
與前面的代碼相同，顯示了IDA為何不能表示真正的代碼
模糊處理程序流程使用的封裝程序會模糊處理原始程序流程。這是通過不同的步驟中完成的。第一個需要的步驟是找到Image Base 值，放置在一個固定位置和RIP（指令指針）值。
EBX 將保存RIP 值
一旦封裝程序知道這兩個值，它就會開始從一個地方跳到另一個地方，使分析變得更加困難。為此，它將存儲在下一個地址的某個寄存器值中以跳轉到寄存器中。這些寄存器的值是在jmp 指令之後立即計算的，使用像POP [reg] - jmp [reg]或ADD [reg1, reg2] - jmp [reg1]這樣的結構。請注意，反編譯程序將無法顯示實際流程，因為跳轉地址是由一個未定義的寄存器確定的。
顯示最終jmp 變為RBX 的模糊處理代碼
這些簡單技術的組合使封裝程序現在處於流的控制中，但靜態反編譯程序無法表示代碼將遵循的路徑。最後，封裝程序會執行大量的垃圾指令，並最終執行真正有趣的代碼。例如，在IAT 構建任務中，原始代碼在GetProcAddress 調用之間將使用不超過20 條指令。但封裝後的代碼可執行超過30000 條指令。
但根據最近的追踪分析，最近的攻擊不再使用該封裝程序。
總結如上所述，KONNI Rat 每隔一段時間就會更新迭代一次。開發者會不斷改進代碼。在我們看來，他們的努力旨在打破沙盒規則，使檢測更加困難，特別是通過常規簽名，因為可執行文件的關鍵部分現在已加密。