Ever since the ZeuS cyber crime toolkit source code leaked in 2011, malware authors have used its cogent malware development tools for generating new custom versions of the Trojan; examples include the ICE-IX and Citadel variants. Trusteer security research team identified a series of attacks carried out by a new ZeuS variant since January 2014. Seeing that this variant mainly targets customers of Canadian banks, IBM Trusteer security research team has named it “ZeuS.Maple.”

Trusteer researcher Avidan Avraham, who conducted a thorough analysis on the new variant, explains that ZeuS.Maple is a heavily modified version of ZeuS It implements unique browser re-patching techniques (browser patching is a method of stealing information from browser sessions; re-patching ensures the patch stays in place), an alternative naming generation algorithm, different anti-debugging and new anti-VM capabilities. It uses an encrypted configuration stored in the Windows registry, and in order to remain stealthy, ZeuS.Maple distribution in the wild is limited and controlled.

Avraham adds that the enhancements introduced in ZeuS.Maple are improvements of known ZeuS capabilities, but they don’t really add new functionality. This is why it is interesting that the malware author designated this variant as ZeuS version (as seen in the configuration).

Dissimulating the Executable in a New Installation Path

Most of the ZeuS-based Trojans generate a randomly named executable file and place it in a newly created folder under a randomly generated name; this makes it difficult to detect the file in the file system. ZeuS.Maple takes a different approach for naming the newly generated file: First it enumerates the %APPDATA% directory and chooses an existing folder for its dropped executable location. It then generates a file name from the combination of the directory name and a hard-coded string (a few string options exist). The new executable file is then dropped in the selected directory.

For example:

If the selected directory is c:\users\user\appdata\roaming\microsoft\

And the hard-coded string is: ‘win’

The result will be: c:\users\user\appdata\roaming\microsoft\winmicrosoft.exe

This technique of dissimulating the malicious executable within existing system paths makes the file look legitimate and enables it to stay stealthy.

The code used for the dissimulation is shown in Figure 1:

An additional piece of code found in ZeuS.Maple generates an ordinary ZeuS file name using Windows’ GetTickCount (a Windows function used by ZeuS to generate a random file name); however, it doesn’t write it to disk. It could be a leftover action from ZeuS source code.

Barriers for Malware Researchers: Anti-VM, Anti-Debugging

Malware researchers will often try to run the malware in a synthetic environment and debug it to understand how it operates. ZeuS 2.0 variants are already designed with anti-debugging features that make the malware analysis more difficult. In most cases, the variants use well-known packers that can be easily identified with common tools. ZeuS.Maple uses a unique packer that is written in Visual Basic, which is notoriously complex to debug and makes the analysis more difficult.

In addition, to prevent malware researchers from debugging the malware, ZeuS.Maple checks the value of two known Windows flags: PEB!IsDebuggedFlag and PEB!NtGlobalFlags. The code section that checks the flag value seems to be absent at first glance, but ZeuS.Maple unpacks this code section right before it uses it. In order to enable debug mode, we had to manipulate the flag value checks during runtime.

The screenshot below shows the obfuscated code prior to the unpacking function at unk_710:

After the call at unk_710 is completed, the code is readable and executable — see below. It is clear that this code section looks for flags inside the PEB and raises an exception if the process is being debugged.

The new anti-VM capabilities that were added to this variant of ZeuS are not so impressive: The malware simply checks if VMware Tools is installed on the machine (VMware Tools is a free, optional suite of utilities that enhance the performance of the virtual machine’s guest operating system and improves management of the virtual machine). To bypass this check, malware researchers can simply uninstall VMware Tools.

Browser Patching and Web-Injection

ZeuS.Maple uses browser patching to implement Web-injection functionality, which facilitates information stealing and financial fraud. Browser patching on its own isn’t new to ZeuS; however, ZeuS.Maple is the only variant that also re-patches the browser in order to protect its patches and ensure that they stay in place.

