Auteur Sujet: [FireEye]RIG Exploit Kit Delivering Monero Miner Via PROPagate Injection Technique  (Lu 2751 fois)

0 Membres et 1 Invité sur ce sujet

Hors ligne igor51

  • Admin
  • Mega Power Members
  • *****
  • Messages: 10419
RIG Exploit Kit Delivering Monero Miner Via PROPagate Injection Technique

[html]

Introduction


 

Through FireEye Dynamic Threat Intelligence (DTI), we observed RIG
  Exploit Kit (EK) delivering a dropper that leverages the     href="http://www.hexacorn.com/blog/2017/10/26/propagate-a-new-code-injection-trick/">PROPagate
    injection technique to inject code that downloads and executes a
  Monero miner (similar activity has been reported by     href="https://blog.trendmicro.com/trendlabs-security-intelligence/rig-exploit-kit-now-using-cve-2018-8174-to-deliver-monero-miner/">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   href="https://www.fireeye.com/blog/threat-research/2016/07/exploit_kits_quickly.html">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   href="https://www.fireeye.com/blog/threat-research/2015/08/cve-2015-2419_inte.html">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   href="https://www.fireeye.com/blog/threat-research/2018/02/attacks-leveraging-adobe-zero-day.html">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.


Tags: