South Korea Incident - Analysis of a tiny Downloader

In this short Blogpost I am going to dissect a Downloader which is part of the ongoing "1Mission" campaign against targets in South Korea (thanks Chae Jong Bin for pointing me at). The Downloader comes in the form of a DLL and has the small size of 4 KB. What remains unknown is the way the DLL gets executed (through exploit/loader/...). Except its small size there isn't anything special about this malware. Unfortunately the file it wanted to download isn't available anymore, so there is no chance to dig deeper...

DLL sample
Size: 4.096 Bytes
Timestamp: 2013-05-30 03:54:37
MD5: 17e3e09c27d26c81c9f33882279d6319
SHA1: c467f59cddba2d029044f6f2b22b6b2123b341b6
Report: https://www.virustotal.com/en/file/5b011ebdf1a5a0fd93a933cb40b59fcb8c35667529e28cf0c9d63f92985c4d5d/analysis/
Download: http://www.kernelmode.info/forum/viewtopic.php?f=16&t=2690&p=19700#p19700


The DLL has no export table, so we start at the DLL Entry Point (DllMain). At first the malware checks if it was loaded by the current process or by a call to API function LoadLibrary (fdwReason = DLL_PROCESS_ATTACH). If this was not the case the DLL exits without doing anything harmful. Otherwise the malware continues with resolving the API addresses of the functions it is going to use.

Figure 1: DLL Entry Point

Figure 2: Resolving API function addresses

Before the function addresses are to be resolved (LoadLibrary + GetProcAddress), the library and function names have to be decrypted. The decryption algorithm is a simple substitution cipher with key 0x04. The decryption isn't done in a whole, instead every library/function name is decrypted before the call to LoadLibrary/GetProcAddress.

Figure 3: String decryption algorithm

By looking at the decrypted API function names we can get an idea of the malware's intentions.

Figure 4: Comparison of encrypted and decrypted data

After successful decrypting and resolving all API function addresses, the main Thread is started (CreateThread). At first it renames itself from "SXS.dll" to "pbn.dll" by using MoveFile API function with parameters "c:\Program Files\Internet Explorer\SXS.dll" and "c:\Program Files\Internet Explorer\pbn.dll". The hardcoded path names tell us that the DLL was written to disk before it was loaded. Thereafter the hardcoded URL string "http://augustine.co.kr/bbs/img/icon_03.gif" is written into memory. Then a second string is build (C:\<TempPath>\kbdusv.exe) and also written into memory for later use.

Figure 5: Main threads entry point

Next, the file "icon_03.gif" (see URL above) gets written into a buffer with help of WinInet API functions InternetOpenA, InternetOpenUrlA and InternetReadFile. Subsequently the content of the buffer is written to disk by using CreateFileA and WriteFile as file "kbdusv.exe". To verify that the file is actually a Windows PE, the malware checks the first 2 bytes for the characters 'M' and 'Z' (magic value of PE Header). At the end the file gets executed by using WinExec function.

Figure 6: Varifying for PE and file execution

That's all of the DLLs functionality.


For all german speaking readers: 
I will take the chance to call attention to the case of Gustl Mollath -> www.gustl-for-help.de

Share: