IE Zero Day: Response Required

Another day, another zero day vulnerability (Gosh, I love that term. So ominous. Like seeing a mushroom cloud). This time it's in IE 9 and 10.



Side track: It's amusing to me that software that a vulnerability in software that has been outdated for 3.5 months can be so devastating, but I guess that's the corporate world.

There are a number of pretty good technical writeups on the exploits for this one seen in the wild already, so I won't go into that. I'd rather address what you should do if you're a medium to large company.

A senior analyst at my company was tasked with looking into this threat. He read the title of the FireEye post, sent an email that said "Upgrade to IE 11" and called it good. Not terribly helpful. There are a number of steps you should do to start looking into this.

The first question you should ask is, "Have I been attacked already?" If you have a SIEM tool this should be easy enough to determine. The first domain you'll want to look for is the VFW site (vfw.org), since that was the site that was originally compromised.

If you don't find traffic it is a very good sign. I wouldn't relax quite yet, though, as someone could've accessed this site from their laptop at home. FireEye put together a list of the IPs and domains they've seen that are probably C&C servers connected to the VFW compromise, so it's good to watch for these too:

First Seen	Last Seen	CnC Domain	IP
2013-08-31	2013-08-31	icybin.flnet[.]org	58.64.200.178
2013-05-02	2013-08-02	info.flnet[.]org	58.64.200.178
2013-08-02	2013-08-02	book.flnet[.]org	58.64.200.178
2013-08-10	2013-08-10	info.flnet[.]org	58.64.200.179
2013-07-15	2013-07-15	icybin.flnet[.]org	58.64.200.179
2014-01-02	2014-01-02	book.flnet[.]org	103.20.192.4
2013-12-03	2014-01-02	info.flnet[.]org	103.20.192.4

And as long as you're searching for traffic, look for anything hitting

First Seen	Last Seen	CnC Domain	IP
2012-11-12	2012-11-28	me.scieron[.]com	58.64.199.22
2012-04-09	2012-10-24	cht.blankchair[.]com	58.64.199.22
2012-04-09	2012-09-18	ali.blankchair[.]com	58.64.199.22
2012-11-08	2012-11-25	dll.freshdns[.]org	58.64.199.25
2012-11-23	2012-11-27	rt.blankchair[.]com	58.64.199.25
2012-05-29	2012-6-28	book.flnet[.]org	58.64.199.27

As well.

If all of those searches turn up empty, you might be ok. But depending on your infrastructure, it's still possible someone took a laptop to Caribou and got compromised when they weren't attached to your network, so it wouldn't be a bad idea to create an alarm for traffic to those addresses for some on going awareness.

At this point, you can be pretty confident you aren't already infected (from this specific exploit). So how can you stay clean?

The good news about this exploit is that it is a new way to use old attacks. FireEye has also has a good write up on some of these techniques. You should make sure your end point protection is watching for these techniques (which it should be already).

If you read the article closely, you may have noticed that the exploit checks for EMET to be installed and just gives up if it is. "Shouldn't you just install that?" you may ask. And it's not a bad idea to install it (or to just add a file at the location the exploit checks for). But that's a restriction that this specific exploit decided to give up on. The next attacker to use this vulnerability may decide it's worth figuring out how to evade EMET, so that's not a silver bullet.

And sadly enough, that's most of what you can do at this point. Look for evidence you're already compromised and then make sure your existing security defenses are working as well as they can. I suppose you can also cross your fingers that Microsoft comes out with a fix soon (they did create a press release, but it amounts to "Windows server is less vulnerable, polar bears can be dangerous, and we'll get back to you on this").

Extra: Some interesting research on using Windows Crash reports to catch infections like this on your network here, but it's pretty theoretical. You might be doing some pioneering if you want to go this way.