This blog post was authored by @hasherezade and Jérôme Segura.
We recently detected a drive-by download attack trying to exploit CVE-2018-4878, a vulnerability in Flash Player, in a sequence that was not matching any of the exploit kit patterns that we currently track. Upon investigation, we discovered something that was new to us, but is part of an existing exploitation framework referenced in late 2017 by Chinese security firm Qihoo360. At the time, the payload appeared to be a Trojan pushing adware. (Note: On July 26, our colleagues from TrendMicro published a blog post calling it the Underminer exploit kit).
Since it was last documented, there have been changes to the exploits being used, although the distribution method is similar. One interesting aspect that we don’t see much of these days is the use of encryption to package exploits on-the-fly, which requires a key from the backend server to decrypt and execute them.
The payload served in this campaign is also out of the ordinary because it is not a standard PE file. Instead, it is a multiple-stage custom executable format, acting also as a downloader to retrieve LUA scripts used by the threat actors behind the Hidden Bee miner botnet. This was perhaps the first case of a bootkit being used to enslave machines mining cryptocurrencies.
The attackers are leveraging malvertising via adult sites to redirect their victims to the exploit kit landing page. We believe this campaign is primarily targeting Asian countries based on the ads that are served and our own telemetry data. A server purporting to be an online dating service contains a malicious iframe responsible for the exploitation and infection phases.
With a few exceptions, exploit kits typically obfuscate their landing page and exploits. But here the threat actors go beyond by using encryption and requiring a key exchange with the backend server in order to decrypt and execute the exploit. In the past, Angler, Nuclear and Astrum exploit kits have abused the Diffie-Hellman key exchange protocol in similar ways to prevents analysts from replaying malicious traffic.
The execution of the malicious code starts from a webpage with an embedded encrypted block. This block is Base64 encoded and encrypted with one of two algorithms: RC4 or Rabbit.
After being decrypted, the block is executed. You can find the decoded version of the Java Script that is being run here. As you can see in the script, it generates a random session key, then encrypts it with the attacker’s public RSA key:
The encrypted key is being passed onto the next function and converted into JSON format to perform a POST request to the hardcoded URL:
This is what we can see if we look at the traffic between the client and the server (the client sends the encrypted “key” and the server responds with the “value”):
- With the attackers’ private RSA key, the server decrypts the passed session key.
- It uses it to encrypt the exploit content with a chosen symmetric algorithm (Rabbit or RC4).
- It returns the encrypted content back to the client.
Thanks to the fact that the client still has an unencrypted version of the key in memory, it is able to decrypt and execute the exploit. However, researchers who just have the traffic captured cannot retrieve the original session key, and replaying the exploit is impossible. Thankfully, we managed to capture the exploit during dynamic analysis.
We believe that the decrypted exploit is CVE-2018-8174, as one of our test machines patched against CVE-2016-0189 got exploited successfully.
This newer Flash exploit (CVE-2018-4878) was not part of the exploit toolkit at the time Qihoo documented it, and seems to be a more recent addition to boost its capabilities. The shellcode embedded in the exploit is a downloader for the next stage.
Upon successful exploitation, it will retrieve its payload at the following URL:
This file, given the extension .wasm, pretends to be a Web Assembler module. But in fact, it is something entirely different, appearing to be a custom executable format, or a modified, header-less PE file.
It starts from the names of the DLLs that are going to be needed during the execution:
As you can see, it loads Cabinet.dll that is used for unpacking cabinet files. In later sections, we saw the APIs and strings that are used for the communication over HTTP protocol. We also found references to “dllhost.exe” and “bin/i386/core.sdb”.
It is easy to guess that this module will be downloading something and running via dllhost.exe.
Another interesting string is a Base64-encoded content:
The decoded content points to more URLs:
http://188.8.131.52/git/wiki.asp?id=530475f52527a9ae1813d529653e9501 http://184.108.40.206/git/glfw.wasm http://220.127.116.11/rt/lsv3i06rrmcu491c3tv82uf228.wasm
Looking at the traffic captured by Fiddler, we found that, indeed, those URLs are being queried:
The requests are coming from dllhost.exe, so that means the above executable was injected there.
The file glfw.wasm has nothing in common with Web Assembly. It is, in fact, a Cabinet file, containing packed content under the internal path: bin/i386/core.sdb. Looking inside, we found the same custom executable format, starting from DLL names:
Then, HTTP traffic stops. This was another interesting aspect of this threa,t because the threat actors are perhaps trying to hide the traffic by pretending to use the SLTP protocol to retrieve the actual payload, which can be seen in the strings extracted from the Cabinet file inside of core.sdb:
INSTALL_SOURCE &sid=%u INSTALL_SID INSTALL_CID sltp://setup.gohub[.]online:1108/setup.bin?id=128 ntdll.dll ZwQueryInformationProcess VolumeNumber SCSIDISK os=%d&ar=%d kernel32.dll IsWow64Process RtlGetNtVersionNumbers %02x &sz= sltp
That hostname resolves to 67.198.208[.]110:
Pinging setup.gohub.online [18.104.22.168] with 32 bytes of data: Reply from 22.214.171.124: bytes=32 time=76ms TTL=51
Encrypted TCP network traffic from our sandboxed machine shows how the binary payload is retrieved:
This whole exploitation and payload retrieval process is rather complex, especially in light of the intended purpose behind this drive-by campaign. Infected hosts are instructed to mine for cryptocurrencies:
What is unique about this miner is that it achieves persistence by using a bootkit, as described here. Infected hosts will have their Master Boot Record altered to start the miner every time the operating system boots.
A sophisticated attack for a simple payload
This attack is interesting on many levels for its use of different technologies both in the exploit delivery part as well as how the payload is packaged. According to our telemetry, we believe it is also focused on a select few Asian countries, which makes sense when taking its payload into consideration.
It also shows that threat actors haven’t completely given up on exploit kits, despite a noted downward trend over the last couple of years.
Malwarebytes detects both the IE and Flash exploits, resulting in the infection chain being stopped early on.
Indicators of compromise
Injected dating site
Payload URL and IP