NeoSploit serving two exploits

While tracking NeoSploit it has been interesting to see behavioral changes in the kit, from varying the landing page or the sequence of how the kit delivers victims to the exploit.

NeoSploit, unlike the Blackhole kit, will serve up the exploit multiple times to the victim before the compromise occurs. Why does this happen? I have no idea, but in the future will hopefully find out.

Generally I see NeoSploit serve up a single exploit 3-5 times, this behavior has been adapted recently with addition of the new Java 0-day (referenced here by Daryl at Kahu Security). Now it looks like the kit is serving up two exploits, both served up multiple times to the victim.

2012-09-10T19:36:13  200  text/html                 513:7947    GET  hxxp://minigamesobihais[.]org/gf3ztv8/?2
2012-09-10T19:36:18  200  application/octet-stream  373:3757    GET  hxxp://minigamesobihais[.]org/gf3ztv8/?659fdb537a47b1d90651585d56590d0406010f5d5000050803050d0350530105
2012-09-10T19:36:18  200  application/octet-stream  373:6623    GET  hxxp://minigamesobihais[.]org/gf3ztv8/?4e466b7c405c14f15606420d04590f540451020d020007580155005302530355
2012-09-10T19:36:19  200  application/octet-stream  330:3757    GET  hxxp://minigamesobihais[.]org/gf3ztv8/?659fdb537a47b1d90651585d56590d0406010f5d5000050803050d0350530105
2012-09-10T19:36:19  200  application/octet-stream  330:6623    GET  hxxp://minigamesobihais[.]org/gf3ztv8/?4e466b7c405c14f15606420d04590f540451020d020007580155005302530355
2012-09-10T19:36:33  200  application/octet-stream  373:3757    GET  hxxp://minigamesobihais[.]org/gf3ztv8/?659fdb537a47b1d90651585d56590d0406010f5d5000050803050d0350530105
2012-09-10T19:36:33  200  application/octet-stream  373:6623    GET  hxxp://minigamesobihais[.]org/gf3ztv8/?4e466b7c405c14f15606420d04590f540451020d020007580155005302530355
2012-09-10T19:36:34  200  application/octet-stream  373:3757    GET  hxxp://minigamesobihais[.]org/gf3ztv8/?659fdb537a47b1d90651585d56590d0406010f5d5000050803050d0350530105
2012-09-10T19:36:34  200  application/octet-stream  373:6623    GET  hxxp://minigamesobihais[.]org/gf3ztv8/?4e466b7c405c14f15606420d04590f540451020d020007580155005302530355
2012-09-10T19:36:35  200  application/octet-stream  373:6623    GET  hxxp://minigamesobihais[.]org/gf3ztv8/?4e466b7c405c14f15606420d04590f540451020d020007580155005302530355
2012-09-10T19:36:36  200  application/octet-stream  298:161052  GET  hxxp://minigamesobihais[.]org/gf3ztv8/?2826a54d96e538d05740570d530e0c53020c040d5557045f0708065355040052;1;1
2012-09-10T19:36:37  200  text/html                 300:226     GET  hxxp://minigamesobihais[.]org/gf3ztv8/?2826a54d96e538d05740570d530e0c53020c040d5557045f0708065355040052;1;1;1

I was able to grab the exploits from this interaction and run them through Virus Total.

First up:

659fdb537a47b1d90651585d56590d0406010f5d5000050803050d0350530105

e5e22099f4e24d40b345f4638fd430d1

1/42 detections

AhnLab-V3  with Java/Cve-2012-1723

Older but extremely effective java exploit.

Second up:

4e466b7c405c14f15606420d04590f540451020d020007580155005302530355

5faee8c1d7a9b0e5e6ea52720a958794

3/41 detections

Kaspersky HEUR:Exploit.Java.CVE-2012-4681.gen

And here we have the the Java 0-day.

As for the payload, we saw this medfos served up at the end.

16c352a2282670bcc24c6834ad1aa012

2/41 detections

Fortinet W32/Medfos.ALI!tr

Traffic generated by Medfos looked like this: http://IP

/file/id=BwBwAAEAOuxqCQEFABcAAABWAAAAAAAAAAAAAACMDA... (truncated due to bad bad formatting)

Always interesting to see what shows up after a successful encounter.

Reading Daryl's writeup again, he goes into the deobfuscation and tears through the kit, which is awesome. If you're not following him on twitter (@kahusecurity) or reading his blog and you're in security, you need to do it NOW! (Seriously now!)

It would be interesting to see if there is a way, like Emerging Threats has done with the Blackhole kit, to build a sig off the number of landing page. 

