❌

Normal view

There are new articles available, click to refresh the page.
Before yesterdayThreat Research

RIG Exploit Kit Delivering Monero Miner Via PROPagate Injection Technique

28 June 2018 at 16:00

Introduction

Through FireEye Dynamic Threat Intelligence (DTI), we observed RIG Exploit Kit (EK) delivering a dropper that leverages the PROPagate injection technique to inject code that downloads and executes a Monero miner (similar activity has been reported by Trend Micro). Apart from leveraging a relatively lesser known injection technique, the attack chain has some other interesting properties that we will touch on in this blog post.

Attack Chain

The attack chain starts when the user visits a compromised website that loads the RIG EK landing page in an iframe. The RIG EK uses various techniques to deliver the NSIS (Nullsoft Scriptable Install System) loader, which leverages the PROPagate injection technique to inject shellcode into explorer.exe. This shellcode executes the next payload, which downloads and executes the Monero miner. The flow chart for the attack chain is shown in Figure 1.


Figure 1: Attack chain flow chart

Exploit Kit Analysis

When the user visits a compromised site that is injected with an iframe, the iframe loads the landing page. The iframe injected into a compromised website is shown in Figure 2.


Figure 2: Injected iframe

The landing page contains three different JavaScripts snippets, each of which uses a different technique to deliver the payload. Each of these are not new techniques, so we will only be giving a brief overview of each one in this post.

JavaScript 1

The first JavaScript has a function, fa, which returns a VBScript that will be executed using the execScript function, as shown by the code in Figure 3.


Figure 3: JavaScript 1 code snippet

The VBScript exploits CVE-2016-0189 which allows it to download the payload and execute it using the code snippet seen in Figure 4.


Figure 4: VBScript code snippet

JavaScript 2

The second JavaScript contains a function that will retrieve additional JavaScript code and append this script code to the HTML page using the code snippet seen in Figure 5.


Figure 5: JavaScript 2 code snippet

This newly appended JavaScript exploits CVE-2015-2419 which utilizes a vulnerability in JSON.stringify. This script obfuscates the call to JSON.stringify by storing pieces of the exploit in the variables shown in Figure 6.


Figure 6: Obfuscation using variables

Using these variables, the JavaScript calls JSON.stringify with malformed parameters in order to trigger CVE-2015-2419 which in turn will cause native code execution, as shown in Figure 7.


Figure 7: Call to JSON.Stringify

JavaScript 3

The third JavaScript has code that adds additional JavaScript, similar to the second JavaScript. This additional JavaScript adds a flash object that exploits CVE-2018-4878, as shown in Figure 8.


Figure 8: JavaScript 3 code snippet

Once the exploitation is successful, the shellcode invokes a command line to create a JavaScript file with filename u32.tmp, as shown in Figure 9.


Figure 9: WScript command line

This JavaScript file is launched using WScript, which downloads the next-stage payload and executes it using the command line in Figure 10.


Figure 10: Malicious command line

Payload Analysis

For this attack, the actor has used multiple payloads and anti-analysis techniques to bypass the analysis environment. Figure 11 shows the complete malware activity flow chart.


Figure 11: Malware activity flow chart

Analysis of NSIS Loader (SmokeLoader)

The first payload dropped by the RIG EK is a compiled NSIS executable famously known as SmokeLoader. Apart from NSIS files, the payload has two components: a DLL, and a data file (named β€˜kumar.dll’ and β€˜abaram.dat’ in our analysis case). The DLL has an export function that is invoked by the NSIS executable. This export function has code to read and decrypt the data file, which yields the second stage payload (a portable executable file).

The DLL then spawns itself (dropper) in SUSPENDED_MODE and injects the decrypted PE using process hollowing.

Analysis of Injected Code (Second Stage Payload)

The second stage payload is a highly obfuscated executable. It consists of a routine that decrypts a chunk of code, executes it, and re-encrypts it.

At the entry point, the executable contains code that checks the OS major version, which it extracts from the Process Environment Block (PEB). If the OS version value is less than 6 (prior to Windows Vista), the executable terminates itself. It also contains code that checks whether the executable is in debugged mode, which it extracts from offset 0x2 of the PEB. If the BeingDebugged flag is set, the executable terminates itself.

The malware also implements an Anti-VM check by opening the registry key HKLM\SYSTEM\ControlSet001\Services\Disk\Enum with value 0.

It checks whether the registry value data contains any of the strings: vmware, virtual, qemu, or xen. Β Each of these strings is indictative of virtual machines

After running the anti-analysis and environment check, the malware starts executing the core code to perform the malicious activity.

The malware uses the PROPagate injection method to inject and execute the code in a targeted process. The PROPagate method is similar to the SetWindowLong injection technique. In this method, the malware uses the SetPropA function to modify the callback for UxSubclassInfo and cause the remote process to execute the malicious code.

This code injection technique only works for a process with lesser or equal integrity level. The malware first checks whether the integrity of the current running process is medium integrity level (2000, SECURITY_MANDATORY_MEDIUM_RID). Figure 12 shows the code snippet.


Figure 12: Checking integrity level of current process

If the process is higher than medium integrity level, then the malware proceeds further. If the process is lower than medium integrity level, the malware respawns itself with medium integrity.

The malware creates a file mapping object and writes the dropper file path to it and the same mapping object is accessed by injected code, to read the dropper file path and delete the dropper file. The name of the mapping object is derived from the volume serial number of the system drive and a XOR operation with the hardcoded value (Figure 13).

File Mapping Object Name = β€œVolume Serial Number” + β€œVolume Serial Number” XOR 0x7E766791


Figure 13: Creating file mapping object name

The malware then decrypts the third stage payload using XOR and decompresses it with RTLDecompressBuffer. The third stage payload is also a PE executable, but the author has modified the header of the file to avoid it being detected as a PE file in memory scanning. After modifying several header fields at the start of decrypted data, we can get the proper executable header (Figure 14).


Figure 14: Injected executable without header (left), and with header (right)

After decrypting the payload, the malware targets the shell process, explorer.exe, for malicious code injection. It uses GetShellWindow and GetWindowThreadProcessId APIs to get the shell window’s thread ID (Figure 15).


Figure 15: Getting shell window thread ID

The malware injects and maps the decrypted PE in a remote process (explorer.exe). It also injects shellcode that is configured as a callback function in SetPropA.

After injecting the payload into the target process, it uses EnumChild and EnumProps functions to enumerate all entries in the property list of the shell window and compares it with UxSubclassInfo

After finding the UxSubclassInfo property of the shell window, it saves the handle info and uses it to set the callback function through SetPropA.

SetPropA has three arguments, the third of which is data. The callback procedure address is stored at the offset 0x14 from the beginning of data. Malware modifies the callback address with the injected shellcode address (Figure 16).


Figure 16: Modifying callback function

The malware then sends a specific message to the window to execute the callback procedure corresponding to the UxSubclassInfo property, which leads to the execution of the shellcode.

The shellcode contains code to execute the address of the entry point of the injected third stage payload using CreateThread. It then resets the callback for SetPropA, which was modified by malware during PROPagate injection. Figure 17 shows the code snippet of the injected shellcode.


Figure 17: Assembly view of injected shellcode

Analysis of Third Stage Payload

Before executing the malicious code, the malware performs anti-analysis checks to make sure no analysis tool is running in the system. It creates two infinitely running threads that contain code to implement anti-analysis checks.

The first thread enumerates the processes using CreateToolhelp32Snapshot and checks for the process names generally used in analysis. It generates a DWORD hash value from the process name using a custom operation and compares it with the array of hardcoded DWORD values. If the generated value matches any value in the array, it terminates the corresponding process.

