Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > Author: Daniel Frank

RSA NetWitness Platform

2 Posts authored by: Daniel Frank Employee

Sundown is an Exploit Kit that was popular towards the end of 2016 and had some evolvement in its variants and techniques, but altogether tends to steal code from other EKs. Its distribution was in specific regions, mainly in APJ region, when sources show us high distribution rates of its different variants in Japan, Korean and Taiwan.


The PCAP analyzed can be found in VirusTotal with the following hash: 995eba050390492ad99dc938f958746f and also in


Network Detection

We can identify Sundown’s network activity in RSA NetWitness Logs and Packets ® investigator with the following query, containing common regular expressions found in analyzed PCAPs:

“service = 80 && action = 'get' && query contains '51S3OjuWhdt3' || query contains 'xibsYziX18M' || query contains 'ZUyQpcQET20' || query contains '5yruNm' || query contains 'NgfAaoVnVjJAy9BBtrQj' || query contains '4Ca9YTf21PMMSC'”


App Rule


Let’s begin dissecting our PCAP. First we will see the general structure and flow, and then I will elaborate about each stage’s technical details.



Stage 0 – the landing page

The first part of redirecting the user to start the infection process will be placing a hidden iframe inside a legitimate html page. The iframe is simple and straightforward – it redirects the victim to the initial JavaScript returned by the EK’s gate and the landing page. This is the actual start of the infection process, what will be referred as Stage 1. It is worth to mention, that the iframe is very similar to what we can see in RIG, and might even been stolen from there.



Stage 1 – Start of infection chain

Upon successful redirection from to the landing page, no less than 4 different encrypted payloads (both VB and JavaScript) are loaded and executed one after another. As usual, the JavaScript containing the payloads in the html page is obfuscated, but this time not that heavily. Every payload is encoded with base64 and the string is reversed. In order to de-obfuscate it and see the real payload, all we have to do is to reverse the string, base64 decode it and then execute some more mathematical operations. This can be achieved by running the script in a browser’s debugging console, or even more easily, in python, which will allow “mass decryption” of such scripts without the need to execute the code each time. Finally, the payload will be written to the page and executed. The same routine repeats 4 times, whereas the only changes are the payload, hardcoded desired payload length and another constant number used for the mentioned above mathematical operations and decryption. All of the above, as we often see in other EKs, are used in order to avoid detection and make it harder to analyze.


From here, I will try to analyze each payload execution, possible exploits triggered, URLs accessed and any additional payloads and/or Shellcode.


Script 1

The script is written in VB and exploits IE9 – IE11 VBScript memory corruption vulnerability, CVE-2016-0189. This vulnerability allows the attacker to escape the browser’s sandbox and achieve “God Mode” by bypassing the “Safe Mode” flag and run VBScript as if it was executed by the shell of the machine running the browser. The use of this exploit, according to Malwarebytes, is a rip-off from RIG EK, exactly like the iframe in the landing page and the structure of the GET request follows.



In our analyzed script, after the initial obfuscated payload string is loaded, we can see some of the obfuscated functions used for its decryption.



Once we de-obfuscate and decrypt the 1st payload (out of 4), we receive a VBScript that will be loaded to the page and then executed. Let’s look at some key features of that script.


In the image below we can see the ‘fire()’ function, which is executed after the vulnerability was exploited and the previously mentioned sandbox escaping took place. It will load a URL and a key to be later used for the decryption of the final payload. Afterwards it will connect the malicious URL that was loaded and if it received a 200 status from the server (meaning the gate is online and the final payload can be downloaded) it will first save the downloaded payload to ‘z’ variable and later write it to disk, but also write a DLL (‘dllcode’ in the snippet below) to ‘TempSystem32’ folder, naming it ‘shell32.dll’.



It will then decrypt and do the actual writing of the downloaded final payload to disk to ‘%TMP%’ folder (using ‘GetSpecialFolder(2)’ function, where 2 indicates the temp folder that is also set as the %TMP% environment variable), decrypt it using ‘arcnsave’ function and the key “galiut” from the above image, and try to register it as the system variable %SysFileName%’.



In this script both the DLL and the downloaded payload are being written to disk, but neither of them are actually being executed, whereas if we run the DLL manually, we can see that its job is to execute the final payload after it was downloaded. Below we can see how it looks when manually running the DLL in a debugger. We can see that the relevant Windows API calls, in order to execute the downloaded malicious payload that was previously supposed to be set as %SysFileName%. It is done by using the command line and another Windows API call “CreateProcessAsUserW”. The below string is being sent to the function as the “lpCommandLine” parameter, and this is the command that will be executed in the security context of the current user’s token.



Script 2

The second decrypted payload contains several JavaScript functions that will eventually render various Flash files in order to trigger relevant exploits. Here are the first two functions, responsible for concatenating 2 strings and the browser’s user-agent header, separated by spaces and quotation marks, and finally returns the value in a hex string. 



