Just over a week ago I sort of concluded that Neutrion only had Java exploits. But here someone prove me wrong and I must admit I had only checked with the "obvious" stuff that neutrino uses Plugin Detect for (Or the kit just evoled just after my writing?). So time to look once again into Neutrino and one of it's mysteries.

Get the landing

My referrer from two weeks ago was dead. The TDS was still up and working though so I had to find a valid referrer. Urlquery to the rescue. I found a Neutrino reference there which was still alive so here we go:

Lots of Javascript. Not just any Javascript. Exploit code that looks to me to be exploiting CVE-2013-2551. Thanks to @Rapid7 for reference within metasploit. Picture showing function lea() AKA exploit()

Epilogue

So the Neutrino EK has shown that it is more potent. Lets keep our eyes open and see if more exploits will be incorporated in the near future.

Tuesday, September 3, 2013

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.

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

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:

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 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

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:

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:

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 1.6.0.45 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:

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:

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: