Trusteer security research team identified a series of attacks carried out by a new ZeuS.Maple variant that targets customers of leading Canadian banks.

ZeuS.Maple Variant Targets Canadian Online Banking Customers


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 2.0.8.9. 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 3.3.6.0 (as seen in the configuration).

Register for the Jan. 14 webinar: 2015 Cybercrime Trends – Things are Going to Get Interesting

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:

ZeuS.Maple searches within known shell folders and generates a new file name

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.

The log of process explorer shows in the first two rows that a random file name is generated but not used

ZeuS.Maple builds its desired name out of the QueryDirectory request

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:

ZeuS.Maple calling the obfuscated function

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 code section after the call at sub_710.

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.

Ensuring browser remains patched

Important patch list on Internet Explorer:

IE patch list

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 3.3.6.0, 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):

list of targets as seen in the configuration

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:

looking for URLs that indicate e-Commerce transactions

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 62.76.190.115 –

Domain details

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

Country RU

Conclusion

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.

Topics: , , , , , , , , , , , ,

Related Content

0 comments