[Updated on December 30, 2012] On December 27, we received
reports that the
target="_blank">Council on Foreign Relations (CFR) website was
compromised and hosting malicious content on or around 2:00 PM EST
on Wednesday, December 26. Through our href="http://www.fireeye.com/products-and-solutions/malware-protection-cloud.html"
title="FireEye Malware Protection Cloud">Malware Protection
Cloud, we can confirm that the website was compromised
at that time, but we can also confirm that the CFR
website was also hosting the malicious content as early as
Friday, December 21—right before a major U.S. holiday.
We can also confirm that the malicious content hosted on the website
does appear to use Adobe Flash to generate a heap spray attack against
Internet Explorer version 8.0 (fully patched), which was the source of
the zero-day vulnerability. We have chosen not to release the
technical details of this exploit, as Microsoft is still investigating
the vulnerability at this time.
In the meantime, the initial JavaScript hosting the exploit has some
interesting features. To start, it appears the JavaScript only served
the exploit to browsers whose operating system language was
either English (U.S.), Chinese (China), Chinese (Taiwan), Japanese,
Korean, or Russian:
var h=navigator.systemLanguage.toLowerCase();
&& h!="en-us" && h!="zh-tw"
&& h!="ja" && h!="ru" && h!="ko")
{
location.href="about:blank";
}
Also, the exploit used browser cookies to ensure that the exploit is
only delivered once for every user:
var num=DisplayInfo();
if(num >1)
{
location.href="about:blank";
}
where
essentially tracked when the page was last visited through browser cookies:
function DisplayInfo()
{
var
expdate = new Date();
var visit;
expdate.setTime(expdate.getTime() + (24 * 60 * 60 * 1000*7 ));
if(!(visit = GetCookie("visit")))
visit = 0;
visit++;
SetCookie("visit", visit, expdate, "/", null, false);
return visit;
}
Once those initial checks passed, the JavaScript proceeded to load a
flash file
which ultimately triggered a heap spray in Internet Explorer in order
to complete the compromise of the endpoint.
Once the browser is
exploited, Prior to downloading the exploit, the browser
appears to download “
into the browser cache (aka " href="http://blog.armorize.com/2011/04/newest-adobe-flash-0-day-used-in-new.html">drive-by
cache attack"), which is the dropper encoded using
single-byte XOR (key: 0x83, ignoring 0x00 and 0x83 bytes). Once the
exploit succeeds, the JPG file is decoded as a DLL, which is written
to the
"
the sample
(MD5:
(MD5:
href="https://www.virustotal.com/file/3191180d32c3fc044fa67c5a0aa75589a0a809ef3275d609666c77d7b7b68675/analysis/">715e692ed2b48e455734f2d43b936ce1)
appears to contain debugging information in the metadata of the file:
style="display: inline;" class="asset-img-link">
src="https://www.fireeye.com/content/dam/legacy/blog/2012/12/6a00d835018afd53ef017d3f532717970c-800wi.png"
title="Cfr-figure1"
class="asset asset-image at-xid-6a00d835018afd53ef017d3f532717970c landscape-med" border="0" />
The simplified Chinese <文件说明> translates to <File
Description>. It looks like the malware author included additional
metadata in the file, referencing "
as the internal name of this sample.
[Update: December 30, 2012]
Additionally, another binary "
(MD5:
href="https://www.virustotal.com/file/0a26268515a661149cef152d67861d5805040e23aa41ea947710ef55f26b5e0a/analysis/">a2e119106c38e09d2202e2a33e64adc9)
is initially dropped to the
executed, which appears to perform code injection activity against the
standard IE "
process and installs itself as "
Files\DirectDB.exe", using the
registry key to maintain state information. We can also confirm Jamie
Blasco's (AlienVault) findings, where the malware registers
"
through the active setup registry key
Components\, so that this executable starts once per user upon
subsequent login. However, while href="https://github.com/jaimeblasco/AlienvaultLabs/raw/master/malware_analysis/CFR/41bd34a6-dff3-435b-8a98-6ec7ab0d222b.ioc">AlienVault's
IOC mentions a process handle name of "
we have actually found the "
process generates a mutex of
upon execution, as well.
As of December 29, Microsoft released a security advisory (
href="http://technet.microsoft.com/en-us/security/advisory/2794220">2794220),
which provides initial details of the zero-day
vulnerability. Additionally, href="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4792">CVE-2012-4792
has been assigned to track this vulnerability over time.
Simultaneously, Metasploit developers have analyzed the
vulnerability and Eric Romang released details of the CDwnBindInfo
Proof of Concept Vulnerability demonstration for independent verification.
Lastly, Cristian Craioveanu and Jonathan Ness with MSRC Engineering
posted further technical details on MS Technet about ways to mitigate
href="http://blogs.technet.com/b/srd/archive/2012/12/29/new-vulnerability-affecting-internet-explorer-8-users.aspx">CVE-2012-4792,
in the meantime.
One interesting side-note that MSRC href="http://blogs.technet.com/b/srd/archive/2012/12/29/new-vulnerability-affecting-internet-explorer-8-users.aspx">mentioned is:
On systems where the vulnerability is not present, this
Javascript snippet will have the side effect of initiating an HTTP
GET request with the encoded heap spray address in it. A network
log or proxy log would reveal the following HTTP requests:
GET /exploit.html HTTP/1.1
GET /%E0%B4%8C%E1%82%ABhttps://www.example.com HTTP/1.1
As you can see, the value 0x10AB0C0D is encoded in UTF8 and sent
as part of the HTTP request. The real-world exploits do not use
example.com and the heap spray address will vary depending on
targeted OS platform and exploit mechanism but if you see encoded
memory addresses in your proxy log, you should investigate to
determine whether your organization has been targeted.
Yet, in the wild, we have seen cases where a successfully
compromised endpoint generates an equivalent encoded pattern:
style="display: inline;" class="asset-img-link">
src="https://www.fireeye.com/content/dam/legacy/blog/2012/12/6a00d835018afd53ef017ee6c809c1970d-650wi.png"
title="Cfr-figure2"
class="asset asset-image at-xid-6a00d835018afd53ef017ee6c809c1970d landscape-med" width="650" />
... and still beacons (via HTTP POST) to the initial command
and control infrastructure at
we encourage security operations analysts to fully investigate
endpoints that generate the encoded heap spray network traffic,
rather than simply assuming those systems are not compromised.
We will continue to update this blog with further details, as we
discover new information about this attack.