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

NeoSploit Exposed

Wewt! Darryl Kahu Security is the Man! This has been the case for a very very long time when it comes to Deobfuscation and Exploit Kits but I'm stoked to have read that someone other than myself has called NeoSploit out. If I haven't already I will credit him with naming the kit I've been trying to document (with questionable success) months and months ago.

Now as I'm trying to get things balanced at work I will be possibly pushing a little more on researching this kit as I can. That being said, I don't promise anything amazing or special due to my lack of knowledge and experience at poking at these things.

My current thoughts on this is there may be a pattern in the URI paths used by the kit, I'm not sure how to break those down. However, there is definitely a reused pattern in the URL structure.

Case in point: A google search for "osnp91icm" (pointed out here by @kahusecurity) yields a few domains that are absolutely related to the kit.

Domains:
warlikedisobey.org/osnp91icm/?5
numbuse.org /osnp91icm/?
scatterrider.org/osnp91icm/?5
lowmustard.org/osnp91icm/?

Here is what I found looking for the same URL pattern:
http hoeobserve.org /osnp91icm/ ?5
http torpidtawny.org /osnp91icm/ ?5
http oxastir.org /osnp91icm/ ?5
http lowmustard.org /osnp91icm/ ?5
http arrivesmear.org /osnp91icm/ ?5

Same kit, different domains.

Frustratingly enough for me, is cracking the huge TLD's of com/org/net when it comes to these kits, the less frequented TLDs are easier to monitor the interaction. Keying off of Java interaction is pretty much a sure bet because the prey is so common, now the question is what versions of Java survive these attacks.


It's good to be back.


-Paul
@demon117