Tag Archives: IE 0Day

Capstone Turbine Corporation Also Targeted in the CFR Watering Hole Attack And More

Since the release of MSA-2794220 by Microsoft, regarding the CVE-2012-4792 vulnerability, a Fix-it solution has been provided KB2794220. I urgently advise you to apply this Fix-it solution, or to use another browser, until the release of the final patch surely planned for the 8 January Microsoft Patch Tuesday.

I have some interesting and funny additional information’s regarding the CFR watering hole attack, and I would like to share them with you. But previously I recommend you to read the following analysis done by security companies or independent security researchers:

Let’s start with the analysis of only two samples, “news_14242aa.html” and “Helps.html“. These two samples are quiet interesting, and a complete blog post is enough for them. I will analyze the other samples in dedicated further blog posts.

news_14242aa.html (545cb268267609910e1312399406cdbc)

This sample was extracted from Google cache with a cache date of 7 Dec 2012 14:12:28 GMT. This sample clearly demonstrate that the compromise of CFR.org wasn’t the 20, or 21 December as mentioned by security companies or medias, but really sooner. The proof is still indexed and in cache of Google.

Capture d’écran 2012-12-28 à 22.25.31


Helps.html (a25c13d4edb207e6ce153469c1104223)

I received this sample, around the 29 December.  This file is the equivalent of the first sample but with some modifications, you can see the differences in the following online diff. Additional languages have been added (jp – ru – ko),  all the stuffs regarding Microsoft Office documents have been removed (boy or girl), some additional “blank” locations have been added and the body text has been hide.

Now, if you do research on VirusTotal with this MD5, you can find a relate sample, but with another filename “config.html” who was submitted the 2012-12-31 18:29:47 UTC. Looks like interesting, but has to be confirmed.

If you execute a request on urlQuery in order to search all “config.html” file for the last past month, you will discover a submission, dating from 2012-12-29 22:58:29, for URL “http://www.capstoneturbine.com/_include/config.html” on server If you take a look at the urlQuery report you can see some “deployJavaPlugin” strings.

The Capstone Turbine Corporation company description, make me believe that this company profile could be a choice of quality for targeted attack:

Capstone Turbine Corporation ® is the world’s leading producer of low-emission microturbine systems, and was first to market with commercially viable microturbine energy products. Capstone Turbine has shipped thousands of Capstone MicroTurbine systems to customers worldwide.

By doing a Google dork research “site:capstoneturbine.com “_include”” you can see something strangely similar to CFR.org “news_14242aa.html file.


This page is also cached in google cache, and guess what ? Ho, Ho Ho, CVE-2012-4792 is in the house since the 18 December 16:10:40 GMT. So CFR.org was and is not the only target of this attack !

Now we will try to define the date of compromise of Capstone Turbine Corporation through research on Google by another google dork “capstoneturbine.com” “_include”“. And we can find some interesting informations 😉


On support.clean-mx.de we can discover that the same “/_include/config.html” URL was indexed since 2012-09-19 04:31:01. But what is awesome is the evidence attached to this submission hoho it is CVE-2012-4969 I discovered in September 🙂 “Grumgog.swf” is in the house.


My conclusions are:

  • CFR.org was comprised since minimum beginning December.
  • CVE-2012-4792 was present on CFR.org since minimum beginning December.
  • CVE-2012-4792 was also used to target visitors of another company named Capstone Turbine Corporation.
  • CVE-2012-4792 was present on Capstone Turbine Corporation since minimum 18 December.
  • Capstone Turbine Corporation was also used to spread CVE-2012-4969 and this since mid-September.
  • Potentially Capstone Turbine Corporation is compromised since minimum beginning September
  • Potentially the guys behind CVE-2012-4969 and CVE-2012-4792 are the same.

But, there is always a but in a story, take a look at the first submission for Capstone Turbine Corporation in August, “http://www.capstoneturbine.com/_flash/videos_native/exploit.html “. Imagine 🙂

Update 1 – 2013-01-02 1:30 am:

Jindrich Kubec director of Threat Intelligence at avast! confirm presence of CVE-2012-4969 in September on Capstone Turbine Corporation.

Microsoft Internet Explorer CButton Vulnerability Metasploit Demo

Timeline :

