Since mid-September 2015, I've generated a great deal of Nuclear exploit kit (EK) traffic after checking compromised websites. This summer, I usually found Angler EK. Now I'm seeing more Nuclear.
Nuclear EK has also been sending dual payloads. I documented dual payloads at least three times last year [1, 2, 3], but I hadn't noticed it again from Nuclear EK until recently. This time, one of the payloads appears to be ransomware. I saw Filecoder on 2015-09-18  and TeslaCrypt 2.0 on 2015-09-29 . In both cases, ransomware was a component of the dual payloads from Nuclear EK.
To be clear, Nuclear EK isn't always sending two payloads, but I've noticed a dual payload trend with this recent increase in Nuclear EK traffic.
Furthermore, on Wednesday 2015-09-30, the URL pattern for Nuclear EK's landing page changed. With that in mind, let's take a look at what's happening with Nuclear.
The images below show some examples of URL patterns for Nuclear EK since 2015-09-15:
In the above images, the initial HTTP GET request always starts with /search?q= for the landing page URL. That changed on Wednesday 2015-09-30.
The initial HTTP GET request now starts with /url?sa= instead of /search?q= for the landing page URL. I saw the same thing from three different examples of Nuclear EK on 2015-09-30. Windows hosts from these examples all had the exact same configuration.
Nuclear EK examples from 2015-09-30
I had some trouble infecting a Windows 7 host running IE 11. The browser always crashed before the EK payload was sent. So I tried three different configurations to generate traffic for this diary. The first run had a Windows 7 host running IE 10. The second run had a Windows 7 host runnining IE 8. The third run had a Windows 7 host running IE 11. All hosts were running outdated versions of Flash player.
I found a compromised website with an injected iframe leading to Nuclear EK. The screenshot below shows an example of the malicious script at the bottom of the page. It's right before the closing body and HTML tags. You'll see many empty lines before the malicious iframe.
The first run used IE 10 with Flash player 126.96.36.199. After the host was infected, the following image was set as the Windows desktop background:
Decrypt instructions were left as a text file on the desktop. The authors behind this ransomware used email@example.com and firstname.lastname@example.org as email addresses for further decryption instructions.
Playing around with the pcap in Wireshark, I got a decent representation of the traffic. Below, you'll see the compromised website, Nuclear EK on 188.8.131.52, and some of the post infection traffic. TLS activity on ports 443 and 9001 with random characters for the server names is Tor traffic. Several other attempted TCP connections can be found in the pcap, but none of those were successful, and they're not shown below. In addition to the two payloads, I found a third piece of malware on the infected host.
For the second run, I infected a different Windows host running IE 8 and Flash player 184.108.40.206. This generated Nuclear EK from from the same IP address and a slightly different domain name. Post-infection traffic was similar; however, I did't see the same traffic that triggered Kovter.B alerts from the first run.
For the third run, I used a Windows host with IE 11 and Flash player 220.127.116.11. As mentioned earlier, the browser would crash before the EK sent the payload, so this host didn't get infected with malware. I tried it once with Flash player and once without Flash player, both times running an unpatched version of IE 11. Each time, the browser crashed. Nuclear EK was still using the same IP address, but different domain names were different. Within a 4 minute time span on the pcap, you'll find a different top-level domain (TLD) from Nuclear EK on 18.104.22.168.
To get a better look at Nuclear EK, see the screen shots below from the first run.
Other than the landing page URL pattern and dual payload, Nuclear EK looks remarkably similar to the last time we reviewed it in August 2015 .
Preliminary malware analysis
The first and second runs generated a full infection chain and post-infection traffic. The malware payload was the same during the first and second run. The first run had additional malware on the infected host. The third run using IE 11 didn't generate any malware payload.
Nuclear EK malware payload 1 of 2:
Nuclear EK malware payload 2 of 2:
Additional malware recovered from the infected host (first run only):
Like other EKs, Nuclear EK keeps evolving. We will continue to keep an eye on the situation and let you know of any significant developments.
Packet captures of the 2015-09-30 Nuclear EK traffic are available at:
A zip archive of the associated malware and artifacts is available at:
The zip archives are password-protected with the standard password. If you don't know it, email email@example.com and ask.
Oct 1st 2015
3 years ago