FireEye Malware Intelligence Lab

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.

Using Honeypots to Sniff and Snuff out Botnets, part 1

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.

Anatomy of an MS08-078 exploit, part 2

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.

Anatomy of an MS08-078 exploit, part 1

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.

On the new Explorer XML zero day

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:)

I haven't seen this <object id=xmltarget classid="CLSID:88d969c5-f192-11d4-a65f-0040963251e5"> in malicious Javascript recently enough that I can recall it off the top of my head - and some grepping on the boxes I checked found only this one event like this in the last month.  "88d969c5-f192-11d4-a65f-0040963251e5" turns out to be the class ID for the ActiveX control that implements XMLHTTP within Microsoft XML Core Services so it seems likely that this is an instance of the new exploit (though I haven't verified that yet) .  There was a vulnerability in this component back in 2006 (eg see the Securiteam advisory from that time).  If so, it's at least possible that the instructions at that link for disabling that component would also be protective here.  That would be less impactful than not browsing with IE 7.  (Again, I stress that I haven't confirmed that speculation - I'm throwing out the possibility in case it's helpful to others in the community).

More tomorrow hopefully.

Update:

It turned out when we investigated this in detail that it's not related to the XML zero-day vulnerability.  We've now seen four of these events at various customers with the same starting <object> tag with the same classid.  We haven't seen that particular form before, and Google does not find other discussions of it.  The obfuscated body is polymorphic but when deobfuscated reveals a bunch of older browser/plugin exploits.  One of the incidents succeeded in infecting the client, and on investigation, that turned out to be this fresh packing of the Grum bot.  The destination IP of the exploit server was the same in all cases, and it's a known RBN IP address.  The campaign appears to be driven by malicious ads.  Thanks to Julia, Atif, and Alex for help in investigating, and apologies for any confusion: it appears to be a new obfuscation idiom and a new packing that was not recognized by almost any AV, but not a new exploit - just coincidence that the XMLHTTP classid was used on the same day that the new XML exploit was out.

NOC4HOSTS and the Grum Botnet

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.

Zoom-In to Pushdo CnCs....

[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.

Cut the Cutwail....!

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.