CVE reference assigned the 2012-09-06
First samples of the attack discovered in Google cache the 2012-12-07
Vulnerability discovered exploited in the wild on CFE.org around the 2012-12-26
Vulnerability details provided by binjo, Eric Romang and FireEye the 2012-12-29
Microsoft Security Advisory published the 2012-12-30
Metasploit PoC provided the 2012-12-30
Metasploit module name changed the 2012-12-31

PoC provided by :

mahmud ab rahman
juan vazquez

Reference(s) :

new IE 0day coming-mshtml!CDwnBindInfo object use after free vulnerability
Attack and IE 0day Informations Used Against Council on Foreign Relations

Affected version(s) :

nternet Explorer 6
Internet Explorer 7
Internet Explorer 8

Tested on Windows XP Pro SP3 with :

Internet Explorer 8

Description :

Note: The module name has change from ie_cdwnbindinfo_uaf to ie_cbutton_uaf

This module exploits a vulnerability found in Microsoft Internet Explorer. A use-after-free condition occurs when a CButton object is freed, but a reference is kept and used again during a page reload, an invalid memory that’s controllable is used, and allows arbitrary code execution under the context of the user. Please note: This vulnerability has been exploited in the wild targeting mainly China/Taiwan/and US-based computers.

Commands :

use exploit/windows/browser/ie_cbutton_uaf
set TARGET 1
set PAYLOAD windows/meterpreter/reverse_tcp


Microsoft Release Security Advisory MSA-2794220 for CFE Internet Explorer 0day

Microsoft has release a security advisory MSA-2794220 for the Internet Explorer 0day used against Council on Foreign Relations (CFR.org) “drive-by” attack. This attack was reported the 28 December by “The Washington Free Beacon” but it seem that only 48 hours after the publication of this news an exploitable Metasploit module will be available during this long week-end end of the year.


Microsoft confirm, in the security advisory, that the vulnerability is only affecting Internet Explorer 6, Internet Explorer 7, and Internet Explorer 8. Internet Explorer 9 and Internet Explorer 10 are not affected by the vulnerability. Also this Internet Explorer vulnerability has been identified as CVE-2012-4792.

Microsoft is not providing any date for a patch release, but will the appropriate actions, which may include providing a solution through the monthly security update release process, or an out-of-cycle security update. The next “Patch Tuesday” cycle is planned for the 8 January, but depending on how fast the exploit kits will include this new vulnerability, it will be maybe possible that Microsoft will release an out-of-band patch.

As always Microsoft is recommending the usage of Enhanced Mitigation Experience (EMET) in order to mitigate the attack.

Attack and IE 0day Informations Used Against Council on Foreign Relations

Council on Foreign Relations (CFR.org), a foreign policy web group, has been victim of a targeted attack who seem to be linked to computer hackers traced to China.

Regarding information’s posted on the Washington Free Beacon, infected CFR.org website was used to attack visitors in order to extract valuable information’s. The “drive-by” attack was detected around 2:00 pm on Wednesday 26 December and CFR members who visited the website between Wednesday and Thursday could have been infected and their data compromised, the specialists said.

Through Washington Free Beacon news we know that only Internet Explorer 8 and higher versions have been targeted. A possible Internet Explorer 0day was used to infect visitors computers. We also know that the attack was limited to CFR members and website visitors who used browsers configured for Chinese language characters.

As always, I was curious and tried to have more information’s regarding this attack and potential 0day.

urlQuery.net investigations

On urlQuery.net, we can see that the first submission was done, the 20 December. More interesting is the submission of 21 December on URL “/js/js/news_123432476.html“. “/js/js/” directory seem to be a strange behavior. We can see that a “deployJava.js” was involved by loading this page.

Other URLs are interesting like “/js/js/robots.txt“, “/js/js/today.swf“, “/js/js/news_435435s.html” but all these URLs have been submitted the 27 December and after, and the file are no more available.

jsunpack investigations

On jsunpack we can observe that the “deployJava.js” was submitted the 26 December. All other files have been submitted the 27 December and after, and the file are no more available.

CLEAN MX realtime database investigations

On CLEAN MX we can observe an analysis the 20 December.

Why so many parallel submission ? Ok guys, the infection has started since minimum the 20 December, so not since Wednesday 26 December. Now, if you have some skill in researching information’s and if you are still curious, you will find part of the “drive-by” attack source code. By doing some additional researches I found the source code of the “drive-by” attack, and I can confirm you that this attack has started since minimum the 7 December !

