Auteur Sujet: [FireEye]CFR Watering Hole Attack Details  (Lu 3028 fois)

0 Membres et 1 Invité sur ce sujet

Hors ligne igor51

  • Admin
  • Mega Power Members
  • *****
  • Messages: 10419
[FireEye]CFR Watering Hole Attack Details
« le: mai 15, 2019, 06:00:18 »
CFR Watering Hole Attack Details

[Updated on December 30, 2012] On December 27, we received
  reports that the     href="http://freebeacon.com/national-security/chinese-hackers-suspected-in-cyber-attack-on-council-on-foreign-relations/"
    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();
 
     style="font-family: courier new , courier;">if(h!="zh-cn"
    && 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   style="font-family: courier new , courier;">DisplayInfo()
  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   style="font-family: courier new , courier;">"today.swf",
  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 “  style="font-family: courier new , courier;">xsainfo.jpg”
    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     style="font-family: courier new , courier;">%TEMP% folder as
      "    style="font-family: courier new , courier;">flowertep.jpg",
    the sample

  (MD5:   style="font-family: courier new , courier;">1e90bd550fa8b288764dd3b9f90425f8)
  (MD5:
   
        href="https://www.virustotal.com/file/3191180d32c3fc044fa67c5a0aa75589a0a809ef3275d609666c77d7b7b68675/analysis/">715e692ed2b48e455734f2d43b936ce1
)
  appears to contain debugging information in the metadata of the file:


 


      href="/content/dam/legacy/blog/2012/12/6a00d835018afd53ef017d3f532717970c-800wi.png"
    style="display: inline;" class="asset-img-link">      alt="Cfr-figure1"
      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 "  style="font-family: courier new , courier;">test_gaga.dll"
  as the internal name of this sample.


 

[Update: December 30, 2012]


 

Additionally, another binary "  style="font-family: courier new , courier;">shiape.exe"
  (MD5:
   
        href="https://www.virustotal.com/file/0a26268515a661149cef152d67861d5805040e23aa41ea947710ef55f26b5e0a/analysis/">a2e119106c38e09d2202e2a33e64adc9
)
  is initially dropped to the   style="font-family: courier new , courier;">%TEMP% folder and
  executed, which appears to perform code injection activity against the
  standard IE "  style="font-family: courier new , courier;">iexplore.exe"
  process and installs itself as "    style="font-family: courier new , courier;">%PROGRAMFILES%\Common
  Files\DirectDB.exe", using the   style="font-family: courier new , courier;">HKLM\SOFTWARE\STS\"nck"
  registry key to maintain state information. We can also confirm Jamie
  Blasco's (AlienVault) findings, where the malware registers
    "  style="font-family: courier new , courier;">DirectDB.exe"
  through the active setup registry key     style="font-family: courier new , courier;">HKLM\SOFTWARE\Microsoft\Active Setup\Installed


 

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 "  style="font-family: courier new , courier;">&!#@&",
    we have actually found the "    style="font-family: courier new , courier;">shiape.exe"
    process generates a mutex of     style="font-family: courier new , courier;">\BaseNamedObjects\&!#@&
    upon execution, as well
.


 

As of December 29, Microsoft released a security advisory (    target="_self"
  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:


 


      href="/content/dam/legacy/blog/2012/12/6a00d835018afd53ef017ee6c809c1970d-650wi.png"
    style="display: inline;" class="asset-img-link">      alt="Cfr-figure2"
      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     style="font-family: courier new , courier;">[REDACTED].yourtrap.comTherefore,
    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.


Source: CFR Watering Hole Attack Details

Tags: