In-Depth Look at New Variant of MONSOON APT Backdoor, Part 1

Credit to Author: Jasper Manuel and Artem Semenchenko| Date: Wed, 05 Apr 2017 08:58:03 -0700

Three weeks ago, FortiGuard Labs, along with @_ddoxer (Roland de la Paz), using VirusTotal Intelligence queries, spotted a document with the politically themed file name “Senate_panel.doc”. This malicious RTF file takes advantage of the vulnerability CVE-2015-1641. Upon successful exploitation, it drops a malware in the %appdata%Microsoft directory. To evade suspicion by the victim, it also drops a decoy document which shows the symbol of the Ministry of Foreign Affairs of Pakistan on the first page, but on the next pages shows an article about the Senate of Pakistan. 

Decoy document

Decoy document

As we were unable to identify which malware family the dropped malware belongs to, we tried to dig a bit further. Our analysis exposed that this is a new variant of a malware dubbed as BADNEWS, which is actively being used in the MONSOON APT campaign. This variant steals documents from USB drives.

The first thing we wanted to learn is if there were other files similar to this malicious RTF file that had been submitted to VirusTotal after the discovery of the APT campaign was first published in August 2016. A quick similar-to: search in VirusTotal provided 3 results:

VT similar-to: search gives 3 similar malicious RTF files

VT similar-to: search gives 3 similar malicious RTF files

It looks very similar to file that was submitted to VirusTotal on 11/08/2016 with file name “Who_would_win_an_all_out_war_between_Pakistan_and_India.doc,” and another one submitted on 03/08/2017 with the file name “Jobs.” Executing the files reveals that the first has a theme similar to the initially discovered file, while the other looks like a United Nations career opportunities guide document. All of them drop the same malware, with only small code variations.

Malicious RTF

In this blog we will just run a quick analysis of the malicious RTF shellcode, as our colleague Wayne already did an in-depth analysis of CVE-2015-41 here. RTFScan tells us that there are 4 objects in this RTF file, and dumps these objects as separate files.

Object 2 contains a zip file with “PK” header, which is obviously an embedded OLE document. When you extract the contents of this OLE object, we notice that it contains 2 activeX.bin files (activeX1.bin and activeX2.bin)

The first contains the first-stage shellcode. The second contains the second-stage shell code, the malware, and decoy document.

We attached winword.exe to a debugger and opened the malicious RTF file to see what the shellcode does. As seen below, the first stage shellcode searches for the marker 0xC24350D1 in the activeX2.bin file, then allocates memory where it copies 0x88F bytes after the marker. The copied data is the second-stage shell code, and is decrypted using SUB 0x37 on each byte. After decryption, the second shell code is called.

The second stage shellcode uses hardcoded offsets to locate the encrypted files.

After decrypting the first file using SUB 0x37 on each byte, it drops the file as %appdata%MicrosoftTemplatesmsvcrt.dll. It then drops the file ~Normal.dat in the same directory that contains the encrypted decoy document and the malware, along with other legitimate files. The file msvcrt.dll is loaded using LoadLibraryW(). The shellcode then cleans up the registry in HKCUSoftwareMicrosoftOffice1{0-6}.0WordResiliency to prevent warning messages when someone re-opens a document that has crashed previously.

The msvcrt.dll file loads the ~Normal.dat file in memory. The decoy document is first decrypted using the same decryption algorithm, and is dropped as %localappdata%MicrosoftWindows.doc. It is started using hidden cmd.exe /c start .

The following files are also decrypted from ~Normal.dat file using the algorithm XOR 0x41, SUB 0x7 on each byte, and are dropped in the %appdata%Microsoft directory as:

MicroScMgmt.exe

msvcr71.dll

jli.dll

The file MicroScMgt.exe is then executed using CreateProcessA(). The file jli.dll contains the malware dubbed as BADNEWS. BADNEWS was the name given to this malware as it uses news sites and blogs to obtain its C&C servers.

BADNEWS Backdoor

BADNEWS uses a DLL side-loading technique with a signed Java executable to evade the Host Intrusion Prevention System (HIPS) of security programs that monitor the behaviors of executed files. Most HIPS tools whitelist signed or trusted files. This technique is reminiscent of the PlugX backdoor technique because it also piggybacked on signed legitimate files to execute the PlugX backdoor.

