Nuclear EK traffic patterns in August 2015

Published: 2015-08-05
Last Updated: 2015-08-05 11:54:37 UTC
by Brad Duncan (Version: 1)
3 comment(s)


About two weeks ago, Nuclear exploit kit (EK) changed its URL patterns.  Now it looks a bit like Angler EK.  Kafeine originally announced the change on 2015-07-21 [1], and we collected examples the next day.

Here's how Nuclear EK looked on 2015-07-20 [2]:

Here's how Nuclear EK appeared two days later on 2015-07-22 after the change [1]:

Now that we're into August 2015, URL patterns for Nuclear EK have altered again.  These changes are similar to what we've seen with Angler EK since June 2015 [3].  They're not the same URL patterns as Angler, but the changes are similar.

In today's diary, we examine Nuclear EK traffic as of Tuesday, 2015-08-04.  In this example, the EK delivered Troldesh ransomware, which is similar to a previous infection I published earlier this year in April 2015 [4].

First, let's see how the 2015-08-04 traffic from a compromised website led to Nuclear EK.

From a compromised web site to the EK

I viewed the compromised website by getting to it through a Bing search, which is my preferred method for generating EK traffic.  Google had already identified the site as potentially malicious and wouldn't let me get to it from their search engine.

Malicious javascript was injected in at least 4 places when I visited the site's index page.  The script is obfuscated, so you won't see any obvious URLs.   I've highlighted two examples below.

The same type of malicious script was also present in one of the .js files from another HTTP GET request.

What's the easiest way to deobfuscate the script?  Copy and paste the script into its own HTML file, make sure you've got HTML and body tags, then change the document.write to alert (see the image below).

Open the resulting web page in a browser, and you should see an alert showing the deobfuscated script.  From the above example, we find a hidden iframe that goes to

The follow-up HTTP GET request returns a redirect to the Nuclear EK landing page.

With any EK, this all happens behind the scenes.  The average user won't know what happened until it's too late.  With ransomware, users will realize something's wrong when a message comes up saying their important files have been encrypted.

Shown above:  The infected host's desktop after the Troldesh ransomware infection.

A look at the Nuclear EK traffic

On 2015-07-21 when Nuclear changed, each GET request from the EK started with search?q=.  URL patterns remained that way through at least 2015-07-30 [5].  A few days later, the landing page URL still contains search?q=.  However, other URLs for the Flash exploit and payload use different words.  They also follow a different pattern after the question mark (?) up to the equal sign (=).  Below shows our example of Nuclear EK from 2015-08-04 (the landing page URL is sent twice).

In the 2015-08-04 traffic, Nuclear EK's landing page has some text before the initial HTML tag.  This is something we hadn't noticed before in Nuclear.

Except for the change in the URL pattern, this HTTP GET request for the EK's Flash exploit is similar to what we've seen before.

Nuclear EK still uses an ASCII string to XOR the payload binary.  This started with Nuclear's previous change of URL patterns back in December 2014 [6], and it remains the EK's method for hiding its payload.

Review the infection traffic using Security Onion with the EmergingThreats signature set, and you'll find events related to Nuclear EK, Tor traffic, and Troldesh malware.

Additional information from the infected host

Filtering the traffic in Wireshark, we see SSL activity to over port 443 and over port 995.  Although this traffic is related to the Troldesh ransomware, those IP addresses are not inherently malicious.  EmergingThreats signature hits indicate these are nodes for Tor traffic (see the previous image).

The README text files from the desktop were identical.  They all had the same message in Russian and English:

All the important files on your computer were encrypted.
To decrypt the files you should send the following code:
to e-mail address or .
Then you will receive all necessary instructions.
All the attempts of decryption by yourself will result only in irrevocable loss of your data.

Hey, Google.  Someone is using Gmail accounts for nefarious purposes.  Bet you haven't seen that before!  Ah, free services...  A cyber-criminal's delight!

Final words

In recent months, we've seen a lot of ransomware from EK traffic.  This has been primarily (but not limited to) Angler, Magnitude, and Nuclear EK.  Most of the ransomware has been CryptoWall 3.0 [7], but every once in a while, we'll see something like AlpaCrypt/TeslaCrypt [8] or Toldesh [4].  We'll continue to monitor EK traffic and post any significant changes.

A pcap of the 2015-08-04 Nuclear EK infection traffic is available at:

A zip file of the associated malware is available at:

The zip file is password-protected with the standard password.  If you don't know it, email and ask.

Brad Duncan
ISC Handler and Security Researcher at Rackspace
Blog: - Twitter: @malware_traffic



3 comment(s)


Not a very ringing endorsement of Bing, that you go there when you want to get attacked...
Thanks, John! I was wondering if anyone would comment about that. On a serious note, say what you will about Bing, but at least Bing gives you a choice. Bing will warn you about a compromised website, but it gives you an option to get to that site, if needed. Google just blocks the links from their search results. Google doesn't give you any choice in the matter. The situation is less than ideal when doing this type of research.
Google should consider provisioning means to display unsecure sites as an OPT-IN capability. That would be a great assist for system managers/owners to determine possible reasons why some sites show up in normal (filtered) searches and some do not due to malicious activity filters.

On another note... the random character DNS names just make me sick to my stomach.

Diary Archives