Granted the way we've been attacking it is building a rule off of exploit delivery URI, load URI, and post-load URI patterns.

Exploit sig:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"CURRENT_EVENTS Neosploit Exploit URI Request (by bare query parameter pattern)"; flow:established,to_server; content:"/?"; http_uri; pcre:"/\/\?\d[0-9a-f]{50,68}$/U"; classtype:attempted-user; reference:url,www.google.com; sid:*******; rev:2; )

Load URI sig:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"CURRENT_EVENTS Neosploit Load URI Request (by bare query parameter pattern)"; flow:established,to_server; content:"/?"; http_uri; content:"|3b|"; distance:0; http_uri; content:"|3b|"; distance:0; http_uri; pcre:"/\/\?\d[0-9a-f]{50,68}\;\d+\;\d+$/U"; classtype:attempted-user; reference:url,www.google.com; sid:*****; rev:2; )

 Post-load URI sig:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"CURRENT_EVENTS Neosploit Post-Load URI Request (by bare query parameter pattern)"; flow:established,to_server; content:"/?"; http_uri; content:"|3b|"; distance:0; http_uri; content:"|3b|"; distance:0; http_uri; content:"|3b|"; distance:0; http_uri; pcre:"/\/\?\d[0-9a-f]{50,68}\;\d+\;\d+\;\d+$/U"; classtype:attempted-user; reference:url,www.google.com; sid:******; rev:2; )

Again, these are experimental rules.

More on NeoSploit as I can find it.

-Paul

@demon117

The "2 hit" kit

I dub this unknown kit/pack as the "2hit kit" and here is why.

The kit is extremely "simple" looking, there are two interactions with the malicious domain that serve up an exploit and then a payload.

Example:
evildomain[.]info/0516 (exploit)
evildomain[.]info/07893 (payload)

Could it be that simple?

No, however I haven't been able to find and document the missing link in the malicious traffic. My assumption of the traffic is a compromised site (possibly outdated/exploited wordpress or something along those lines) serving up the malicious JavaScript that leads to the victims system's JRE connecting to the malicious domain.

Unfortunately this has been evading me so these are my unconfirmed assumptions.

I will be editing this or adding another post with a theoretical Snort signature for this kit.

My RegEx logic: (Splunk with proxy logs)

uri_path="/0*" user_agent=*java* | regex uri_path="^/0\d{3,4}$"

Currently the logic for the signature will be based around catching the Java/1. user agent string in the header, moving into the regex for the number. There is much work to be done on it.

There is much data to sift through and sites to plug at when I have the chance.

Until I have more.

-Demon

@demon117

NeoSploit is not dead

In April/May we realized that it had been a year since encountered NeoSploit, what a ride it has been since then. Mostly on figuring out how to lock in a signature for the kit.

Up until just recently (1-1.5 months) this was the most advanced kit I have seen, granted I've never seen anything around the install of the kit or the mechanics beyond the URI patterns. Granted from a Regular Expression stand point the pattern is a bit of a beast, but there are ways to match.

This kit has definitely not faded away, it's out there, maybe not as prevalent as blackhole but it is striking from the shadows.

Looking back, I referred to the rules we created to try and catch this kit but never got into them (at least I think I never got deep into them on here).

Here are the rules:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Neosploit Exploit URI Request (by bare query parameter pattern)"; flow:established,to_server; content:"/?"; http_uri; pcre:"/\/\?\d[0-9a-f]{50,68}$/U"; classtype:attempted-user; reference:url,www.google.com; sid:1000021; rev:2; )

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Neosploit Load URI Request (by bare query parameter pattern)"; flow:established,to_server; content:"/?"; http_uri; content:"|3b|"; distance:0; http_uri; content:"|3b|"; distance:0; http_uri; pcre:"/\/\?\d[0-9a-f]{50,68}\;\d+\;\d+$/U"; classtype:attempted-user; reference:url,www.google.com; sid:1000022; rev:2; )

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Neosploit Post-Load URI Request (by bare query parameter pattern)"; flow:established,to_server; content:"/?"; http_uri; content:"|3b|"; distance:0; http_uri; content:"|3b|"; distance:0; http_uri; content:"|3b|"; distance:0; http_uri; pcre:"/\/\?\d[0-9a-f]{50,68}\;\d+\;\d+\;\d+$/U"; classtype:attempted-user; reference:url,www.google.com; sid:1000023; rev:2; )

These rules have been crafted to catch what we've seen for a while, however for some unknown reason little success has been had actually catching the kit. From a visibility standpoint I hope it is the rule...

Regardless, what has been observed looks like this:

Landing page: (Do not have a rule for this)
/?digit