MicroScMgmt.exe is a renamed version of java-rmi.exe, the legitimate Java Runtime executable version 6.0.390.4. This file needs to load the legitimate DLLs msvcr71.dll and jli.dll to import some functions. However, the dropped jli.dll file here is crafted to contain the BADNEWS code.

All functions exported by this jli.dll file point to a single routine, which is the malware code, so upon execution of the MicroScMgmt.exe file one of these functions will be called, effectively calling the malware code.

Export functions point to malware code

Anti-Analysis Techniques

The malicious DLL file is not packed ,but is obfuscated to deter analysis.

Anti-sandbox/emulator

A long loop has been added before it performs its malicious routines. Many sandboxes and emulators only run for a certain short period of time until they time-out, so malware behavior usually are not captured when malware goes in a long loop before it performs its routines. An emulator, though, that can patch files it tries to emulate, can easily bypass long loops.

Long loop as anti-sandbox/emulator

Reversed, Garbage, and Encrypted Strings

BADNEWS has a lot of reversed, garbage, and encrypted strings. However, the string encryption is just a simple minus 1 on each byte.

API resolution

Traversing the export table to get the API address is an old technique used by malware, but if a malware like BADNEWS does this, most of the time it calls a Windows API without any function for it. That could be very annoying to analyze, as manually setting the type of variables is needed in IDA for each resolution in order to get proper decompilation.

LoadLibraryA() is resolved twice

Auto-Start Mechanism

This malware creates the following registry entry, so it starts when the machine reboots.

HKCUSoftwareMicrosoftWindowsCurrentVersionRun

JUSCHED = %Appdata%MicrosoftMicroScMgmt.exe

Creates Threads

BADNEWS backdoor also creates 2 threads. One performs key-logging, and the other one steals documents from USB drives.

Key-logging

The first thread creates a hidden window to log keystrokes, and saves them to a file named %temp%TPX498.dat.

Hidden window creation

When the window procedure is called, the function checks to see if the message the window received is WM_LBUTTONDOWN. This means the user presses the left mouse button, and this is when it starts to log keystrokes.

The file TPX498.dat starts with the marker “K L T N M :    Appdat” followed by the keyboard layout code which signifies the language. The rest is a list of information about the captured keystrokes. The information contains the date when the keystrokes were captured, the window title, and the keys pressed while on the window. In the example below, the language code is 0x0409, which means English – US. It shows that the user left-clicked on the window with title Temp (active window is Windows explorer, the user is exploring the %temp% directory,) which started the keylogging routine.

TPX498.dat file contains the logged keystrokes

Stealing Documents from USB Drives

The second thread again creates a hidden window to monitor when a new USB device is added to the machine. It does this by first checking to see if the message received by the window is WM_DEVICECHANGE.

Device change detection

It then sends the IOCTL_STORAGE_QUERY_PROPERTY control code to all volume devices. The devices should return a STORAGE_DEVICE_DESCRIPTOR data containing the BusType. If the BusType is BusTypeUsb (0x07), the thread then knows that the new device is a USB drive, and the stealing routine is called.

BusType should be BusTypeUsb to enable stealing of documents

The function then creates a folder named “SMB” in the %temp% folder and creates a folder with the following name format ,where it stores the stolen files for each USB drive it tries to steal documents from.

Ex.

The files in the USB drive are then checked to find documents to steal. The documents it tries to steal have the following extension names, with file size less than 15MB:

Earlier variants also steal files with extension names .xls, .xlsx, .rtf, .zip, .7z, .rar.

The following files are created in the SMB folder:

The MUT.dat file looks like a dummy file, and is not used. TZ0000001.dat contains filenames and file sizes found in the USB drive. If the file size is greater than 15 MB, or the file doesn’t have the file extension above, it will mark it as “HUGE:” so it will not be stolen. Otherwise, a 0 will be appended following the file name.

The file TZ0000002.dat contains a list of files to be stolen. Files with file name with random alphanumeric characters without extension names are actually copies of the files it tries to steal. When opened, a file contains the file path and the contents of the file.

