This is a blog post featuring the TrustDefender indepth report for “Zeus Trojan Update – New Variants based on leaked Zeus Source Code” by Alex Shipp / Andreas Baumhof

1 Introduction

When the source code of the Zeus Trojan (v.2.0.9.8) leaked into the public in April this year, it was clear that this will have some serious implication for the security industry. At the time, there was speculation that this would result in a large amount of new variants, as malware writers got hold of the code and started work on their own versions.

After a period of silence, we have seen at least three new variants based on the leaked Zeus source code appearing within the last couple of weeks. None of the three variants modified the core of the Zeus code; all of them focused on AV evasion and making sure that security researchers/tools cannot easily decrypt the configuration files.

The configuration files define what a Zeus Trojan does, and are therefore the holy grail to each Trojan.

In this report, we look into great detail with respect to these new variants and what changes were introduced.

The Zeus Trojan is complicated, with more than 600 subroutines. Rather than examine the entire code for changes, this research just looks at the processes involved in obtaining a decoded configuration file. This is a useful benchmark for a researcher, because the information we are usually interested in are the sites under attack by any particular copy of Zeus, and any custom code used in those attacks. Both these pieces of information are contained in the configuration file, which is encrypted.

2 Executive Summary

The three variants that were released within just a few weeks are:

ICE IX
- This version of Zeus is claimed by its author to make life harder for tracking companies by making it more difficult for them to download the configuration file.
- This is clearly the stab at ZeuS Tracker and all security companies that try to monitor configuration files and decrypt them to provide an assessment to a brand whether they are exposed.
Registry Storage Version
- This version stores the configuration file in different locations and also attempts to clear the encryption keys in memory.
- Many configuration decryption tools search for the RC4 keys in memory which this version clearly tries to avoid.
RC4 replaced with AES
- The RC4 encryption algorithm has been replaced by AES.
- This means that all the existing tools don’t work anymore and have to be rewritten.

Three different authors have developed strains of Zeus with their own ideas of how to improve the malware. However, in each case there have been no fundamental changes to the architecture, but just small changes which are more in keeping with the way Zeus has evolved itself. With a small amount of effort, it is still possible for security researchers to obtain and decrypt the configuration files.

The worst-case scenario of a proliferation of uncrackable Zeus variants has not therefore materialised. This may still be a question of time. The effort needed for a large scale rewrite of Zeus may mean that we have to wait a while longer for the nastier variants to arrive. Alternatively, it might also mean that basing your malware on code to which security researchers also have access is a bad move for malware authors. They may have decided it is better to write their own malware from scratch, and not reuse code which may be considered compromised.

Lastly, old versions of Zeus still proliferate. Many of the samples we see are still based on the good old original source!

The picture above summarises the changes in the three versions. More detail is supplied in the following notes.

4 The Zeus Trojans in detail

4.1 Benchmark Copy

To start with, we take a brief look at a benchmark copy of Zeus to see how the configuration file could be decoded at the time of release of the source code. The benchmark copy chosen was very similar to the copies of Zeus created by compiling the source code. The following diagram summarises the steps needed to decrypt the Zeus configuration file.

Zeus Protection Algorithm

The diagram shows just how complicated Zeus has become in order to try and protect its configuration file from security researchers.

Zeus applies a permutation algorithm to its ‘BaseConfig’ data area to create a key used by the RC4 encryption algorithm.
This key is used to search the Zeus exe for a marker used to store another data area, the ‘Overlay’ area.
Once found, the key is then used to decrypt the entire Overlay data area, recovering data identified as INSTALLDATA.
This INSTALLDATA data area contains an XOR key and size information used to decrypt code which Zeus needs to carry on its execution.
Zeus now copies itself to a new location, updates the Overlay area with new data it calls PESETTINGS, and starts the new copy.
Zeus XORS its ‘BaseConfig’ data with another data area to extract a second RC4 key, and a URL.
The URL is used to download the Zeus configuration file.
The RC4 key is used as the first stage in decryption.
An XOR based algorithm called ‘VisualDecrypt’ is used to complete the decryption. The parameter file is now available, but is still stored in an internal compressed Zeus format.
The UCL decryption algorithm is used to decompress parts of the configuration file, which can now finally be viewed by security researchers.
The new copy repeats steps one to three to decrypt the Overlay area and recover the PESETTINGS data. A new RC4 key from the PESETTINGS data is used to re-encrypt the configuration file from step 8 and store it in the registry. Zeus can now use this local copy rather than downloading the configuration data each time.

Even though this is incredibly complicated, this is still a simplification of the actual process. The Zeus builder kit can vary the order and locations of all the data areas within the BaseConfig and Overlay areas so that recompiling the same source code can create a version with different characteristics.