Exploits (served up multiple times, mainly 3)
/?+digit+lots-of-hex(variable amount 50-68)

Load Request:
/?+digit+lots-of-hex(variable amount 50-68);digit(s);digit(s) (Malware payload)

Post-Load Confirmation:
/?+digit+lots-of-hex(variable amount 50-68);digit(s);digit(s);digit(generally a 1)

The landing page is fairly sizeable, and full of obfuscated javascript.
Exploits we've seen are all Java related and are around 5kb
Payload is roughly 100-300kb in size.

Please let me know if you've seen any activity like this, have more information regarding this kit, or just want to compare notes.

I know researchers have seen it, but it seems like no one is talking about it other than quick spurts.

Thanks!

-Demon

@demon117 (on twitter)
paul.sec117@gmail[.]com for email

Bugat-Feodo-Cridex

Been seeing some interesting traffic credited to Bugat/Feodo/Cridex.

Sadly due a lack of packet data I cannot contribute more than IPs related to CNC activity and the URL structure that was employed in the POSTs.

Reading Kimberly and Andre's write-ups I wanted to contribute something to the community that may possibly at least add something more to their analysis.

The first interaction that I became aware of the CNC was observed with this interaction (Proxy log):

POST - http 68.178.206.179 8080 /mx5/B/in/ - - "Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US)"

One of the points of data I have found useful in CNC activity is checking out the User Agent String, this one being more complex than "Internet Explorer" or "Mozilla / 4.0", etc.

The UAS is fairly rarely used, in my research I've seen it associated with real.com or Cridex.

Digging through the last couple of months of traffic I observed the URI path that stopmalvertising documented the URI Path: /zb/v_01_a/in/ /zb/v_01_b/in/. This was observed starting out on 6/5/12.

Here is the traffic observed in this earlier compromise:

POST - http 41.168.5.140 8080 /zb/v_01_b/in/ - - "Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US)" 10.17.10.59 4063 1710859

Here are the observed CNC IPs related to these compromises:

216.24.197.66
213.17.171.186
211.44.250.173
210.56.23.100
200.169.13.84
190.81.107.70
188.40.0.138
184.106.189.124
180.235.150.72
164.15.21.2
155.98.65.40
125.19.103.198
110.234.150.163
97.74.75.172
95.142.167.193
91.228.154.199
91.121.103.143
85.214.204.32
59.90.221.6
41.168.5.140

