New Remcos RAT Variant is Spreading by Exploiting CVE-2017-11882

everal days ago, FortiGuard Labs captured a malware sample that was exploiting the Microsoft Office vulnerability CVE-2017-11882 patched by Microsoft last November. The sample is an RTF document with an Equation object. By analyzing its behavior in my test environment, I realized that it spreads a new variant of Remcos RAT, version “2.0.4 Pro,” that was released on April 7, 2018 from its official website. It is able to control the victim’s PC after infection.

In this blog, I am not going to explain the causes of the vulnerability CVE-2017-11882, but how the sample works to spread this new Remcos RAT, as well as what this variant does on a victim’s PC.

“RFQ File.doc” is the sample’s name, which is an RTF file. Equation object data (attack data) is included in the “\*\objdata” destination. To avoid being detected by cyber security products such as Firewall devices and Anti-AV software, the attacker added a lot of padding data in front of the real Equation object, and even the real Equation object data was split into many parts using ASCII control characters like White Space (0x20), Tab (0x09), Carriage Return (0x0D), or Line Feed(0x0A). These control characters are ignored by the parser — MS Office Word. It’s kind of an escape method to avoid security products.

In Figure 1, you can see partial content of the RTF sample. I also added comments to it.

For you to clearly see the real Equation object data, I removed the useless padding data and restored the data that was being split. You can see the whole data in Figure 2.  The malicious shellcode is in it.

When this RTF sample is opened in MS Office Word, a buffer overflow happens and the shellcode is executed. Because the core shellcode and data are encrypted, the data is first decrypted and then jumps to execute the core shellcode. Figure 3 below provides a partial view of the decrypted core shellcode and string content.

The shellcode is a downloader. Its only purpose is to download files from “hxxp://persianlegals.com/wp-includes/js/gist.exe” into “%APPDATA%\namegh.exe” and then run the downloaded file. Figure 4 shows that it calls API CreateProcessW to run the downloaded file, and later calls API ExitProcess to terminate EQNEDT32.EXE running.

The downloaded file is a self-extracting file, which means that it contains a compression archive and a small program to decompress it into a specified folder and then execute one of the files.

For this instance, it extracts the files into the “%temp%\ 01644247\” folder, sets the entire folder to Hidden property, and later runs the file “%temp%\ 01644247\enj.exe” with the argument “%temp%\ 01644247\cgj=agr”. Figure 5 shows a screenshot of this folder in my test environment.

Through my analysis, the file “enj.exe” is, without a doubt, an AutoIt script interpreter program. The program version is 3.3.8.1, though its official website shows the latest version to 3.3.14.5. The file “cgj=agr” is the malicious AutoIt script, and “ujb.mp4” is the configuration file, which is going to be read and parsed by the “cgj=agr” script. Other files were not used in my analysis.

Put “cgj=agr” into any text editor and you can see that the content is full of “#xZQMLS??????????????????????????????????????????????????” characters inserted between the real script code.  “#” starting lines can be thought of as a comment to AutoIt. By removing all the “#” lines we can get the clear script, as shown in Figure 6, but you may also notice that the code was obfuscated.

All the names of variables and methods are meaningless, which makes it hard to perform static analysis. So I manually deobfuscated the script and debugged it in the AutoIt Debugger.

By examining Figure 7, below, using the deobfuscated code, it’s easy to understand what it is going to do. It reads the config data from “ujb.mp4”, from which it then extracts and decrypts “[sData]” data (i.e. between “[sData]” and “[esData]”). Later, it writes the decrypted data into a random name file. This newly created file will be located in the same path as “cgj=agr”, and its name will consists of 5 random letters. This time it is “SENPR”. “SENPR” is another obfuscated AutoIt script, and I manually deobfuscated it as well.

This one also reads “ujb.mp4” – the config file – and loads some setting values from it, which can change the code branch.

By following its main branch, we can figure that it does the following things :

1) It adds itself into the system registry as an Auto Run item. This allows the malware to start automatically when the system starts.

Below is a code snippet:

It also adds a new key named “WindowsUpdate” into “HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run”. Figure 8 shows that the new item was added into the registry. The file name is in short name format.

2) It then extracts the “[Data]” data (i.e. between “[Data]” and “[eData]”) from the config file and decrypts it to get a PE file. It then gets the exe file’s full path in the .Net frame install directory – “RegSvcs.exe”, which will be executed later. (“RegSvcs.exe” is a .NET Services Installation Tool).

To prevent its code from being easily analyzed, it has an x86 ASM binary code that runs “RegSvcs.exe” with suspended status by calling CreateProcess and then replacing its code with the decrypted PE file.  This allows the decrypted PE file to play as “RegSvcs.exe” in order to execute malicious things on a victim’s machine. I call it a fake “RegSvcs.exe” in my analysis below. BTW, the decrypted PE file was never saved into a local file. Instead, it always lives in the memory. If you are not deeply debugging it, you would never know it, but this PE file is the main component of Remcos RAT. Figure 9 shows the code snippet of “SENPR” that executes x86 ASM code to run the fake “RegSvcs.exe” in the “RegSvcs.exe” process.

