Although Rig EK is the dominant one in the market right now, our sources from the RSA FraudAction Intelligence team indicate that Magnitude EK is still being used by some private groups and not offered anymore for the wider community of fraudsters in the underground crimeware markets. This is an interesting fact, since it shows us that Magnitude EK is not yet to lose its relevancy; moreover – threat actors are using it privately for specific campaigns.
It’s important to note that although Magnitude EK, just as any other exploit kit, may be packed and shipped with a variety of exploits targeting various software components (usually tracked by CVE numbers, as long as the vulnerability had been previously reported and documented), additional EK related elements tend to be shared between many different gates, regardless of the exploited vulnerability or delivered malware variant.
These shared EK elements include the landing pages, JavaScript obfuscation method and shellcode delivered upon successful exploitation.
Security researchers tend to focus on the detection, analysis and dissection of these specific elements, as their presence in your network serves as a generic indication for malicious activity, regardless of the exploited software vulnerability which may vary significantly between different network configurations.
Today we chose to focus on a specific variant of Magnitude EK in order to demonstrate the shared behavior which we expect to find in additional variants.
The analyzed PCAP file can be found in VirusTotal using the following MD5 hash: 6129fee0eae386e8c5040a2e63c20f44.
Network Detection
You can see below how the malicious traffic looks in RSA NetWitness® Logs and Packets after applying the appropriate query. This query should be used only as a quick pivot to find malicious leads to investigate, then drill deeper to validate malicious activity, assuming the appropriate meta keys are enabled:
“service = 80 && action = 'get' && referer exists && filename regex '[0-9|a-z]{8,32}' && query contains 'win%20'”
Related indicators of compromise were added to Live, you can find them under the threat description: ‘magnitude-ek’.
In addition we will release a dedicated LUA parser for enhanced detection results.
Now let’s take a closer look under the hood of the Magnitude EK.
The Infection Chain
Stage 0
The first file loaded from the EK is a small obfuscated JavaScript which sends the screen color depth and dimensions to load the next file. It sends the details as parameters in a GET request and receives back the next stage.
Stage 1
The script retrieved in this stage contains a list of Kaspersky’s Virtual Keyboard Plugin API calls, iterates over them and tries to create an ActiveX object. In each iteration, if an object is successfully created, this indicates the product is installed on the victim’s computer, and a flag that holds the “object’s creation fail” Boolean value changes from ‘true’ to ‘false’. Finally, if the “object’s creation fail” was indeed set to ‘false’, stage 2 is called.
Stage 2
The second HTML has 2 main functionalities:
- A small Flash loader is being called and automatically executed. A classid object is created and the appropriate Flash file is loaded and afterwards played by assigning the relevant JavaScript tags: creating a Flash type object, setting the URL of the file that will be played and setting the ‘play’ value to ‘true’.
- An HTML page containing another JavaScript (stage 3) is being executed in an iframe.
Stage 2 Flash payload ActionScript:
The capabilities class is the most relevant library that’s loaded here. This class is for the ongoing communication with the gate, since this class can provide details about the system and runtime environment of the host application where the Flash file is being executed. Here, the ActionScript retrieves the Flash player’s platform and version and sends the information to another URL, to trigger the second Flash file that can be potentially exploited.
In the following image taken from Wireshark, we can see that Flash file being loaded by the small Flash loader whose ActionScript we saw earlier in stage 2. As mentioned, the newly downloaded Flash file can potentially trigger a Flash exploit in order to run malicious code and deliver the final payload:
JavaScript Analysis
The script loaded in stage 3 contains ~500 lines of code and of course is obfuscated. We will focus on some key points:
- The first function that obfuscates multiple strings in the script and version checking to see if the victim has the appropriate JavaScript version installed.
- The line triggering a JSON exploit.
- The shellcode.
So, let’s begin:
- The following function (kv9035r2o8) appears in several different ‘stage 3’ files. Each time the function converts an obfuscated string from Hex to ASCII by reading two chars at a time and using a different numeral system (here it’s base19). If we use the string shown below as an input we receive: ‘ScriptEngineBuildVersion’. A new window.ScriptEngineBuildVersion object will be created and variables will be updated with the version details. Afterwards, in several places in the script, relevant checks will be made, to make sure the JavaScript version ran by the browser is vulnerable for the exploit.
- Here we can see the arguments that will be passed to the JSON stringify function (when passing the below string to ‘kv9035r2o8’ we’ll get ‘stringify’) that later will be used to invoke CVE-2015-2419, just like in Angler EK described in FireEye’s blog.
- Below is a part of the obfuscated shellcode that will be executed upon successful exploitation of the vulnerability mentioned above. It will also first be passed to the same ‘kv9035r2o8’ function to deobfuscate the actual code.
Once we extract the shellcode and open it in IDA, we can see some interesting strings, such as a string that contains the command line that will execute the final payload and another that contains a gate URL:
Next, we will start debugging and single stepping through the code. Here are key steps inside the shellcode:
- Relevant WinAPIs, containing methods that will later be used to execute the shellcode, are being loaded to memory:
- Next, the URL string is being sent as a parameter to wininet.InternetOpenUrlA function that stored in EDI register. Finally, wininet.InternetOpenUrlA creates the internet connection, and when sniffing in Wireshark, we can actually see that call being made.
- The gate seems to be offline, so we can’t see the actual download of the payload. Nevertheless, we can dynamically edit the download URL and point it to the Apache server of the host machine where the payload that was downloaded from the PCAP is pre-stored.
- As stated in Hardik Suri’s analysis in malware-traffic-analysis.net, the payload is the CVE-2015-2426 exploit from hacking team. After the payload was successfully downloaded, it is stored in EDI register, by calling the function InternetReadFile.
- The shellcode then loads the next URL to download what seems to be the final payload, and the filename it will use in order to write and execute the downloaded file in the infected system. It then will start going over open processes and search a process to inject code into, most likely in order to download and execute the final payload from the injected process. In our case, the process is “taskhost.exe” that crashes.
- After the crash, we can see that the shellcode has a fallback mechanism and still, it will try to download the final payload.
- Then, save it in the current user’s temp folder as “a.exe” and execute it. In our case, “a.exe” will also crash. This will be done using the newly written binary from the command line, using WMI.
- Finally, the shellcode will try to redo the same process, and this time executes the downloaded malware as “b.exe” using PowerShell. Finally, after both have failed in our case, the shellcode will exit and terminate.
In conclusion, we see that this variant of Magnitude Exploit Kit has used several techniques and known vulnerabilities in order to achieve infection of the targeted machine and includes profiling prior to potential infection. Magnitude EK is not as dominant as before in public usage, but is still in use, mostly by private and closed groups of financially motivated cyber criminals.
References:
https://support.kaspersky.com/12945
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system/Capabilities.html
https://www.fireeye.com/blog/threat-research/2016/04/cve-2016-1019_a_new.html
https://www.fireeye.com/blog/threat-research/2015/08/cve-2015-2419_inte.html
https://www.proofpoint.com/us/threat-insight/post/killing-zero-day-in-the-egg
http://mcdermottcybersecurity.com/articles/windows-x64-shellcode
http://www.malware-traffic-analysis.net/2016/04/15/index.html
https://msdn.microsoft.com/en-us/library/windows/desktop/yftk84kt(v=vs.94).aspx