The second thread enumerates the windows using EnumWindows. It uses GetClassNameA function to extract the class name associated with the corresponding window. Like the first thread, it generates a DWORD hash value from the class name using a custom operation and compares it with the array of hardcoded DWORD values. If the generated value matches any value in the array, it terminates the process related to the corresponding window.

Other than these two anti-analysis techniques, it also has code to check the internet connectivity by trying to reach the URL: www.msftncsi[.]com/ncsi.txt.

To remain persistent in the system, the malware installs a scheduled task and a shortcut file in %startup% folder. The scheduled task is named β€œOpera Scheduled Autoupdate {Decimal Value of GetTickCount()}”.

The malware then communicates with the malicious URL to download the final payload, which is a Monero miner. It creates a MD5 hash value using Microsoft CryptoAPIs from the computer name and the volume information and sends the hash to the server in a POST request. Figure 18 shows the network communication.


Figure 18: Network communication

The malware then downloads the final payload, the Monero miner, from the server and installs it in the system.

Conclusion

Although we have been observing a decline in Exploit Kit activity, attackers are not abandoning them altogether. In this blog post, we explored how RIG EK is being used with various exploits to compromise endpoints. We have also shown how the NSIS Loader leverages the lesser known PROPagate process injection technique, possibly in an attempt to evade security products.

FireEye MVX and the FireEye Endpoint Security (HX) platform detect this attack at several stages of the attack chain.

Acknowledgement

We would like to thank Sudeep Singh and Alex Berry for their contributions to this blog post.

Fake Software Update Abuses NetSupport Remote Access Tool

5 April 2018 at 15:00

Over the last few months, FireEye has tracked an in-the-wild campaign that leverages compromised sites to spread fake updates. In some cases, the payload was the NetSupport Manager remote access tool (RAT). NetSupport Manager is a commercially available RAT that can be used legitimately by system administrators for remotely accessing client computers. However, malicious actors are abusing this application by installing it to the victims’ systems without their knowledge to gain unauthorized access to their machines. This blog details our analysis of the JavaScript and components used in instances where the identified payload was NetSupport RAT.

Infection Vector

The operator behind these campaigns uses compromised sites to spread fake updates masquerading as Adobe Flash, Chrome, and FireFox updates. When users navigate to the compromised website, the malicious JavaScript file is downloaded, mostly from a DropBox link. Before delivering the payload, the JavaScript sends basic system information to the server. After receiving further commands from the server, it then executes the final JavaScript to deliver the final payload. In our case, the JavaScript that delivers the payload is named Update.js, and it is executed from %AppData% with the help of wscript.exe. Figure 1 shows the infection flow.


Figure 1: Infection Flow

In-Depth Analysis of JavaScript

The initial JavaScript file contains multiple layers of obfuscation. Like other malicious scripts, the first layer has obfuscation that builds and executes the second layer as a new function. The second layer of the JavaScript contains the dec function, which is used to decrypt and execute more JavaScript code. Figure 2 shows a snapshot of the second layer.


Figure 2: Second Layer of Initial JavaScript File

In the second JavaScript file, the malware author uses a tricky method to make the analysis harder for reverse engineers. The author uses the caller and callee function code to get the key for decryption. During normal JavaScript analysis, if an analyst finds any obfuscated script, the analyst tries to de-obfuscate or beautify the script for analysis. JavaScript beautification tools generally add line breaks and tabs to make the script code look better and easier to analyze. The tools also try to rename the local variables and remove unreferenced variables and code from the script, which helps to analyze core code only.

But in this case, since the malware uses the caller and callee function code to derive the key, if the analyst adds or removes anything from the first or second layer script, the script will not be able to retrieve the key and will terminate with an exception. The code snippet in Figure 3 shows this trick.


Figure 3: Anti-Analysis Trick Implemented in JavaScript (Beautified Code)

The code decrypts and executes the JavaScript code as a function. This decrypted function contains code that initiates the network connection. In the decoded function, the command and control (C2) URL and a value named tid are hard-coded in the script and protected with some encoded function.

During its first communication to the server, the malware sends the tid value and the current date of the system in encoded format, and waits for the response from the server. It decodes the server response and executes the response as a function, as shown in Figure 4.


Figure 4: Initial Server Communication and Response

The response from the server is JavaScript code that the malware executes as a function named step2.

The step2 function uses WScript.Network and Windows Management Instrumentation(WMI) to collect the following system information, which it then encodes and sends to the server:

Architecture, ComputerName, UserName, Processors, OS, Domain, Manufacturer, Model, BIOS_Version, AntiSpywareProduct, AntiVirusProduct, MACAddress, Keyboard, PointingDevice, DisplayControllerConfiguration, ProcessList;

After sending the system information to the server, the response from the server contains two parts: content2 and content3.

The script (step2 function) decodes both parts. The decoded content3 part contains the function named as step3, as shown in Figure 5.


Figure 5: Decrypting and Executing Response step3

The step3 function contains code that writes decoded content2 into a %temp% directory as Update.js. Update.js contains code to download and execute the final payload. The step3 function also sends the resulting data, such as runFileResult and _tempFilePath, to the server, as shown in Figure 6.


Figure 6: Script to Drop and Execute Update.js

The Update.js file also contains multi-layer obfuscation. After decoding, the JavaScript contains code to drop multiple files in %AppData%, including a 7zip standalone executable (7za.exe), password-protected archive (Loglist.rtf), and batch script (Upd.cmd). We will talk more about these components later.

JavaScript uses PowerShell commands to download the files from the server. It sets the attribute’s execution policy to bypass and window-style to hidden to hide itself from the end user.

Components of the Attack

Figure 7 shows the index of the malicious server where we have observed the malware author updating the script content.


Figure 7: Index of Malicious Server

  • 7za.exe: 7zip standalone executable
  • LogList.rtf: Password-protected archive file
  • Upd.cmd: Batch script to install the NetSupport Client
  • Downloads.txt: List of IPs (possibly the infected systems)
  • Get.php: Downloads LogList.rtf
Upd.cmd

This file is a batch script that extracts the archive file and installs the remote control tool on the system. The script is obfuscated with the variable substitution method. This file was regularly updated by the malware during our analysis.

After de-obfuscating the script, we can see the batch commands in the script (Figure 8).


Figure 8: De-Obfuscated Upd.cmd Script

The script performs the following tasks:

  1. Extract the archive using the 7zip executable with the password mentioned in the script.
  2. After extraction, delete the downloaded archive file (loglist.rtf).
  3. Disable Windows Error Reporting and App Compatibility.
  4. Add the remote control client executable to the firewall’s allowed program list.
  5. Run remote control tool (client32.exe).
  6. Add Run registry entry with the name β€œManifestStore” or downloads shortcut file to Startup folder.
  7. Hide the files using attributes.
  8. Delete all the artifacts (7zip executable, script, archive file).

Note: While analyzing the script, we found some typos in the script (Figure 9). Yes, malware authors make mistakes too. This script might be in beta phase. In the later version of script, the author has removed these typos.


Figure 9: Registry Entry Bloopers

Artifact Cleaning

As mentioned, the script contains code to remove the artifacts used in the attack from the victim’s system. While monitoring the server, we also observed some change in the script related to this code, as shown in Figure 10.


Figure 10: Artifact Cleaning Commands

The highlighted command in one of the variants indicates that it might drop or use this file in the attack. The file could be a decoy document.

Persistence Mechanism

During our analysis, we observed two variants of this attack with different persistence mechanisms.

In the first variant, the malware author uses a RUN registry entry to remain persistent in the system.

In the second variant, the malware author uses the shortcut file (named desktop.ini.lnk), which is hosted on the server. It downloads the shortcut file and places it into the Startup folder, as shown in Figure 11.


