Using Honeypots to Sniff and Snuff out Botnets, part 2
This is a continuation of my previous posting on botnets that propagate through remotely exploitable vulnerabilities.
Continue reading "Using Honeypots to Sniff and Snuff out Botnets, part 2" »
« November 2008 | Main | January 2009 »
This is a continuation of my previous posting on botnets that propagate through remotely exploitable vulnerabilities.
Continue reading "Using Honeypots to Sniff and Snuff out Botnets, part 2" »
In recent years, honeypots have seemed to fall out of favor with security researchers. The reason for this is pretty straightforward - a classic honeypot (a single IP running vulnerable services) or honeynet (a honeypot on multiple IPs) will only catch attacks that actively attempt to propagate. These attacks could be similar to a loud worm like Blaster, Gimmiv, Slammer, etc, or they could be a less noisy attack such as a bot that will only scan a local subnet.
Why am I to presume that there aren't enough researchers employing honeypots and honeynets? Simple - the botnets that use these types of attacks to spread have not had their controllers (C&Cs) fluctuate locations (IPs) in months or more. Of course, this lapse in abuse notifications is on me as well, but I hope to rectify the situation by notifying the offending upstream providers relentlessly going forward.
Continue reading "Using Honeypots to Sniff and Snuff out Botnets, part 1" »
This is part 2 of the article on MS08-078.
Below I'll talk about what this particular invocation of the exploit carried in terms of payloads.
Often times I'm asked what actually happens to a system when the browser is exposed to a modern web exploit. By "web exploit", I'm referring to the type of exploit where your browser only need visit a site - no user interaction (like opening a file) is necessary. I thought it might be interesting to take a look at a real-world implementation of the new IE exploit (MS08-078) to see what the payload was. I'm going to break this up into two posts just because of the size of the screenshots.
See update below!
Shadowserver is reporting on websites serving up a new zero day Internet Explorer exploit involving XML (see also SecurityFocus and an initial so-far-sketchy Microsoft advisory). For the sake of our customers (and potential customers!) I wanted to tentatively report that a) indeed this appears to be a real factor in the wild by now, and b) the FireEye product does appear to be correctly detecting it in at least one case. I checked around a few boxes I have access to and found a VM verified web infection event which was initiated from the web server 94.102.50.131. (That IP address should be assumed to be armed and dangerous). Our statistical anomaly algorithms picked up on the following piece of javascript (this is a screenshot so should be harmless unless you retype it:)
Update: As of 12/08, Jay from HiVelocity took the necessary steps to get these Command and Control servers shutdown. The FE research team thanks him and his team profusely for their efforts. Individual verification of customers is nearly impossible for a facility of their size, so we appreciate any efforts they can make after the fact. We'd also like to thank Ross Thomas from SophosLabs and Phil Hay from Marshal TRACE for their research efforts.
Yesterday, my colleague Atif was looking at Pushdo/Cutwail, and he found a disturbing number of the C&Cs were hosted at NOC4HOSTS. This isn't another McColo, but upon further investigation, there does appear to be a higher than average number of botnet controllers and malware hosted there. The is part 1 of an N part series on C&Cs, malware, and exploits hosted at NOC4HOSTS.
[Dec, 8th, UPDATE] Today NOC4HOSTS responded our abuse notifications and pulled the plug for all Pushdo CnC servers as mentioned in this post along with many Grum CnC as mentioned here. We really say thanks to NOC4HOSTS for their positive response.
[Dec, 4th, UPDATE] One more Cnc within NOC4HOSTS 74.50.113.92.
[Dec, 4th, UPDATE] One more IP from NOC4HOSTS 74.50.120.87 is found to be serving Cutwail. As in other cases this host is continuously delivering new SPAM templates hence becoming a cause of recent increase in Wordwide SPAM.
[UPDATE] We have Identified one more Cutwail CnC (74.50.125.72) hosted at NOC4HOSTS. So far NOC4HOSTS has not responded to any of the abuse notifications sent by FireEye.
In my previous post, I discussed different aspects of Pushdo’s command and control architecture and its fallback mechanism. Now I will discuss some datacenters which are currently hosting Pushdo and Cutwail command/control servers.
Let's first discuss the Cutwail CnCs, as these are the ones which supply daily SPAM ammunition to bots all over the world in the form of new templates. In the absence of these servers, the Pushdo botnet will no longer be able to send SPAM.
One such server is currently located in Estonia hosted by STARLINE WEB SERVICES having an IP address 92.62.100.95:1995. This is the same data center used by Srizbi few days back in an attempt to regain its control. This attempt did not prove to be very fruitful after a quick response by the community and Estonian CERT.
UPDATE: Estonia has pulled this server offline and we sincerely appreciate their swift action.
As Srizbi and Rustock are (temporarily) shutdown, there are only a few botnets left which are still able to communicate with their CnCs, and hence are able to send SPAM. This group of Botnets is some portion of Pushdo/Cutwail and Bobax/Kraken.
Marshal TRACE's recent analysis of SPAM distribution with respect to different botnets shows that currently Pushdo is the main source of worldwide SPAM in the absence of Srizbi and Rustock. Shutting down Pushdo (even temporarily) would mean more days without SPAM, just as we saw with the earlier shutdowns.