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.
Monday, April 2, 2012
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
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
Sunday, March 18, 2012
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
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
Monday, February 6, 2012
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
(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
Sunday, January 29, 2012
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
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
Subscribe to:
Posts (Atom)