Glorious Leader's Not-That-Glorious Malwares - Part 2

This is second (and last) part of the analysis of Korean Central News Agency Malware. If you haven't read the first part yet, I would suggest reading that first here.

First of all I should mention that it's not launch.exe and wdext.exe. WdExt.exe (the main dropper) drops several DLLs: arc.dll,att.dll, dis.dll, fil.dll, sha.dll and usd.dll. I'll try to analyze them all in this post.

First we'll begin with "launch.exe" as this file was the startup component of the malware after infection and registry entry inHKLM\Software\Microsoft\Windows\CurrentVersion\Run has been added for it.

 

 

Launch.exe:

This is the main component of the malware and starts at boot. At the beginning WinMain, same as dropper, it does the same fake CreateProcess call and checks for error code 0x05. After making sure that it returned the right value, it uses same "genius" trick to push the same "sophisticated" encryption key into stack and point to it from EAX register.

Then using "western-made" encryption algorithm (Rijndael), it decrypts data embedded in it's own file to generate a new valid DLL component written in Visual C++ 6. This component does have a default Visual C++ resource:

Also I should mention that this piece of DLL which never gets written on disk, calls himself "dll_suspender.dll".

Anyway, after decrypting this DLL, the code calls VirtualAlloc with a fixed address (0x10000000) and fixed size (0x15000) twice?! to make sure that it definitely allocated the page. See:

After allocation, it copies data there. So generally, this malware is "special" on everything; algorithm, encryption key, doubleVirtualAlloc, "decrypt data and write to a part of memory then allocate new memory and copy it again there instead of decrypting directly there at first place", default version resource and... I'm going to guess they intentionally made it "special" to reflect the "special" supreme leader.

Anyway, after writing data to newly allocated memory page, it calls an unpopular API to make sure it's all OK to read data from it and proceed to next step. It uses IsBadReadPtr API. After making sure that it returns 0, it calls LoadLibrary(Kernel32.dll). This is all an odd style of programming, programmer should know kernel32.dll is definitely loaded in memory, so proper API would isGetModuleHandle here not LoadLibrary, but it does the odd thing, again there is least amount of usage for IsBadReadPtr API, but this "specialware" uses it.

Wonders doesn't stop here! Next algorithm is "super-special":

• Get IAT address of DLL
• Loop through all entries in IAT
• For each IAT entry, read API address and API Name
• After reading API address and name, call GetProcAddress per entry to re-locate already known addresses of APIs
• Re-write addresses of re-located APIs in same IAT table (which is always same value)

Think I'm joking? See:

Hands down this is the best malware ever!

After all those allocations and "special" re-constructions of IAT, it calls DllMain function of the DLL file in memory. Next, it callsDllGetClassObject function of the same DLL. Finally it creates a folder called "Temp" in APPDATA directory. Here suddenly I discovered another "genius" piece of code in this "specialware".

Original infection occurs by WdExt.exe which is roughly 1.6MB and does have all necessary components including Launch.exe. After initial infection it drops followings:

WdExt.exe into %APPDATA%\Microsoft\Messenger\Extension

att.dll into %APPDATA%\Microsoft\Windows\Addins

Launch.exe into %APPDATA%\Microsoft\Defender

usd.exe into %APPDATA%\Roaming\Microsoft\Caches\Files

fil.dll into %APPDATA%\Roaming\Microsoft\Shared\Modules

arc.dll into %APPDATA%\Roaming\Microsoft\Identities\%Username%

dis.dll into %APPDATA%\Roaming\Microsoft\Common\Shared

So at next startup, ONLY launch.exe have a startup point, does run some "special" algorithms to generate a DLL and communicates with this DLL to resume suspended threads, enumerate processes and threads, create startup keys, inject DLLs into explorer.exe etc. Even though WdExt.exe has everything and Launch.exe needs it, still Launch.exe gets the startup entry and if you just rename or delete one DLL component, launch.exe by reading WdExt.exe, it can easily extract and re-construct missing component, but no, it just fails and goes on without missing DLL component. That's it. So if you just rename for exampleatt.dll to something else, even having Launch.exe and WdExt.exe with 1.6MB of size in place, "specialware" won't re-build missing part. Also I should add that if the startup entry was for WdExt.exe, everything was fine, because WdExt.exe each time extracts all files and executes Launch.exe. Also using my old tool I was able to unload each DLL component of this malware injected into explorer.exe and no any other component reloaded the missing part. So simply using my code I was able to unload all injected modules in explorer.exe without crashing or killing explorer.exe. In addition to that, simply killing explorer.exewould terminate this specialware.

Anyway, as every single DLL will take too long to analyze very deeply, I'll write them ony by one in alphabetical order and generally explain their usage:

 

ATT.DLL:

This DLL is called NtProcessMonitor by authors of it:

I'm going to speculate that the ATT name possibly coming from Supreme Leader's obsession for NBA and AT&T. Anyway, this DLL is also written in VC++ 6 and it's the first component I've seen that doesn't have any additional file in it's resources or embedded inside it's file. MD5 hash of this file is: FFFA05401511AD2A89283C52D0C86472.

This DLL after being loaded, gets current process name and ID, then calls OpenProcess on current process ID, afterwards, callsZwQueryInformationProcess with ProcessBasicInformation as second parameter for it's own process. It was the first I observed a "little-bit-advanced" API call from this malware. It enumerates current process's parent process and loaded modules and then it compares current process name to explorer.exe using manual letter by letter comparison (no function calls). If it's explorer.exe, it creates on additional thread. In that additional thread, it tries to open all processes in a loop, then it enumerates all modules in the process. Afterwards, it checks process list for"iexplore.exe;ieuser.exe;firefox.exe;chrome.exe;msimn.exe;outlook.exe;winmail.exe;wlmail.exe;msnmsgr.exe" process names. See:

Are you wondering what this DLL does after being injected into those critical processes? Well, here is the answer

First of all it just checks process name, so I renamed a tool to chrome.exe and it got injected with att.dll. The injection happens with classic OpenProcess, WriteProcessMemory and CreateRemoteThread method. It injects a shellcode along with the full path to att.dll. The shellcode, again, calls SetErrorMode API to make sure no crash will be reported. Then calls LoadLibraryW orLoadLibraryA (chooses by checking result of Kernel32.GetVersion API call!) with full path to att.dll received from injector.

Now att.dll, being injected into a process other than explorer.exe, it does it's main "genius" trick! This DLL install two inline hooks for comdlg32.dll, one for GetOpenFileNameW and one for GetSaveFileNameW. This is again one of the greatest and most useful features of this "specialware"! This dangerous and sophisticated hook which also gets installed on several important processes such as Chrome, Firefox and Explorer.exe, does have a very unique hiding feature. In these processes, if you use Common Dialogs to browse for files (save or open dialogs) in your computer, you won't be able to see this "specialware" files. But if you simply use Windows explorer dialog, you'll see them! See:

Wow! Simply amazing, isn't it? So this sophisticated hook hides files only when you use open/save dialog. Just because of this highly sophisticated hook, I almost missed all files of this "specialware", it reminded me how easy it would be to find "Supreme Leader" during a hide-and-seek game. I think they forced malware authors to write codes in a "special way" that would remind Supreme Leader to people as much as possible.

 

dis.dll:

This one is called Filesystem Monitor by authors:

I think they originally called this called dll_diskscan.dll, but they never used this name, see:

This DLL have a lot of functions identical to att.dll, for example checking for parent process ID and name and current process name comparison to explorer.exe (manual letter by letter). This DLL only works if it's loaded inside explorer.exe. After making sure it's running inside explorer.exe process, it uses SystemParametersInfoW API with 0x72 (SPI_GETSCREENSAVERRUNNING) to determine if screen saver is running, if it's running, it starts scanning drives. This DLL usesfil.dll and arc.dll which are responsible for gathering, compressing, infecting and encrypting files. This DLL enumerates drives and creates threads for them and passes discovered drives (after detecting that screen saver in on) and starts calling fil.dll and subsequently arc.dll. It literally scans for drives and passes them to sub-threads.

 

fil.dll and arc.dll:

These two files supposed to be the "file thieves". fil.dll is a wrapper for calls to arc.dll (I've discovered that it's statically linked to ZLIB library) which does have all sorts of encrypting and compressing features. But fil.dll is the one responsible for locating and choosing the important files. fil.dll have particular interest for some extensions:

Also one odd feature of fil.dll was reading and processing version string information of DLL, OCX, SYS and EXE files.

Also as I said above, in this fil.dll, I spotted this code being used as it is without a single line of modification. Well, I guess glorious leader is going to be angry that his programmers used too much "foreign" code.

Another feature of fil.dll is infecting PE files. It does by carefully detecting "MZ" banner, then it reads PE header and finally tries to read sections of PE. It also pay a special attention to rsrc. Then it injects a Manifest file to resources. See:

Infection occurs on disks locations other than local drives. Also in this DLL and arc.dll, "smart" authors didn't hide their true intentions:

USD.DLL is a simple DLL that tries to detect new USB disks and passes new locations to fil.dll and arc.dll. It usesRegisterDeviceNotification API for detecting USB devices.

SHA.DLL is also a simple DLL that keep enumerating network shares and tries to find new ones. When detected, again it passes them to fil and arc dlls.

 

Some final points:

• As you've seen all DLLs does have a real name and purpose of them inside them. One odd point was that att.dll which is responsible for injecting into several processes and hook open save dialogs, is called dll_attachdetect.dll. What they mean by attach and detect, I don't know, but I thought maybe they instead of injection they call it "attach"? No idea.
• It does have a string with "samhung" and "hana" words in it. I have no idea what they mean. See:

• There was too much duplicate copy/paste code among DLLs. I'm sure if someone wrote better code, whole malware shouldn't have occupied more than 600kb (even less). But also in the other hand, if someone wrote a better code, SO MANY things would've been different.
• I didn't detect any C&C server and network activity, not a single packet! I even suspected that maybe I missed some parts of malware, I let it run for 2 hours, but still it didn't send a single packet, not even a DNS query. Possibly it is a payload malware and it is under development? Maybe they designed malware in a way that it only works on NK computers?

 

In the end I want to send my special thanks to /r/netsec people! You guys ruined my weekend, if it wasn't for you, possibly I was going to finish second part of my article 2-3 weeks later.

P.S. If anyone needs all files of this malware in a zip file, just send a DM on twitter and I'll send you the DropBox link.