Code in lines 237 and 238 show that the API “CallWindowProcW” calls the x86 ASM binary code in the “enj.exe” process (the AutoIt interpreter). The x86 ASM code contains one main function. Its purpose is to call several APIs to run the fake “RegSvcs.exe” up in the real “RegSvcs.exe”. The called APIs are familiar, such as CreateProcessW, RtlMoveMemory, ZwUnmapViewOfSection, VirtualAllocEx, WriteProcessMemory, RtlMoveMemory, GetThreadContext, SetThreadContext, and ResumeThread, etc.

When the fake RegSvcs.exe gets executed, it first reads the data from a resource named “SETTINGS”. This consists of two parts; the first part is an RC4 key seed of 80H size in bytes that is used to generate an RC4 Key to encrypt/decrypt all data in this malware, including the data sent to the C&C server.

The rest is encrypted data. Decrypting provides the information shown in Figure 10. It is like a config file that contains C&C server related information as well as some of the flags that will control the code flow. As you can see, all data were separated by the string “@@”.  Later, each data is split by “@@” into a global array so that all of them can be located by an array index. In the analysis below I call it the “SETTINGS” array.

It first creates a sub-key in the system registry as its home, where it saves its configuration data. The sub-key locates “HKEY_CURRENT_USER \Software\Fmt-W5SO9H\”, where “Fmt-W5SO9H” is from the “SETTINGS” array.  It then adds the value name “EXEpath” into FMT-W5SO9H with the value of the encrypted Unicode RegSvcs.exe full path, as you can see in Figure 11. BTW, the encryption key was generated by the first 80H data of the resource “SETTINGS”, which was used to encrypt the full path of the RegSvcs.exe (It’s shown as “C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegSvcs.exe” in my test environment.)

You may notice that this malware likes using threads to work.

It runs three threads whose thread function works together to collect data from the system clipboard, which contains software windows information that the victim is working on. In this case, the collected data is saved in the shared global variable unk_419830. unk_419830 is a global object, whose offset +4 is a string object holding the collected data.  Finally, it encrypts all the collected data and saves into a local file. This local file is “%appdata%\skype\logs.dat”. The directory “skype” and the file name “logs.dat” are from the “SETTINGS” array (see Figure 10.) It masquerades as a Skype file.

Before creating these three threads, it initializes the global variable unk_419830 with keyboard information and the current local time.

Thread1:

This thread’ task is used to encrypt the collected data in the global variable unk_419830 and then append it to the local file “%appdata%\skype\logs.dat”. If the folder does not exist, it first creates it. It performs this task every 10 seconds. For the very first time, the thread function encrypts the string of current date/time in a global variable. The string likes “\r\n{ 2018/04/18 10:26:09 – Offline Keylogger Started! }\r\n”.

The encryption algorithm is RC4, and the encryption key is also from the first 80H data from resource “SETTINGS”.

Thread2:

The purpose of this thread is to setup a keyboard hook by calling the API “SetWindowsHookExA” with the idHook parameter “WH_KEYBOARD_LL”. In this way, the hook function can handle the keys that the victim pressed before the destination software does.

The hook function records the victim’s inputs and appends the key value to the global variable unk_419830. The key record format is like “[Ctrl + C]”, which means the victim pressed the Control and C keys. It also copies clipboard content and appends it to the global variable unk_419830 when the victim presses the Control and V keys. Here is the string format: “[Ctrl + V]\r\n[ Following text has been pasted from clipboard:]\r\n CLIPBOARD CONTENT\r\n[End of clipboard text]\r\n\r\n”.

Thread3:

This thread works every 500ms. It gets the topmost window’s title and system clipboard content, as well as the user’s idle time. In the same way, the collected information is formatted and appended to the global variable unk_419830.

As I mentioned before, the collected data in the global variable unk_419830 is encrypted and stored into file “%appdata%\skype\logs.dat”, and the file is then set as Hidden & System property. Figure 13 shows this logs.dat file’s property.

Figure 14 shows an example of the collected data from my environment, which was encrypted and saved in “%appdata%\skype\logs.dat”.

As you may see in the record, I first opened “credential.txt” file in Notepad, copied the file content to the clipboard, and then pasted it to the same file.

I next typed a test account and test password in an online bank login page using IE browser.

After doing that, I stopped for around 2 minutes. Finally I opened Firefox and typed “www.google.com” and hit the Enter key. The malware successfully recorded everything I did.

Meanwhile the malware runs another thread every 10 minutes to keep clearing the browser’s cookies file and the stored logins records. In this way, it can force the victim to enter his username and password using the local keyboard when logging into those web sites that have been saved in cleared cookies or logins files.  In this way the three threads described above can record the victim’s account and password. Let’s see how it achieves clearing the browser’s cookies and storing the logins:

It reads key values from system registry « HKEY_CURRENT_USER\ Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folder\Cookies » to get the cookie location « %USERPROFILE%\AppData\Roaming\Microsoft\Windows\Cookies » for IE browser cookies, and then deletes all files under this folder.