Figure 11: Downloading Shortcut File

The target command for the shortcut file points to the remote application β€œclient32.exe,” which was dropped in %AppData%, to start the application on startup.

LogList.rtf

Although the file extension is .rtf, the file is actually a 7zipped archive. This archive file is password-protected and contains the NetSupport Manager RAT. The script upd.cmd contains the password to extract the archive.

The major features provided by the NetSupport tool include:

  • Remote desktop
  • File transfer
  • Remote inventory and system information
  • Launching applications in client’s machine
  • Geolocation
Downloads.txt

This file contains a list of IP addresses, which could be compromised systems. It has IPs along with User-agent. The IP addresses in the file belong to various regions, mostly the U.S., Germany, and the Netherlands.

Conclusion

RATs are widely used for legitimate purposes, often by system administrators. However, since they are legitimate applications and readily available, malware authors can easily abuse them and sometimes can avoid user suspicion as well.

The FireEye HX Endpoint platform successfully detects this attack at the initial phase of the attack cycle.

Acknowledgement

Thanks to my colleagues Dileep Kumar Jallepalli, Rakesh Sharma and Kimberly Goody for their help in the analysis.

Indicators of Compromise

Registry entries

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run : Β ManifestStore

HKCU\Software\SeX\KEx

Files

%AppData%\ManifestStore\client32.exe

%AppData%\ManifestStore\client32.ini

%AppData%\ManifestStore\HTCTL32.DLL

%AppData%\ManifestStore\msvcr100.dll

%AppData%\ManifestStore\nskbfltr.inf

%AppData%\ManifestStore\NSM.ini

%AppData%\ManifestStore\NSM.LIC

%AppData%\ManifestStore\nsm_vpro.ini

%AppData%\ManifestStore\pcicapi.dll

%AppData%\ManifestStore\PCICHEK.DLL

%AppData%\ManifestStore\PCICL32.DLL

%AppData%\ManifestStore\remcmdstub.exe

%AppData%\ManifestStore\TCCTL32.DLL

%AppData%\systemupdate\Whitepaper.docx

Shortcut file

Β Β Β Β Β Β Β Β Β Β Β  %AppData%\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\desktop.ini.lnk

Firewall program entry allowing the following application

Β Β Β Β Β Β Β Β Β Β Β  %AppData%\ManifestStore\client32.exe

Running process named β€œclient32.exe” from the path β€œ%AppData%\ManifestStore\client32.exe”

Hashes

The following hashes are JavaScript files that use the same obfuscation techniques described in the blog:

fc87951ae927d0fe5eb14027d43b1fc3

e3b0fd6c3c97355b7187c639ad9fb97a

a8e8b2072cbdf41f62e870ec775cb246

6c5fd3258f6eb2a7beaf1c69ee121b9f

31e7e9db74525b255f646baf2583c419

065ed6e04277925dcd6e0ff72c07b65a

12dd86b842a4d3fe067cdb38c3ef089a

350ae71bc3d9f0c1d7377fb4e737d2a4

c749321f56fce04ad8f4c3c31c7f33ff

c7abd2c0b7fd8c19e08fe2a228b021b9

b624735e02b49cfdd78df7542bf8e779

5a082bb45dbab012f17120135856c2fc

dc4bb711580e6b2fafa32353541a3f65

e57e4727100be6f3d243ae08011a18ae

9bf55bf8c2f4072883e01254cba973e6

20a6aa24e5586375c77b4dc1e00716f2

aa2a195d0581a78e01e62beabb03f5f0

99c7a56ba04c435372bea5484861cbf3

8c0d17d472589df4f597002d8f2ba487

227c634e563f256f396b4071ffda2e05

ef315aa749e2e33fc6df09d10ae6745d

341148a5ef714cf6cd98eb0801f07a01

❌
❌