Command and Control Communication

BADNEWS backdoor has a bit of an interesting way of getting an updated C&C server. It uses legitimate web services like Github, Dynamic DNS, RSS feed, blog, and forum websites to host encrypted data that contains the actual C&C server. Below are the hardcoded URLs where the encrypted data is hosted:

hxxp://www.webrss.com/createfeed.php?feedid=49321

hxxp://feed43.com/0414303388550176.xml

hxxps://r0nald2017.wordpress.com/2017/02/16/my-first-post/

hxxps://github.com/r0nald2017/project1/blob/master/xml.xml

r0b1n.crabdance.com

r0nald.ignorelist.com

This technique does not just make it easy to update the C&C server, but also so that security vendors can’t proactively block the hardcoded URLs since they point to legitimate services.

Encrypted C&C server information hosted in Github

The above data is encrypted by performing ROR by 3 bits and XOR by 0x23 on each byte, converting the result to hexadecimal representation and lastly encode it with base64. When decrypted, the real C&C URL is revealed.

The C&C server is written to the file %temp%TZ90.dat as a backup in case the URLs embedded in the malware body are already down.

After obtaining the C&C URL, this backdoor generates a unique identifier for the machine using a value from GetTickCount() and prepares a message containing the generated UID, system information and the malware version:

The UID is saved in the file %temp%T89.dat so the same UID will be used every time it contacts the C&C server. The malware version seems to be bogus though, as earlier variants found in 2015 also use v=2.2 ]which is hardcoded in the malware body. Username and computer name are in Unicode and in hexadecimal representation.

This message is encrypted using the above encryption algorithm before it is sent to the C&C server via HTTP POST. To further obfuscate the message, it splits it into several bogus fields with randomly generated names so it looks like a normal query string.

HTTP POST data contains bogus fields

Commands

One of things that makes BADNEWs backdoor a bit difficult to analyze, as with other bots, is that the server doesn’t always respond. It took us 1.5 weeks of monitoring to finally get a response. However, it looks like the bad guy manually controls the C&C every time it becomes active. The moment we got a response, the bad guy issued a command to capture a screenshot, which was sent back to him. After that, we got a “403 Forbidden” response. It also looks like the IP address that was used during monitoring was blocked.

Commands received from the server have the format :. Encrypted data uses the above encryption algorithm, and can contain a URL where a file is downloaded, or a file path to upload to the C&C server, or a command for the remote shell.

“snp”: command to take screen shot then send to C&C

Below are the commands found in the malware body, along with their descriptions:

For the commands where this malware needs to send a file to the C&C, there are 4 messages it sends to the C&C. If it’s not sending a file, it sends just the last one, signifying that a command has been performed. Below are the 4 messages, in the order of when they are sent. The “tt” parameter contains the file.

“&tt” field contains the file it uploads

Here are some interesting observations about the how the commands were implemented. First, it looks like for the commands “mod” and “upd” the author intends to execute the downloaded files, but there’s a bug in the code where LoadLibraryA() function is called. Instead of passing the path of the downloaded file as a parameter, it passes the contents of the file, therefore LoadLibraryA() sets the error ERROR_MOD_NOT_FOUND. For the commands “link”, “mod”, and “upd”, if the malware fails to create the files they are executed using process hollowing. The file downloaded using the command “shell” is not executed, however the remote shell can be used to execute it manually by the attacker.

Hidden CMD

When this backdoor receives the “hcmd” command, it creates a hidden “cmd.exe” process. This hidden cmd.exe acts as a remote shell that uses the standard input and output to pipe the commands from the C&C server to the cmd.exe, and the output to a created file in %temp% folder named DMCZ0000.dat.

Hidden cmd.exe process

To better understand how this works, Microsoft published an article describing how to create a child process with redirected input and output.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms682499(v=vs.85).aspx

The DMCZ0000.dat file is then sent to the C&C server.

DMCZ000.dat contains cmd.exe output

In part 2 of our analysis, we will try to discover who might be behind the distribution of these malicious files.

-= FortiGuard Lion Team =-

https://blog.fortinet.com/feed