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 security. Show all posts
Showing posts with label security. Show all posts
Sunday, November 24, 2013
Saturday, November 9, 2013
Data Wrangling – Splunk & CIM
Data… there is a lots of it… Now we can store it, well, we’ve been
able to for a while, but it’s catching on that lots of data is good, and
making it useful is awesome!
I get to play with a little data, it’s miniscule in comparison with some, but it’s what I get to play with… so I am learning about the things I can do. One of the tools I get to use is Splunk, I’ve had the opportunity to shape and mold the “data” so that it’s more than just unstructured data. It’s useable data with some tuning, but as far as I can tell, you really do have to put time and effort into Splunk to “train it”. Let me be clear, I’ve yet to see Splunk do something that looks intelligent other than Key:Value pair extraction out of data… and that’s debatable on being useful.
I have a vision, and right now I am trying to understand if it’s a commonly shared vision using what the Splunk people call the Common Information Model (link here). My vision, helped along by a friend and mentor, as well as seeing what people have done in more advanced correlation systems is to build essentially a web of linking points of data within all of the various events and log types I have access too.
Think of this from a security analyst standpoint:
Event comes in, they see it in the SIEM or the ES App and start to dig in… Asking the question of what else does this show up in or as? Building a search based off of src_ip=”IP in question” OR dest_ip=”IP in question”… (Two points on this, still pre-Splunk6 and lets say we cleverly specify the index via config magic for the role in the app)… What do you think will happen?
What I am pushing for is to make it so all sources, sourcetypes, and sub-sourcetypes that have a component that is a “source ip address” or a “destination ip address” is checked for this IP. If it has hits, it shows up in the search. Yes, this is not a super rare term search, that’s the point of the search, it’s not supposed to be. It does however provide the analyst with the ability to dig in to all of the sourcetypes that have hits, allowing further drilling down in various searches to extract and pivot through the data in various periods of time to see where this IP has interacted with the network.
Like:
User VPN’s into company -> AV events occur -> Logs into a meeting -> Logs into an application server -> etc. etc.
Being able to correlate a single users path through various log sources is key to seeing what all that user has done in the period of time visible to the security analyst. Making it easier for them to pick up a bread crumb, whether it be in the middle of the trail or at any point, and finding out about the who|what|why|when parts of deciding if it’s an incident or not.
I have no idea how many people/organizations are leveraging the power of CIM (Common information model), or if I am just being slow to get on board with this.
My experience with CIM is having it pointed out by a friend/mentor, and then trying to hold the people working on Splunk to it.
I get to play with a little data, it’s miniscule in comparison with some, but it’s what I get to play with… so I am learning about the things I can do. One of the tools I get to use is Splunk, I’ve had the opportunity to shape and mold the “data” so that it’s more than just unstructured data. It’s useable data with some tuning, but as far as I can tell, you really do have to put time and effort into Splunk to “train it”. Let me be clear, I’ve yet to see Splunk do something that looks intelligent other than Key:Value pair extraction out of data… and that’s debatable on being useful.
I have a vision, and right now I am trying to understand if it’s a commonly shared vision using what the Splunk people call the Common Information Model (link here). My vision, helped along by a friend and mentor, as well as seeing what people have done in more advanced correlation systems is to build essentially a web of linking points of data within all of the various events and log types I have access too.
Think of this from a security analyst standpoint:
Event comes in, they see it in the SIEM or the ES App and start to dig in… Asking the question of what else does this show up in or as? Building a search based off of src_ip=”IP in question” OR dest_ip=”IP in question”… (Two points on this, still pre-Splunk6 and lets say we cleverly specify the index via config magic for the role in the app)… What do you think will happen?
What I am pushing for is to make it so all sources, sourcetypes, and sub-sourcetypes that have a component that is a “source ip address” or a “destination ip address” is checked for this IP. If it has hits, it shows up in the search. Yes, this is not a super rare term search, that’s the point of the search, it’s not supposed to be. It does however provide the analyst with the ability to dig in to all of the sourcetypes that have hits, allowing further drilling down in various searches to extract and pivot through the data in various periods of time to see where this IP has interacted with the network.
Like:
User VPN’s into company -> AV events occur -> Logs into a meeting -> Logs into an application server -> etc. etc.
Being able to correlate a single users path through various log sources is key to seeing what all that user has done in the period of time visible to the security analyst. Making it easier for them to pick up a bread crumb, whether it be in the middle of the trail or at any point, and finding out about the who|what|why|when parts of deciding if it’s an incident or not.
I have no idea how many people/organizations are leveraging the power of CIM (Common information model), or if I am just being slow to get on board with this.
My experience with CIM is having it pointed out by a friend/mentor, and then trying to hold the people working on Splunk to it.
Tuesday, September 11, 2012
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.
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
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
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.
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
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
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.
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
Subscribe to:
Posts (Atom)