Recent trends in Nuclear Exploit Kit activity

Published: 2015-10-01. Last Updated: 2015-10-01 00:02:01 UTC
by Brad Duncan (Version: 1)

Introduction

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 [4] and TeslaCrypt 2.0 on 2015-09-29 [5]. 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.

URL patterns

The images below show some examples of URL patterns for Nuclear EK since 2015-09-15:

Shown above: Some URLs from Nuclear EK on 2015-09-15. Pcap available here.

Shown above: Some URLs from Nuclear EK on 2015-09-16. Pcap available here.

Shown above: Some URLs from Nuclear EK on 2015-09-18. Pcap available here.

Shown above: Some URLs from Nuclear EK on 2015-09-22. Pcap available here.

Shown above: Some URLs from Nuclear EK on 2015-09-29. Pcap available here.

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.

Shown above: Some URLs from Nuclear EK on 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.

Shown above: Malicious code on a page from the compromised website.

The first run used IE 10 with Flash player 14.0.0.125. After the host was infected, the following image was set as the Windows desktop background:

Shown above: Desktop background from the infected host.

Decrypt instructions were left as a text file on the desktop. The authors behind this ransomware used decode010@gmail.com and decode1110@gmail.com as email addresses for further decryption instructions.

Shown above: Decryption instructions from the ransomware.

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.226.215.37, 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.

Shown above: Some of the infection traffic from the pcap in Wireshark (from a Windows host using IE 10 and Flash player 14.0.0.125).

Below are alerts on the infection traffic when I used tcpreplay on Security Onion with the EmergingThreats (ET) and ET Pro signature sets on 2015-09-30 at approximately 19:00 UTC.

Shown above: Alerts from the traffic using Sguil in Security Onion.

For the second run, I infected a different Windows host running IE 8 and Flash player 11.2.202.228. 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.

Shown above: Nuclear EK traffic using IE 8 and Flash player 11.2.202.228.

For the third run, I used a Windows host with IE 11 and Flash player 18.0.0.203. 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 188.226.215.37.

Shown above: Nuclear EK traffic using IE 11 and Flash player 18.0.0.203... Tried twice but no payload was sent.

To get a better look at Nuclear EK, see the screen shots below from the first run.

Shown above: Nuclear EK landing page.

Shown above: Nuclear EK sends a Flash exploit.

Shown above: Nuclear EK sends the first malware payload.

Shown above: Nuclear EK sends the second malware payload.

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 [6].

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: