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 malware-traffic-analysis.net.
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'”
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:
- hxxp://hco[.]huc[.]mobi/7/?9643522803
- hxxp://hco[.]huc[.]mobi/7/?947545190441&id=265
- 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:
References
http://www.malware-traffic-analysis.net/2017/01/19/index3.html
https://blog.malwarebytes.com/cybercrime/exploits/2016/10/yet-another-sundown-ek-variant/
https://www.fireeye.com/blog/threat-research/2016/05/cve-2016-4117-flash-zero-day.html
http://binaryhax0r.blogspot.co.il/2016/09/rig-exploit-kit-shellcode-spwans.html
http://www.nao-sec.org/2017/05/analyzing-rig-exploit-kit-vol2.html
http://contagiodump.blogspot.co.il/2012/05/may-3-cve-2012-0779-world-uyghur.html
