The more people switch to 64-bit platforms, the more 64-bit malware appears. We have been following this process for several years now. The more people work on 64-bit platforms, the more 64-bit applications that are developed as well. Sometimes these include some very specific applications, for example, banking applications.... If someone wants to hack into an application like this and steal information, the best tool for that would also be a 64-bit agent. And what's the most notorious banking malware? ZeuS, of course - the trendsetter for the majority of today's banking malware. Its web injects have become a fundamental must-have feature of almost every banking malware family. And it was only a matter of time until a 64-bit version of ZeuS appeared - but we didn't expect it to happen quite so soon.
That's because cybercriminals don't actually need a 64-bit version. ZeuS is mostly intended to intercept data passing through browsers, and modify that data allowing the operator to steal information related to online banking, to wire transactions or to cover his tracks. But nowadays people still use 32-bit browsers - even on 64-bit operating systems. So, 32-bit versions of ZeuS have been sufficient to keep the thieves satisfied with their earnings.
Then, out of the blue, we spotted a 32-bit ZeuS sample maintaining a 64-bit version inside. And it's turned out that this 64-bit version has already been recorded being present in the wild at least since June, 2013 and compilation date specified in the sample is April 29, 2013! Moreover, this ZeuS version works via Tor. The initial 32-bit sample injects malicious code into target processes. If the target process belongs to a 64-bit application, ZeuS injects its 64-bit version into the process; otherwise, it pushes the 32-bit version. We ran tests to see how the 64-bit ZeuS works inside a 64-bit Internet Explorer and it demonstrated the usual ZeuS functionality: in any case, the web injects functioned as usual.
There is one bank whose online banking page address ended up in the web inject rules for this version of ZeuS. One web inject rule reads:
<input id="e_finance_login" class="button" type="submit"
meaning that when a victim visits the bank's online banking page and the HTML code of that page contains a string after the tag "data_before", ZeuS inserts additional text after the tag "data_inject" immediately after the initial target string. When visiting this page during an active ZeuS infection in 64-bit Internet Explorer we observed the following malicious insertion in the HTML code in the browser:
Code injected into an online banking page in 64-bit IE
The malicious function gotoo() is specified in another web inject rule for this site, and is added to the HTML code of the banking page along with other malicious code. This function gathers some valuable information from the page (login, password, cookies, and other special values specified on the page) and sends it to a domain controlled by the ZeuS operator.
So, the 64-bit version of ZeuS works. But are there really that many users who have migrated to 64-bit browsers to justify the effort that has gone into creating a 64-bit version of ZeuS? Nope, it's simply not the case - the proportion of users running 64-bit browsers is still negligible. According to our stats, for example, the share of users browsing with 64-bit IE is less than 0.01%. So why has some virus writer compiled a working 64-bit version of ZeuS? Admittedly, it doesn't look too complicated from our side - the source code is available, some fixes are required to make it work in 64-bit processes and to compile it as a 64-bit application. Maybe that isn't actually the case, and it requires a lot more effort to make a working version of a 64-bit ZeuS. After all, we did notice a bug in the current version: when ZeuS injects a 64-bit counterpart into the 64-bit process of the EMET Notifier application it causes this process to crash. This is due to an error in the calculation of some of API function addresses - the ZeuS instance inside the EMET Notifier process tries to call the WSAStartup function, but the variable that should contain this function address does not point to this function. Instead, it points to non-allocated memory that causes a whole EMET Notifier process to generate the "Access violation" exception and terminates the process.
EMET Notifier crash due to buggy code in ZeuS x64
If it's actually not so straightforward to create a reasonably stable 64-bit version of ZeuS and the vast majority of users are still using 32-bit browsers, then it begs the question: why bother? Perhaps it's just a marketing gimmick - a new feature, even if it is mostly useless, with a bit of 'wow' factor! Support for 64-bit browsers - a great way to advertise the product and to lure buyers - the botnet herders.
Interestingly, the configuration file for this version of ZeuS includes a long list of programs that the malware can function on if they are found on the infected system. There are different types of programs, but all of them contain valuable private information that cybercriminals would love to steal - login credentials, certificates and so on. Don't forget that ZeuS is capable of intercepting key strokes and data before encryption/after decryption that is sent/received on a network with the use of some typical system API functions. So, when operating inside these programs ZeuS is able to intercept and forward a lot of valuable information to the botnet operator. The entire list of programs specified is presented below:
Apart from the inclusion of the 64-bit version and CnC communication via Tor, this ZeuS behaves like any other ZeuS-based malware. It drops its files in folders with randomly generated names in the %APPDATA% directory under random file names:
ZeuS local drop zone
The persistence is achieved in the usual way for Zeus by creating a value in the system autostart Run key in the registry:
ZeuS is registered to run at system startup
The internal version of the malware specified in the bot body is 188.8.131.52, which actually means nothing. It's definitely not a third generation of ZeuS as the malware author would have us believe. The process of downloading the configuration file suggests this version is closer to the initial leaked source code of ZeuS 184.108.40.206 than, for example, it is to the Citadel branch. The Citadel version got rid of simple access to the configuration file and its CnC only allows it to be downloaded using an accurate HTTP POST request when the CnC of this ZeuS version does not prevent the downloading of a configuration file by simple URL request to the file path. So anyone who knows the correct URL can download it with using browsers, wget, curl, etc.
Besides 64-bit component, this version of ZeuS maintains a tor.exe utility from the 0.2.3.25 version inside its body. Tor.exe is launched indirectly - ZeuS starts the system svchost.exe application in suspended mode, then injects the tor.exe code into this suspended svchost.exe process, tunes the code to run properly and resumes execution of the suspended svchost. As a result, instead of the system svchost.exe, the process actually starts executing tor.exe.
The Tor utility under the cover of the svchost.exe process creates an HTTP proxy server listening to the TCP port 9050.
Tor proxy running as svchost.exe process
So, for example, if you adjust the browser on an infected host to work via proxy 127.0.0.1:9050, all the browser traffic will go through the Tor network. The CnC server of this ZeuS version is located in the onion domain: egzh3ktnywjwabxb.onion. So when the malware communicates with its CnC, it pushes requests via the aforementioned proxy, successfully reaching the Tor network and subsequently its CnC.
Moreover, ZeuS creates a Tor hidden service on the infected machine, passing on the following parameters when it starts tor.exe:
--HiddenServiceDir "%APPDATA%\tor\hidden_service" --HiddenServicePort "1080 127.0.0.1:" --HiddenServicePort "5900 127.0.0.1:"
Basically, these parameters are intended to specify how to run the hidden service (onion web server) on specific machines. HiddenServiceDir defines where the configuration of the hidden service is located locally, and HiddenServicePort defines how to redirect users connecting to your onion domain to your web server running locally. Users typically connect to web domains on port 80 which is assigned to the HTTP protocol, but your web server could accept incoming connections to another port, for instance, 1080. In this case, tor.exe needs to be started with following parameter:
--HiddenServicePort "80 127.0.0.1:1080"
meaning that when users connect in the usual way via the browser to .onion, they reach your machine where tor.exe accepts a connection on port 80 and redirects it to port 1080 on the local machine which is listened to by the web server. As a result, users connect to your web server.
But in the case of ZeuS there is most likely no single web server running on infected host. So, why would malware want to roll out a hidden service in addition to this port mapping to random ports? The answer lies in ZeuS itself. It creates a tor configuration folder for each infected host, generating a unique private key for the hidden service and, consequently, an exclusive domain name. In turn, tor.exe enables the hidden service with a unique onion domain name.
Created by ZeuS configuration tor folder
Created by ZeuS configuration tor folder
Example of generated domain related to infected host
When running in an infected system ZeuS listens to the ports that were generated randomly and remembered during the first launch of malware. The botnet operator will be aware of the generated onion domain related to every infected machine as the malware informs the CnC about its tor domain name. So, when an infected machine is online the botnet operator can reach it connecting to its unique onion domain via the Tor network. One purpose of this approach is the remote control of the infected host. For example, one of these ports specifically listens to in the VNC function of ZeuS, obviously meaning that ZeuS provides remote desktop control to the operator via this port.
However, ZeuS working via Tor is nothing new. We have tracked ZeuS samples with signs of Tor communications that date back to 2012 when, along with a ZeuS infection, the Tor proxy and Tor hidden service were rolled out on infected machines. There are even step-by-step instructions on the Internet on how to use tor.exe to pass ZeuS or Spyeye traffic via the Tor network as well as how to create onion domain hosting for a CnC for these banking Trojans. But these earlier samples mostly had CnC domains specified in their bodies as localhost or 127.0.0.1 meaning that samples of ZeuS or Spyeye themselves were not tied too strictly with Tor communications, whereas the version of ZeuS described in this blog post has CnC onion domain egzh3ktnywjwabxb.onion defined in its internal block of settings. And tor.exe is included directly in its body and is run by ZeuS itself. So Tor communcations and the 64-bit version are inseparable parts of this ZeuS sample, with the functionality included at the very development stage.
Whatever the intentions were of the malware author that created this piece of ZeuS - be it a marketing ploy or the groundwork for some future needs - a pure 64-bit ZeuS does finally exist, and we can conclude that a new milestone in the evolution of ZeuS has been reached. Moreover, this sample has revealed that another distinct feature has been added to ZeuS functionality - ZeuS malware has the ability to work on its own via the Tor network with onion CnC domains, meaning it now joins an exclusive group of malware families with this capability.
We detect 32-bit ZeuS samples in question as
Trojan.Win32.Scarsi.uhm - 52d3b26a03495d02414e621ee4d0c04e
HEUR:Trojan.Win32.Generic - b33d3509ce930bcc796a9e2904f426d7
64-bit ZeuS sample extracted from aforementioned 32-bit samples as
Trojan-Spy.Win64.Zbot.a - cc793e5b0df621b8d572cf4e7f26e053