Recently we came across a new family of cross-platform backdoors for desktop environments. First we got the Linux variant, and with information extracted from its binary, we were able to find the variant for Windows desktops, too. Not only that, but the Windows version was additionally equipped with a valid code signing signature. Let´s have a look at both of them.
DropboxCache aka Backdoor.Linux.Mokes.a
This backdoor for Linux-based operating systems comes packed via UPX and is full of features to monitor the victim’s activities, including code to capture audio and take screenshots.
After its first execution, the binary checks its own file path and, if necessary, copies itself to one of the following locations:
One example would be this location: $HOME/.local/share/.dropbox/DropboxCache. To achieve persistence, it uses this not very stealthy method: it just creates a .desktop-file in $HOME/.config/autostart/$filename.desktop. Here’s the template for this:
Next, it connects to its hardcoded C&C Server. From this point, it performs an http request every minute:
This “heartbeat” request replies with a one-byte image. To upload and receive data and commands, it connects to TCP port 433 using a custom protocol and AES encryption. The binary comes with the following hardcoded public keys:
The malware then collects gathered information from the keylogger, audio captures and screenshots in /tmp/. Later it will upload collected data to the C&C.
/tmp/ss0-DDMMyy-HHmmss-nnn.sst (Screenshots, JPEG, every 30 sec.)
/tmp/aa0-DDMMyy-HHmmss-nnn.aat (Audiocaptures, WAV)
/tmp/dd0-DDMMyy-HHmmss-nnn.ddt (Arbitrary Data)
DDMMyy = date: 280116 = 2016-01-28HHmmss = time: 154411 = 15:44:11nnn = milliseconds.
This part of the code is able to capture audio from the victim’s box.
However, audio capturing is not activated in the event timer of this binary, just like the keylogging feature. Since the authors have statically linked libqt, xkbcommon (the library to handle keyboard descriptions) and OpenSSL (1.0.2c) to the binary, the size of the binary is over 13MB. The criminals also didn’t make any effort to obfuscate the binary in any way. In fact, the binary contains almost all symbols, which is very useful during analysis.
There are also references to the author’s source files:
Apparently, it’s written in C++ and Qt, a cross-platform application framework. According to the binary’s metadata it was compiled using “GCC 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)” on Ubuntu 14.04 LTS “Trusty Tahr”. According to the
qt_instdate timestamp, the last time the Qt sources were configured was on 2015-09-26 (qt/qtbase.git: deprecated), which implies the compilation time of the malware to be not earlier than end of September 2015.
We detect this type of malware as Backdoor.Linux.Mokes.a.
OLMyJuxM.exe aka Backdoor.Win32.Mokes.imv
Just a few days ago, we came across a rather familiar looking sample, although it was compiled for machines running Microsoft Windows. It quickly turned out to be a 32-bit Windows variant of Backdoor.Linux.Mokes.a.
After execution, the malware randomly chooses one of nine different locations in %AppData% to persistently install itself on the machine. The binary also creates a “version”-file in the same folder. As its name implies, it stores just version information, together with the full installation path of the malware itself:
Then the corresponding registry keys are created in
HKCUSoftwareMicrosoftWindowsCurrentVersionRun to ensure persistence in the system.
After the malware has executed its own copy in the new location, the SetWindowsHook API is utilized to establish keylogger functionality and to monitor mouse inputs and internal messages posted to the message queue.
The next stage in its operation is to contact the hardcoded C&C server. Besides the different IP addresses and encryption key, we see almost identical behavior.
However, this particular variant uses a slightly different implementation and tries to obtain the default Windows user-agent string.
If this is not successful, the sample uses its hardcoded version:
Like the Linux variant, it connects to its C&C server in the same way: once per minute it sends a heartbeat signal via HTTP (GET /v1). To retrieve commands or to upload or download additional resources, it uses TCP Port 433.
It uses almost the same filename templates to save the obtained screenshots, audiocaptures, keylogs and other arbitrary data. Unlike the Linux variant, in this sample the keylogger is active. Below you can see the content of a keystroke logfile, located in %TEMP% and created by this sample:
And again, we spotted some unexpected code. The following screenshot shows references to code which is able to capture images from a connected camera, such as a built-in webcam.
Similar to the Linux version, the author left quite a number of suspicious strings in the binary. The following string is surprisingly honest.
From the criminal’s point of view, it’s important that the software looks legitimate and that Windows doesn’t asks the user for confirmation prior to execution of unknown software. On Windows machines this can be achieved by using Trusted Code Signing Certificates. In this particular case, the criminal managed to sign the binary with a trusted certificate from “COMODO RSA Code Signing CA”.
We detect this type of malware as Backdoor.Win32.Mokes.imv.
Since this software was intentionally designed to be platform independent, we might see also corresponding Mac OS X samples in the future.
(2016-02-01 10:45 UTC): We just got Backdoor.Win32.Mokes.imw. This is the first time we see a variant of Mokes, which comes with the audio capture module activated. The malware creates a new audio file every 5 minutes.
Backdoor.Win32.Mokes.imv & .imw
f2407fd12ec0d4f3e82484c027c7d149 (imw)91099aa413722d22aa50f85794ee386e (imv)
%TEMP%aa$n-$date-$time-$ms.aat (imw)where $n is a decimal hash-value calculated from the soundcard’s name
HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun “%PERSISTENT-FILENAME%”, “%PERSISTENT-FILEPATH%”
where %PERSISTENT-FILENAME% is one of the filenames aboveand %PERSISTENT-FILEPATH% is the corresponding path