In the figure below, the code repeatedly goes over some function addresses and writes the patched function over the function address.

Important patch list on Internet Explorer:

The Encrypted Configuration

Like other ZeuS variants, ZeuS.Maple’s configuration is stored in the Windows registry. However, unlike other variants, it uses the executable name, or a GUID format string, as the name for the registry key (instead of the regular generated name). The data is encrypted with AES-128 instead of RC4 which is commonly used with other ZeuS variants. However this isn’t unique since AES-128 has been previously used with other variants. After decrypting the malware configuration, we’ve noticed that the ZeuS version ID is, which indicates that this is a brand new variant of ZeuS, as previously mentioned.

As for the targets, the main targets include 14 leading financial institutions located in Canada. In addition, it contains some “universal” attacks on URLs that consist of generic strings for e-commerce targets.

A sample of the financial institutions targeted as seen in the configuration (shown in IBM Trusteer’s format):

In addition to the listed financial institutions, ZeuS.Maple targets general e-commerce transactions but looks for URLs that contain strings like: ‘order,’ ‘cart,’ ‘account activity’ and more:

Command and Control Communication

ZeuS.Maple uses nginx-based C&C. Each server has the .in DNS suffix, and the communication is directed to the /www/ folder. The ‘.in’ suffix should be an indicator of the location of the server (India); however, when looking up the server details, we see it is located in Russia. The domain is registered under a fake name and address.

The latest active sample we analyzed communicated with C&C b1estchooseweearesame2014.in/www/ – this resolved to the IP address –

The server IP address seems to be registered to a Russian Internet service provider.


The base code of ZeuS 2.0 remains a central source for malware authors as it continues to enable the evolution of the ZeuS malware family. The ZeuS.Maple variant provides an interesting example of new and improved methods used by malware developers to bypass automated security controls as well as human malware researchers.

We expect this trend to continue as we find more sophisticated, stealthy variants of ZeuS targeting specific geographical regions.

Read the white paper: Accelerating growth and digital adoption with seamless identity trust

More from Banking & Finance

How to Spot a Nefarious Cryptocurrency Platform

Do you ever wonder if your cryptocurrency platform cashes in ransomware payments? Maybe not, but it might be worth investigating. Bitcoin-associated ransomware continues to plague companies, government agencies and individuals with no signs of letting up. And if your platform gets sanctioned, you may instantly lose access to all your funds. What exchanges or platforms do criminals use to cash out or launder ransomware payments? And what implications does this have for people who use exchanges legitimately? Blacklisted Exchanges and Mixers…

Kronos Malware Reemerges with Increased Functionality

The Evolution of Kronos Malware The Kronos malware is believed to have originated from the leaked source code of the Zeus malware, which was sold on the Russian underground in 2011. Kronos continued to evolve and a new variant of Kronos emerged in 2014 and was reportedly sold on the darknet for approximately $7,000. Kronos is typically used to download other malware and has historically been used by threat actors to deliver different types of malware to victims. After remaining…

Why Cybersecurity Risk Assessment Matters in the Banking Industry

When customers put money in a bank, they need to trust it will stay there. Because of the high stakes involved for the customer, such as financial loss, and how long it takes to resolve fraud and potential identity theft, customers are sensitive to the security of the bank as well as fraud prevention measures. Banks that experience high volumes of fraud are likely to lose customers and revenue. The key is to protect customers and their accounts before problems…

Cost of a Data Breach: Banking and Finance

The importance of cybersecurity has touched almost every industry. Beyond that, robust cybersecurity is table stakes for several sectors, particularly health care and the banking and finance industry. Not only is financial data at risk, but so is customer trust. In banking and finance, trust means everything. Yet, consumers are hesitant to share their confidential data. A recent McKinsey survey revealed that no industry achieved a trust rating of 50% for data protection. Here’s the most sobering stat: 87% of…