Old Wine In A New Bottle

The recent Adobe Flash 0 Day (CVE-2011-2110) is a classic case of an old malware that has used new 0 days as a vector to spread itself. How and why I will explain shortly, first a little detail about the exploit itself. The exploit is targeting a vulnerability in the Action Script Virtual machine according to our good friends at Shadowserver. The swf file takes an info parameter and a successful exploitation leads to the download of a zlib compressed and xor encoded binary. The two GET requests in succession would look like this

More on the IE 0-day - Hupigon Joins The Party

It was just a few days ago when Symantec disclosed a new 0-day vulnerability in Microsoft's Internet Explorer (versions 6, 7, and 8). They found at least one malware called 'Backdoor.Pirpi' that is actively exploiting this vulnerability in targeted email attacks posing as hotel reservation notifications. 

Here at FireEye labs, we have identified another type of Modern Malware called 'Hupigon' exploiting the same IE zero-day vulnerability. This malware looks to be more successful/reliable at infecting systems than Pirpi.

It is increasingly common that cyber criminals 'upgrade' Modern Malware with newly uncovered zero-day exploits. Now the question is, are the criminal masterminds behind this second wave of attacks the same as those behind the first wave?  In this article I will try to answer this question.

In order to find a link, let's compare these attacks side-by-side.

Who is Exploiting the Java 0-day?

Update: Oracle released an emergency patch recently to fix this major flaw. See details in the bottom.

-------------

The recent discovery of a 0-day design flaw in the 'Java Web Start' module has opened new avenues for malware drive by attacks.  This flaw was exposed by Tavis Ormandy a few days back and it did not take a long time for bad guys to start using the proof of concept code for real exploitation.  I have been reading about the exploit details for the last few days, but very few details were available on the active use of this exploit.  Who are the guys using this exploit and for spreading what?  This article is all about this, with emphasis on the post infection stuff.

Users who are interested in the inner workings of this 0-day flaw itself, can read the full disclosure here.

It all started like this... yesterday afternoon my colleague Stuart Staniford pointed me to a malicious domain hxxp://zikkuat.com (dead at the moment) which he believed seemed to be exploiting this 0-day flaw.  After a little analysis, I found it to be true indeed.  Here are the details of my findings after a detailed analysis.

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.