So when we run ‘vbcvfd’ function, this is the result that we’ll get (separated by square brackets and ‘hxxp’ replaces ‘http’ for obvious reasons): 'galiut" "hxxp://hxrheg[.]fve[.]mobi/@@@.php?id=265" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0"\x00\x00\x00\x00'


In the following image we’ll see the 3rd and 4th function, together with calls to the first two functions, start rendering of the first Flash files.



The returned value from ‘vbcvfd’ function will be sent as a parameter to ‘iotug’ function together with another URL. In the following image we can see that the URL is being called in order to render a Flash file, and the returned value from ‘vbcvfd’ function is actually being set as parameters to the rendered flash movie.



Similar to the above, ‘fkhjkghg’ function will be executed, this time calling to a different file and not providing a second parameter, so it just renders another Flash file.



The final function we have here will render a 3rd Flash file and send a second parameter to it, this time it’s a straightforward shellcode to be executed by the rendered Flash file once exploited. Here is how it looks in the script itself:



And here is how it looks after running the function.  We can see similar code to the first 2, and here it’s even more straightforward. Render an exploitable Flash file and execute Shellcode.




The next stage will be going over the Flash files, categorizing the exploits in each one and Analyzing their payload. So, altogether we have 3 different rendered Flash files:

  1. hxxp://hco[.]huc[.]mobi/7/?9643522803
  2. hxxp://hco[.]huc[.]mobi/7/?947545190441&id=265
  3. hxxp://hco[.]huc[.]mobi/7/?78493521


Flash 1

Flash 1 comes with binary data that needs to be decoded. Here the ActionScript will xor each byte with the value in the last byte of the binary data, and modify it with each iteration by ‘+ 17 & 255’.



After unpacking it, we will see Flash 1 tries to exploit vulnerability CVE-2016-4117 that uses a memory read vulnerability in ‘DeleteRangeTimelineOperations’ class to run embedded shellcode.



It will first load the relevant ‘urlmon.dll’ DLL using ‘LoadLibraryA’ function from kernel32.dll:



Afterwards it will load the download URL that is hardcoded in the binary and get the user’s ‘AppData\Local\Temp’ folder, where he will try to download and execute the payload, calling it “Temp.exe”, and finally terminate.



The extension of the requested file is ‘.php’, but the http request is GET. Here we can see how it looks when dynamically editing the URL to the host machine, in order to see the request:



A reasonable explanation for that will be trying to hide it’s true intentions. We can see clearly that this is a binary because of the ‘.exe’ extension and its execution with ‘WinExec:



Flash 2

Flash 2 is almost unpacked completely, with two small sections of binary data.  The payload will be first of all decrypted using a simple xor with the hardcoded key 0x84, xoring each byte with that value:



After loaded and decrypted, the next step will be to load the relevant kernel32 functions:



Finally, it will call ‘CreateProcessA’ function that will run the decrypted WScript:



Here is how the whole script looks like after extracting it:



It will try to download, decrypt and execute the final payload, writing it to the user’s temp folder, naming it ‘OTTYUADAF’ in this case, and finally deleting it after execution. The download URL and key are hardcoded in the JavaScript loading the Flash files. The same payload is also seems to be common across other exploit kits such as RIG.


Flash 3

Flash 3 has the same payload hardcoded as Flash 1, and with a packed and obfuscated Flash file. After trying to decrypt it with a Python script, the binary data decrypts to a zlib archive with the header ’78 DA’ which means the file was compressed with the maximum compression, but once trying to decompress it using Python, it seems that the length of the file created is wrong and we get an error trying to decrypt it. When looking for some strings, together with an analysis classification from VirusTotal, it seems the relevant CVE here might be CVE-2015-7645 that exploits type confusion vulnerability.


Script 3

The 3rd script is VBScript, loading another VBScript segment, when the 1st script exploiting CVE-2016-0189 and the 2nd one exploits CVE-2014-6332.



The 1st VBScript will write a file to user’s temp folder, calling it ‘mfgrehy.tmp’, and echo the second script to it. Afterwards, it will execute ‘wscript.exe’, providing it with the URL, key and UserAgent, download and decode the malware, and finally try to execute it.



Script 4

The 4th and final script is a JavaScript that uses Steganography to decrypt its malicious payload. It will first load a png hiding a malicious code inside, exploiting CVE-2015-2419 vulnerability, that is caused by a memory corruption in the Jscript9 engine that is used in Internet Explorer 10 and 11. Here we can see the beginning of the JS file:



After running the png decryption code in a browser’s debug console, we will see the decrypted JavaScript. As we can see it will try to execute the same payload we’ve seen in the analysis of the precious files:




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:

  1. 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’. 
  2. 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:

  1. The first function that obfuscates multiple strings in the script and version checking to see if the victim has the appropriate JavaScript version installed.
  2. The line triggering a JSON exploit.
  3. The shellcode.


So, let’s begin:

  1. 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. 
  2. 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
  3. 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, 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. 



Filter Blog

By date: By tag: