A New Wave Of WIN32/CAPHAW Attacks - A ThreatLabZ Analysis

Over the last month, the ThreatLabZ researchers have been actively monitoring a recent uptick in the numbers of Win32/Caphaw (henceforward known as Caphaw) infections that have been actively targeting users' bank accounts since 2011.  You may recognize this threat from research done by WeLiveSecurity earlier this year in regards to this threat targeting EU Banking sites.  This time would appear to be no different.  So far, we have tied this threat to monitoring it's victims for login credentials to 24 financial institutions.

The Caphaw trojan is a financial malware attack that functions similarly to the Carberp, Ranbyus, and Tinba threats according to analysis done by WeLiveSecurity Researcher, Alekandr Matrosov. These attacks are carried out utilizing stealth tactics both on and off the wire.  Caphaw avoids local detection by injecting itself into legitimate processes such as explorer.exe or iexplore.exe, while simultaneously obfuscating its phone home traffic through the use of Domain Generated Algorithm created addresses using Self Signed SSL certificates.  This limits the ability of traditional network monitoring solution to dissect the packets on the wire for any malicious transactions.  Caphaw attacks major European banks and previous analysis has shown that the malware is most active in the UK, Italy, Denmark and Turkey. This is especially prevalent considering the mapped known infected nodes seen here. 

The geoip (location) information derived from the infected host is of special significance to this malware. The malware leverages the following legitimate URL: hxxp://j.maxmind.com/app/geoip.js to discover geoip information about its freshly infected victim.  Administrators should view this transaction as a starting point for their investigation into any suspicious activity. It is not a malicious service, but illustrates how malware writers can leverage even legitimate services. The infection uses the output of this script to extract location information about the infected host/victim.

 

At the time of research, we were unable to identify the initial infection vector.  We can tell that it is more than likely arriving as part of an Exploit Kit honing in on vulnerable versions of Java.  The reason we suspect this is that the User-Agent for every single transaction that has come through our Behavioral Analysis (BA) solution has been: Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_07.

 

The variation in the dropped executable is different across every instance, so its no wonder standard AV is having a problem keeping up (1/46 at time of research). This AV performance also indicates that the likelihood of someone proactively catching this infection inside their network is fairly low at the time of this writing.

What initially drew us to this threat was the use of DGA following the execution of the dropped malicious package. We ran three test instances of the attack sequence in our Behavior Analysis (BA) lab to illustrate the use of DGA in the malware's attack sequence:

 

 

 

 

The pattern ("ping.html?r=") is commonly known to be used by past versions of Caphaw.  Don't panic straight away if you see this string in your user logs however as it is also commonplace among sites that use "outbrain.com" services.  You'll want to look for any URI path that uses /ping.html?r= that does not contain "/utils/".  Hopefully that helps narrow the search to see if you've encountered transactions similar to the following screenshot.

Across all 64 distinct samples we've collected of this threat thus far, there have been 469 distinct IPs where there has been a call to a DGA location.  A small sample of those illustrate the connection between the phone home data collected via network logs and the BA of the Caphaw samples.

 

 

The initial indicators were in the form of mysterious self-signed SSL traffic between end user hosts and various points of presence on the Internet, potentially components of the malware’s CnC infrastructure.  See the screenshot below showing the self signed SSL cert. used in the malware communication:

Other screenshots below show the SSL handshake between the infected hosts and the remote CnC servers:

SSL communication between infected host(s) and the remote CnC servers

A binary executable (.exe) file is created in the attack sequence and masquerades as a .php file. This executable is created using Microsoft Visual C++ and the creator has not removed the debugging information from the final executable.

Both the location of where this file is dropped and the name of the file itself is selected quasi-randomly. For example, in one of the test instances we found this to be: 

C: Documents and Settings\user\ApplicationData\Sun\Java\Deployment\SystemCache\6.0\9\typeperf.exe

 

During the three instances of malware execution we ran in our BA lab, we observed the following executables and their drop locations:
 

 

 

The malware makes the following significant API calls: 

 

Further, the executable when run, modifies the explorer.exe process to ensure that it's self-signed certificates are not cached and it also hides inside the explorer.exe process to ensure that the protection banner is hidden for a stealthier execution: 

Further evidence of this being Caphaw exists in the banking information that it is listening for once it is injected into key Windows Processes.  Amongst all samples analyzed, we found the following 24 major banks' sites were actively being monitored by the infection primarily to seek out the victim's online banking credentials. This is based on data pulled from an added thread to explorer.exe process.

Strings found in explorer thread added by Capchaw

ThreatLabZ continues to monitor the Internet for this threat and it's propagation. The lab is also engaged currently in dissecting this threat further in order to obtain more information about its attack methodology, scope and impact. 

Written by Sachin Deodhar & Chris Mannon (ThreatLabZ)