First off, going to pull what may be a stupid wannabe blogger move and mix in some speculation with a lot of opinion... hopefully it works, if not... let me know.
Analysis... it's interesting, necessary for life and survival... but as natural as it may be on a day to day basis, security analysis is a little different for most of us. Fact of the matter is, there are many facets of life that require thinking or analysis that is more difficult than just regular every day 2nd nature thinking.
Last week I heard in a presentation, well multiple presentations about Security Intelligence and Operations. Organizations around the world are pitched in battle and are faced with challenges that range from hiring analysts to training to fighting the battles they are hired for.
There are many questions that management is asking about analysts, and from the sounds of it they are centered primarily around hiring... One of the constants of Ops is the ever rotating door...
The question I am asking myself is how do we build solid analysts that can link security concepts with tools and open their minds to do awesome analysis, or just quality analysis versus assumption.
Okay, time to stop my mentally meandering and get to the point.
I am going to sit down and read two books, well finish one and consume the other.
'Thinking Fast and Slow' by Daniel Kahneman
And
'Psychology of Intelligence Analysis' by Richards J. Heuer Jr. [pdf here]
Both of these books have to do with thinking, and I am under the impression that both have something to do with helping us understand when we are acting off of assumptions and when we are doing analysis.
I am going to see if I can find and then illustrate a link between the two writings. My premise for this is based on Thinking and Fast and Slow and the two systems we as humans operate with. Then linking that to Heuer's writing on what I believe is doing analysis and being able to separate the assumption from analysis.
This will take a bit as I have to finish both books.
- Paul
Showing posts with label infosec. Show all posts
Showing posts with label infosec. Show all posts
Sunday, November 24, 2013
Sunday, August 12, 2012
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
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
Labels:
2hit,
attack,
criminal,
cybercrime,
Exploit Kit,
Exploit Pack,
infosec,
Java,
malware,
research,
security,
threat,
threatintel,
webbased
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
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
Labels:
attack,
cybercrime,
Exploit Kit,
Exploit Pack,
infosec,
malware,
Sutra TDS,
TDS,
threat,
webbased
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
Sunday, October 30, 2011
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
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
Labels:
criminal,
cybercrime,
Exploit Kit,
infosec,
Java,
malware,
NeoSploit,
security
Subscribe to:
Posts (Atom)