On the new Explorer XML zero day

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