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
Sunday, August 12, 2012
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
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
Tuesday, August 7, 2012
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.
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.
Subscribe to:
Posts (Atom)