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.
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
Stage 1 – Start of infection chain
From here, I will try to analyze each payload execution, possible exploits triggered, URLs accessed and any additional payloads and/or Shellcode.
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.
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:
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 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:
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.
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.