Capture d’écran 2012-12-28 à 22.25.31

Let analyze this source code.

I can confirm that only visitors with Internet Explorer 8 and higher versions have been targeted.


But, a fact who was not pointed is if the visitor don’t has Adobe Flash, he will not be part of the party, Flash free Internet Explorer are not targeted.


I can also confirm that visitors who used browsers configured for Chinese language characters were targeted, but also Taiwanese and American visitors…


If you load the malicious page for the first time, a “visit” named cookie is create with a lifetime of 7 days through the “DisplayInfo()” function. If you have already a cookie, you will no more be exploited until the expiration of the cookie.


Then the page is loading the “download” Javascript function. This function is trying a XML HTTP request to a “xsainfo.jpg” file. After some discussion with @binjo, it could be that “xsainfo.jpg” maybe just a clean file, ajax trick to call the “callback” function.



xsainfo.jpg” file is maybe “320e0729e1a50fd6a2aebf277cfcad66” found on VirScan and VirusTotal. This file was submitted the 13 December.

The “callback” function verifies if the “xsainfo.jpg” has been loaded and that a “200” HTTP status code has been returned.


If the visitor operating system is Windows 7 or Windows 2008 R2, an Office document is opened through the “SharePoint.OpenDocuments” ActiveX control. Depending the way the document is opened the “key” variable is initiated with funny values “boy” or “girl“. I’m not specialist in this domain, maybe one of the blog post reader could provide some more information’s.


Depending if you are “girl” or a “boy“, the “test” division of the HTML document will be manipulated, a “today.swf” flash object will be loaded plus a “news.html” iframe.


If you are not a “girl” or a “boy“, you will need to have Java SE 6, but not JSE 7, in order to load the two same files as previously mentioned. If the visitor operating system is Windows XP, the “test” division of the HTML document will be also manipulated, and the two same files are loaded.


Unfortunately, actually I didn’t find these two files, but after more discussions with @binjo it could be that the swf is used to setup payload, “news.html” used to trigger the vulnerability.

So if 0day exist, this 0day is surely in “news.html” file, and it is also sure that this targeted attack has not begin on Wednesday, not only targeted visitors who used browsers configured for Chinese language characters.

I keep you in touch if I have additional information’s regarding this potential new Internet Explorer 0day.

Update 1 – 12/29 2am:

FireEye has post some additional information’s regarding the attack. It seem that “today.swf” trigger a heap spray in Internet Explorer in order to complete the compromise. Once the browser is exploited, it appears to download “xsainfo.jpg,” which is the dropper encoded using single-byte XOR (key: 0x83, ignoring null bytes).

What is also new regarding FireEye blog post is that their version is targeting English (U.S.), Chinese (China), Chinese (Taiwan), Japanese, Korean, or Russian. My version of 7 December was only targeting English (U.S.), Chinese (China), Chinese (Taiwan), so the guys had time to release new version of they’re code during this elapse of time. Also they didn’t mention the news.html file.

Update 2 – 12/29 11am:

@binjo has release further information’s regarding “new IE 0day coming-mshtml!CDwnBindInfo object use after free vulnerability”.

Also, I can observe that a certain number of people have samples of the 0day, I could not imagine that an active exploit will not be out before the end of the year.

Update 3 – 12/29 6pm:

AlienVault has publish more detailed information’s regarding the attack and the 0day.

Update 4 – 12/29 10pm:

@_sinn3r is on the way to deliver a Metasploit module for the CFR.org 0day exploit.

Update 5 – 12/30 00am:

Microsoft has release MSA-2794220 and confirm the vulnerability targeting Internet Explorer 6, Internet Explorer 7, and Internet Explorer 8. Internet Explorer 9 and Internet Explorer 10 are not affected by the vulnerability. CVE-2012-4792 has been assigned to this vulnerability.

Update 6 – 12/30 2am:

Metasploit team has release the Microsoft Internet Explorer 0day.


Update 7 – 12/30 11am:

Here under is the code version I found in Google cache as it appeared on 7 Dec 2012 14:12:28 GMT

Got some more samples:

  • Helps.html (a25c13d4edb207e6ce153469c1104223)
  • news.html (76d14311bae24a40816e3832b1421dee)
  • robots.txt (96b01d14892435ae031290cd58d85c2e)
  • xsainfo.jpg (7c713c44e34fa8e63745744e3b7221db)