Botnet Classics – Part 1

An interesting aspect of botnet study is to attempt to learn the motives behind building a particular botnet or trying to find the intent of the criminal mind controlling all the zombies. When it comes to botnet payloads, many different motives come to  mind like DDOS, vulnerability exploitations, key logging, SPAM etc.  But not all botnets are capable of doing everything especially when it comes to vulnerability exploitations, DDOS and password stealing.  Amazingly most of the biggest botnets in recent times have been  dedicated to sending SPAM.  Take for example Srizbi, Rustock, Storm(mostly), Grum and now Waledac.

IRC bots were the first breed of malware to build multi-purpose botnets. These IRC Bots started to emerge as the next generation of malware after nifty worm breakouts like Blaster, Sasser and Slammer.

Here at Fire Eye Labs we monitor the communication of different types of bots with their command and control servers in a controlled environment. The fun part of monitoring IRC CnC is that most of the time this communication is real-time, plain text and self descriptive.  Most commonly IRC Bot masters communicate their commands using IRC channel topics and/or through Private Messages. Today I will discuss some of these bot commands extracted from my lab logs.  Lets see what these puppet masters are trying to do today:

Irc_bot_cmd

Continue reading »

Upcoming Jan & Feb Events Where We Are Presenting Research

We’re sharing our research at the upcoming ISOI6, the US Dept of Defense Cyber Crime conference, Internet2 Joint Techs, and at ShmooCon. If you are attending any of those events, we’d love to meet you in person! Alex talks about McColo, I’ll be discussing Web malware in government networks, Stu covers the latest in malware obfusction tactics, and Julia dives into the Srizbi botnet takedown. For Dates, times, topics, & locations, please read on.

Continue reading »

Barbarians Inside the Cyber Gates

Critical government, military, and civilian networks have been repeatedly infiltrated to steal our intellectual property and national secrets. So, how do we build a modern, national cyber security policy as we enter into the 44th Presidency? The Center for Strategic and International Studies' report weighed in on this topic, but I think they missed the point in their technical recommendations.

Before I go further, I should introduce myself. I'm Ashar Aziz, FireEye's CEO and founder. I'll be chiming in to write about the big picture security issues that are facing CIO/CISO's, businesses, our national cyber infrastructure, and essentially anyone who does anything on the Internet these days.

Continue reading »

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.

Continue reading »

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.

Continue reading »

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


Picture 289
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.

Continue reading »