Furthermore, most copies of Zeus are packed with one or more packers, which means that several unpacking steps need to be taken before the real work can begin.

However, we can make some simplifications as well. We said earlier that one of the goals of the security researcher was to decrypt Zeus configuration files. If this is all we need to do, then we can miss out most of the steps. Starting with a copy of Zeus and a configuration file, we only need to carry out steps 6, 8, 9 and 10 to end up with a decoded parameter file. If we don’t have a parameter file, we can carry out step 7, or even run the copy of Zeus in a virtual machine and capture the network traffic as it downloads a copy. We can use either copy of Zeus for this purpose – the original, or the new copy it creates.

The stages coloured red in the diagram illustrate this.

Most of the time, this is the situation that security researchers are in. In some cases the research might have available a compromised machine, and with it, the copy of the configuration stored in the registry, plus the changed copy of Zeus. In this case it is a little more difficult, but the parameter file can be recreated by following steps 1, 2, 3, 11, 9 and 10. Here, the copy of Zeus used must be the changed copy. The RC4 key generated in the Overlay area is unique to the machine that Zeus is on, and no other copy will therefore work. Again, the stages coloured red in the diagram illustrate this.

We can now take a look at the new versions of Zeus to see how they have affected this process.

4.2 ICE IX

This version of Zeus is claimed by its author to make life harder for tracking companies by making it more difficult for them to download the configuration file. This is claimed to prolong the life of the botnet, giving a greater return on investment. Analysis of the code shows that this is done by changing the format of URL used to fetch the configuration data. Extra data is appended which is checked for correctness before the Zeus serve will return the configuration file.

Whether this will cause the tracking companies the difficulties the author envisages is a question for consideration. The tracker site zeustracker.abuse.ch already has a blog post on the new format[1], which suggests it did not give them any particular difficulty. In any case, no matter how difficult the author makes his algorithm, the copy of Zeus can always be executed so that it will download its configuration file. This suggests that any arms race the author may choose to pursue is essentially futile.

There are other change in this version of Zeus also designed in making it more attractive to potential purchasers[2], but these are outside the scope of this paper.

The areas of change are indicated in red in the following diagram.

4.3 Registry Storage Version

This version of Zeus changes the way that data is stored in the registry. The benchmark version uses 3 subkeys with randomly generated names and stores the names in the Overlay area. This version uses many more subkeys. To avoid having to expand the Overlay area, the subkey names are generated using an algorithm which eventually produces a base 20 number which is used as the subkey name.

It is not clear if this has been done to make life harder for security researchers. It may simply be a new scheme to allow for the easy expansion of registry keys used.

The registry data is no longer protected by the VisualDecrypt algorithm. This might be because the author decided that because the 100 bit RC4 algorithm should take longer than the lifetime of the universe to crack[3], there was not much point in adding extra protection with an XOR layer.

Some attempt is also made to clear the RC4 keys in memory after usage. This may help protect against memory probes attempting to locate the key while the program is running. However, it does nothing to protect against static analysis. Also, the coverage is not complete, and some copies are not destroyed; and of course, the keys are still in memory while they are being used.

Lastly, the configuration file location is no longer stored in the same way. Instead of a single hardcoded URL, the BaseConfig data contains a series of IP addresses and ports. These are contacted on a rolling basis via a UDP based protocol. This makes it harder for security researchers to download the configuration file, although as mentioned earlier, running the bot and making it download the file itself is always an option.

As usual, changes are indicated in red.

4.4 RC4 replaced with AES

The final copy of Zeus we look at has the RC4 algorithm replaced by AES.

This replaces one algorithm uncrackable in the lifetime of the universe with another, also uncrackable in the same time span. It therefore adds nothing to the theoretical safety of the configuration file, although of course it does require security researches to add AES to their arsenal of tools, if they have not already.

Indeed, there are some minor flaws in the author’s implementation of AES, which render it less secure than it could be, and possibly less secure than the RC4 version. However, in practice they probably still leave the configuration file uncrackable with readily available technology[4], and the author can always trivially correct these flaws in the next version.

There is one area where security is enhanced. The code which was protected in step 5 by a 4 byte XOR key is now protected by AES. The XOR key was trivially easy to deduce, because the protected code did not differ much from one version of Zeus to another. Thus, by knowing what 4 of the bytes probably should be, the key can be determined in only a few tries. Encrypting with AES gives a much higher degree of protection. However, only two start-up routines are protected in this way, and knowledge of this code is not really necessary for decryption of the configuration file, or for understanding the main routines of Zeus. As before, changes are indicated in red in the following diagram.

5 More information

Please feel free to get in touch with us at labs@trustdefender.com

6 Appendix – technical details

This section looks in more details at the specific changes