You've probably noticed that my first example doesn't match the previously documented structures, this is where the fun begins. (It's ok if you didn't notice it, that's the purpose of the post is to bring that to light (or attempt too)).


POST - http 68.178.206.179 8080 /mx5/B/in/ - - "Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US)"

They are utilize the POST method, both run on port 8080 (at least that's all I have observed), same UAS, but they varied up the URI path.

Here are the observed CNC IPs related to these compromises:

87.204.199.100
87.120.41.155
85.226.179.185
68.178.206.179
64.94.164.18
72.167.253.106
59.90.221.6
41.168.5.140
219.94.194.242
210.56.23.100
202.65.121.5
200.169.13.84
123.49.61.59

Without packet data and better visibility with the systems this is what I can find and document, I hope it helps.

-Demon117
@demon117 on twitter

*Warning* Both sets of IPs may very well be still active and contain malicious stuff on it, or not, either or... if you do anything them and stuff happens for the bad, it's not my fault.

New NeoSploit Research

Had a ton of fun digging into new encounters with the NeoSploit kit over the last two days and have discovered a bit of change from the initial encounters in the last year. It boggles my mind that it's been a year since we saw it start to show up and almost a year since I tried to get serious about tracking it. I was serious, but it was and continues to be difficult.

Over the last week I have been refining my queries to dig through the logs looking for the specific URI patterns, specifically the Load URI Request and what I assume is the Post-Load URI Request or confirmation the payload was delivered. The query has proven to be quite solid now to push my searches farther back in time to amass a larger data set than I currently have.

My hope is the more data these searches yield the better the and more refined signatures can be crafted from them. In the last year I have been tracking patterns and what I could determine behavior of both the kit and the traffic direction techniques that the kit used. In that time there have been changes, there are probably changes now that I haven't seen. This kit is brutally effective and is extremely obfuscated with its tactics.

Observations from previous posts and the interactions recently are:

1. Changed the redirection means - previously a strange string/uri query, now a third party site that seems to be referenced by a compromised site to insert an iframe leading to the landing page.

2. No longer seeing the strange http://[IPaddress]/random.class file in the interaction process.

3. (unvalidated) Appears that the same exploit seems to be pushed multiple times prior to Load URI request ... this may not be a new thing either, but interesting

4. Found a variant of a 9 alpha-numeric subdirectory structure in the URI path, originally assumed there was just an 8 character path.

I need to collect my notes from the last year and try to combine all of request URI structures in a file to do analysis on. As well as consolidate my notes for a more coherent understanding and ability to communicate my findings.

After digging through a small data set we were able to piece together 3 test signatures for Snort to track Exploit URI, Load URI request, and Post-Load URI request. Running this for the next few months will hopefully provide much more granular content around the requests so the signatures can be tuned and shared with the community.

Happy hunting!

-Paul
@demon117

Client JavaScript is NOT a security mechanism

I am coming to the conclusion that masking things behind client side JavaScript to keep it "secure" or safe is not a good idea if you want to keep things safe. Seriously folks, "No Script" have you heard of it?

Will try to learn more to communicate it out. If you have a site, please don't rely on this to keep your content safe... People with a browser and some know how can poke at things, and most likely will.

-Paul

A "Gotcha!" moment, literally

Researching what appears to be a malicious injection I wanted to poke at the bad site - piz[dot]de[dot]tf . Obviously, this seems malicious to me and I have still not identified where the injection is at (I need to pull .css files .etc from the cafecoronado page).

(This is related to the Sutra TDS. Thanks to Darren for the help on identifying the threat.)

I tried to wget the in.cgi?2  at the above mentioned domain and here is the output:



$ wget hxxp://piz.de.tf/in.cgi?2
--2012-02-06 10:42:54--  hxxp://piz.de.tf/in.cgi?2
Resolving piz.de.tf (piz.de.tf)... 31.184.192.6
Connecting to piz.de.tf (piz.de.tf)|31.184.192.6|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: hxxp://188.72.213.185/c/bot.js [following]
--2012-02-06 10:42:55--  hxxp://188.72.213.185/c/bot.js
Connecting to 188.72.213.185:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `bot.js'

    [ <=>                                                                                                                    ] 7           --.-K/s   in 0s     

2012-02-06 10:42:55 (273 KB/s) - `bot.js' saved [7]
                                                                                                                                                
$ cat bot.js                                                                                                                                                   
GOTCHA!$

Yes, I was found and have laughed a few times at this response.

Pretty funny stuff.

-Paul
@demon117

The Blackhole Pack

Blackhole - of all the packs that I've seen it has to be this one that we see the most.

The other day watching a redirect chain that was blocked I decided to research  the part of the chain the unsuspecting user was protected from. The page landing page was a mess, obfuscated and gnarly to say the least. So I decided to run it through wepawet to see what it could do work through the obfuscation.

Wepawet came through wonderfully and yielded the following link/report:


Doublediet[dot]com Report
(http://wepawet.iseclab.org/view.php?hash=4bb5c0ea61443185406fa062237525bc&type=js)

It's awesome to see from start to finish the mechanics down to detecting the shellcode and payload.

Thanks to the Wepawet folks for an awesome tool and making it easy to read.

I am working on getting more time to play with the packs we see, and will hopefully be refining my means of pulling data and getting better at it.

-Paul
@demon117

.info: home to badness

Greetings,
It has been a while since I gave this blog some attention, work has shifted to provide more research time that will have direct benefits to my information gathering time and being able to share said findings.

First off, seen a massive uptick in the Black Hole kit activity, and NeoSploit is back on the radar after we lost visibility for a bit (most likely it was us and not them taking a break). Another pack has emerged as well that I don't know what it is, but it uses some interesting attempted obfuscation. It's not as blatant as Black Hole, but no where near as wicked obfuscated as NeoSploit.

Getting to the title, the TLD of .info is home to definitely BH and NeoSploit. Black Hole is pretty easy to identify the payload/compromise as the binary payload download has been locked in very tight with the Emerging Threats signature. I will edit it this with one of the strings as it is completely escaping me right now. NeoSploit is never easy, at least not for me. I need to poke at the patterns again to see if there is a way to determine a content match rather than just going solely off of regex. This "new" pack that is between BH and NeoSploit seems to share some of the common exploit names with BH, something I've seen regularly is the use of the com, edu, net, org java bits being passed. Why does it do this? I have no idea, it however does pass them.

If you have proxy logs for your consumption and can build content around it I recommend shooting for a UserAgent containing Java going to the ".info" TLD. There are more than just this that are absolutely suspicious and there is rarely a good reason for anyone to be playing with java over there, I will find that list and drop it in here too of suspicious TLDs that have been high fidelity when seeing Java talking with them.

Here is to more hunting and at least blocking of the badguys.

-Paul
@demon117