A few days ago, we published a blog entry on an advanced malware – Moker, and discussed the different challenges that Moker placed to avoid detection and anti-dissection.

Now that we have the stripped down malware sample, it’s time to analyze the actual malware.

Figure 1: IDA presents the opened DLL

Side Note

Moker’s downloader already appears in VirusTotal. In fact, one of the leading Anti-Virus detected the downloader “Hoax/ArchSMS”. “Hoax” may fall under the definition of “malware” or not, depending on your own philosophy. ArchSMS, however, is obviously not the malware in hand.

At time of our analysis, the DLL itself still does not appear in VirusTotal, and running the stripped-down malware through an AV shows “No threats detected.”

File Characteristics

The decrypted payload is an ordinary DLL.

It weighs 196K and has about 600 functions, none of which are exported except for the mandatory DllEntryPoint.

The tool of our choice, PEiD, cannot identify the compiler precisely. However, it tells us that the linker version is 10.0, which could suggest that it was linked (and most probably compiled) using Visual Studio 2010 which is also known as Visual Studio 10.0. We also know that the DLL is a GUI application, which may seem unusual for malware.

Figure 2: PEiD analyzes the file

Code Quality

The code quality of this DLL is relatively high. The return values of functions are always checked, pointers are validated, exceptions are handled, array boundaries are strictly kept and allocated buffers are freed on-time. This prevents memory leaks and maintains high stability for the malware’s prolonged operation.

Code quality is very important in this case. Since the malware is injected into critical system processes (such as lsass and csrss), a buffer overflow or any unhandled exception would cause the critical process to crash – taking the whole system with it, resulting in a bug-check (“Blue screen”).

Anti-Research Measures

The developers of this malware did not leave anything to chance and implemented anti-research techniques in this DLL too.

Anti-debugging is not present. However, to complicate things for the malware researcher, the author used obfuscation. It seems that the author has put thought into the obfuscation process with the intention of deceiving the researcher, choosing what to obfuscate and what to leave plain.

On first glance, one could easily believe that everything is in the open. For instance, there are plain text strings with references, and imported functions are sometimes called directly.

These miss though the deeper layer of Moker’s operation.

Some strings are loaded into buffers byte-by-byte, preventing simple string search and some of the more important strings are decrypted at runtime. Many times imported functions are resolved by their hash only. In fact, most of the time the malware uses hashing instead of string comparison. The hashing algorithm is simple enough, but to find a function from its hash an analyst has to produce hashes for all available function names. In other words, the researchers needs to perform a short dictionary attack (that is, without running the DLL dynamically).

Figure 3: Strings loaded byte-by-byte

Some functions in this binary are callback functions which are saved into structs and called dynamically. This is probably done due to design considerations but as a side effect, this measure may also be effective in preventing a researcher from finding where the function is called from.

Multi-threading and synchronization

This malware is multi-threaded, using a separate thread for every task. Threads are heavily synchronized with events, mutexes and critical sections and communication between them is done through named pipes. These synchronization objects are also used to synchronize between threads running inside different processes on the system.

Moker Capabilities

1. Allowing a remote attacker to log into the machine as Administrator.
   This is done by creating a new user with administrative rights and enabling remote desktop connections to the machine. Furthermore, if the remote desktop service is down, Moker will start the service.
   The malware hides the new Administrator user from the login screen (done through the registry). After the operation is done, the new created user is deleted and its profile folder is cleaned up.
2. Allowing an attacker to use the machine as a proxy server, similar to a Socks server.
   This way an attacker may use the infected machine to move around its local network.
3. Recording keyboard keystrokes (keylogger)
   Moker does this by installing a hook on the TranslateMessage API.

4. Downloading files from the infected machines
   Files can also be matched with a wildcard mask.
5. Taking screenshots
6. Recording and altering HTTP(s) traffic.
   The attacker sets the infrastructure for Man-in-the-Browser attacks by hooking the API functions appearing in the Appendix. This enables the malware to read web form data and cookies, as well as to inject content into received pages.
7. Changing system settings in order to disable both the UAC prompt and various web browsers’ restrictions.
8. Allowing the attacker to send a new payload to the infected machine. Interestingly, the malware will load the new payload into all processes, which basically allows installation of any other malware at will.

Communication and Server

As said in part 1 of our blog post, the sample did not communicate with any server. Extracting information from the infected machine and altering the program’s flow revealed an IP address based in Montenegro referred by a domain with .GA extension.

The HTTP server behind this address is active, but our request returned error 404 (not found).

It’s worth mentioning that our sample tried to communicate directly with this IP address in case domain resolution fails. This suggests that the server is owned by the attacker and that the command and control mechanism is hosted on either a Virtual Private Server (VPS) or a dedicated server with static IP, rather than on a hacked web site or a shared hosting service, which is generally more expensive.

Local command and control

Since our sample did not communicate, we went searching for other means for the malware’s command and control.

Our search yielded a function that checks for the existence of a certain global event on the system (to be created with the CreateEvent API). If the thread, running inside of Explorer.exe, finds this event in the system (either signaled or not) – it will create a window and show it to the user:

Figure 4: Remote vs Local Commanding of the Infected Machine

This window lists active sessions (including remote desktop sessions), shows which user is currently logged on and features some commanding abilities such as executing a process.

The command from this window is relayed through a named pipe to another thread which in turn executes it with Moker’s high permissions.

The author invested in this command window as well. When created, it is hidden from view until selected from the Alt-Tab switcher. The window itself supports drag and drop of files, and is also capable of following windows link files when presented with one.

Conclusion and thoughts

It’s obvious that Moker was written by highly-skilled malware authors. Some of these capabilities are incorporated in other malwares and some have been honed here.

For now, this is where our analysis of Moker ends in a level that satisfies our curiosity and hopefully – yours too.

Moker is representative of the cat-and-mouse game between Anti-Virus and malwares. For cases where the malware defeats the Anti-Virus, we need to approach security in a different manner. Assuming that the system is, or eventually will be, infected – let’s consider what is the attacker’s ultimate goal and how do we prevent the threat from winning.

On to the next challenge.

Appendix

The AP functions that Moker hooks into for its Man-in-the-Browser infrastructure and recording web traffic:

wininet.dll –

InternetCloseHandle

InternetSetStatusCallback

HttpSendRequestA

HttpSendRequestW

InternetQueryDataAvailable

InternetReadFile

InternetReadFileExA

InternetReadFileExW

HttpQueryInfoA

InternetQueryOptionA

nspr4.dll –

PR_Poll

PR_Read

PR_Write

PR_GetError

PR_SetError

PR_Available

PR_GetNameForIdentity

The post Moker, Part 2: Capabilities appeared first on Breaking Malware.