It then deletes all cookies.sqlite and logins.json files from the sub-folders of “%UserProfile%\AppData\Roaming\Mozilla\Firefox\Profiles” to clear Firefox cookies and stored logins.

Finally, it deletes the file “%UserProfile%\AppData\Local\Google\Chrome\User Data\Default\Cookies” to clear Chrome cookies, and deletes the file “%UserProfile%\AppData\Local\Google\Chrome\User Data\Default\Login Data“ to clear stored logins of Chrome.

Figure 15 is an example of pseudo code and how it clears the stored logins in Chrome.

Finally, it connects to its C&C server, the host and port of which are collected from the “SETTINGS” array. They are “polextrading.ddns.net:1667:moron” and “poliy.kozow.com:1667:moron”.

It then sends collected information about the victim’s PC to the C&C server. The data gets RC4 encrypted before being sent out, with the same RC4 encryption key generated from the first 80H data of resource “SETTINGS”.

I dumped the data that was going to be sent to the C&C server, before it was encrypted, as shown in Figure 16.

I then wiped some sensitive information about my test environment. This content contains two parts – the header and the data. It should be the same packet format for the packets coming back from the C&C server.

Let’s examine what has been harvested from my test PC.

The first 13H bytes are the packet header:

“[DataStart]” tells that it is the first packet to the C&C server.

The following “B0020000”, which is 0x2b0, is the size of the rest data in bytes, while

“4B000000”, is a sort of packet identification.

The rest is the data part that is split by “|cmd|”:

“Java”, which is from “SETTINGS” array. “|cmd|” is a kind of separator.

As you may see, it was able to collect the Computer name, User name, Windows Product name, System language, Physical Memory capacity, CPU information, IsAdmin, Topmost window title, “logs.dat” full path, and the “RegSvcs.exe” full path. It also grabs its home name “Fmt-W5SO9H”, the host string “polextrading.ddns.net”, as well as the malware version “2.0.4 Pro” into this packet.

Unfortunately, the C&C servers were down when I was analyzing how it communicates with the C&C server side. So we still have an unanswered question as to how it sends out the “logs.dat”. This file is, I believe, the final purpose of this RAT malware.

Ok, here we go. The answer, derived through my analysis, is that the C&C server can send back packets to ask for that file. The C&C server’s packets are handled in a thread function. This function is very huge, containing up to about 64 code branches, and the packet identification is the switch. It can do many things asked by the C&C server simply by sending packets to this malware.

Below is a list of most of the branch features:

·       Send topmost window information

·       Get information from system registry

·       Download a executable file

·       Execute downloaded file

·       Get running process list

·       Kill running process by PID

·       Get all window handles

·       Set window title by handles

·       Show or Hide any window by handles

·       Get screenshots

·       Stop and restart Keylogger (those 3 threads)

·       Upload any local file to the C&C server

·       Delete any local file or directory

·       Clear browser cookies and logins

·       Get all file names into a folder

·       Open and close recording audio from waveform-audio input device (sound card)

·       Terminate this malware process

·       Delete its information from system registry

·       Run “restart.vbs” to restart this malware

·       Write data onto victim’s clipboard

·       Write data into local file

·       Rename local file

·       Get PC name and User name

·       Get local Logical Drive status

·       Change the style of desktop wallpaper style

As you have noticed, one code branch can upload files to the C&C server. Remember, the first packet to the C&C server contains the full path of “logs.dat”. So it allows the C&C server to send a packet with the full path to get this file uploaded onto it. In Figure 17, I list a partial set of pseudo code to show you how it reads file content and calls functions to encrypt file content. BTW, the packet identification for uploading the file is 82 (52H).

Fake “RegSvcs.exe” starts a suspended “svchost.exe” process. Later,it puts the entire code of the fake “RegSvcs.exe” into “svchost.exe” and resumes its running.  The one in “svchost.exe” reads the “WD” value from its home in system registry « HKCU\Software\Fmt-W5SO9H\ ». According to the “WD” value, it takes different branch of the fake “RegSvcs.exe”.

The “WD” value is the process ID of the fake “RegSvcs.exe”. Using the process ID, it can detect if fake “RegSvcs.exe” are running from time to time. If not running, it restarts again to keep fake “RegSvcs.exe” running. Unfortunately, the author of the RAT malware made a mistake here: it directly runs the real “RegSvcs.exe” without injecting the malicious code. Therefore, if you kill the “RegSvcs.exe”, it’s done. It will never run again by “svchost.exe”, unless restarting the system.

Back to the fake “RegSvcs.exe” side. It does the similar protection. When it runs the “svchost.exe” it keeps checking to see if it is running by its process ID. The malware runs it again if this “svchost.exe” was killed.

That means these are daemon programs each other.  You can see the daemon code from the fake “RegSvcs.exe” side in figure 18, below.

The file “RFQ File.doc ” has been detected as “MSOFFICE/CVE_2017_11882.A!tr”, and the file “gist.exe” has been detected as “AutoIt/Remcos.DGY!tr” by FortiGuard AntiVirus service.[…]