Category Archives: in-depth report

Man In The Browser: Mac OS X Edition: 1 of 3

1         Introduction

In one of the recent TrustDefender Labs reports (“Man-in-the-Browser 101 or it works as designed (Win & Apple Mac) – we gave a brief over-view of what a Man In The Browser attack was all about, and in that discussion we briefly touched on Man In The Browser (MITB) attacks on Mac OS X. But is this really plausible?

The reputation for Apple’s OS has been that its more secure and doesn’t suffer these problems. Well, we have touched on, and debunked this myth earlier, but the malware examples we have looked at have all been pretty unsophisticated. So maybe there is something in this idea of a more secure OS? Well, given the title of this article, you can guess that’s not true!

We will be looking at three different ways that MITB can be achieved on Mac OS X as well. The most interesting fact is that it is actually fairly easy to do and works exactly the same way as on Windows. Given the detailed knowledge of MITB from the fraudsters on Windows, one can only assume that they have the knowledge as well on Mac and it is only a matter of time before they maintain two complete different versions of their trojan, perhaps with a shared configuration.

2         Browser Hooking

In the previous article, we talked about function hooking, and, although that article was focused on Windows, the concept is exactly the same for Apple OS’es. The basic idea is simple. When the web browser calls a system function, we re-route the call to execute our code first.

We have identified three different methods for getting our code to be called before a system function is called. This list is not exhaustive by any means, and we will cover each in turn in a later in-depth report, but the point is there are multiple ways of achieving this goal.


  1. Library overloading using DYLD_LIBRARY_PATH
  2. Function overloading using DYLD_INSERT_LIBRARIES
  3. Code injection

The first two of these use features made available by the dynamic linker, and the last is a more complicated method where we inject some code directly into another processes memory.  However, regardless of which of method is used, they all rely on the same basic idea. Rather than directly calling a system function, we first call our function first. Like this:

We will cover lazy linking, and explore in more detail the details this image shows in a later article. For now, its enough to know that the system used to resolve symbols in shared libraries, can be perverted and used to call our code instead. All three of the mentioned methods exploit this mechanism, albeit in slightly different ways. Typically, in this situation, the injected code will do its thing, and then call the original system code, so the system call still does what it needs to for the process to run (at least apparently) correctly.

2.1       Results

So, now we get to the interesting part! We have the pieces in place, we just need to figure out the appropriate places to hook, and inject our code. The details of this aren’t really important here, but suffice to say its not a big issue to figure these things out. For MITB malware, we need to find a function that is called to retrieve network traffic, ie our HTML content, from the network. And, if we hook at the right place, we can get access to html content before its encrypted and sent, and also after its received and decrypted. This means that SSL doesn’t help protect the content. We can then add whatever content we like… and we can do all this with no special access rights!

This sounds very familiar from all the MITB trojans on windows such as Zeus, Spyeye, Carberp, Gozi, Mebroot,… And yes, exactly the same thing is easily doable on Apple Mac OSX as well.

So how does it look like?

Note the https url, the lock symbol indicating a secure session… and the extra form field in the sign on section. In case you aren’t familiar with citibank’s sign on page, the relevant section of the same site without our hook looks like this:


Note that we picked citibank for this exercise simply because they are a well known bank. There is no inherent flaw in their website (that we know of, anyway), its a fairly typical banking site, secured with SSL and a certificate from a trustworthy CA (whatever that means in these days!).

Its also worth noting that the code required to inject an extra form element into the page was of medium complexity and highly targeted to this particular website. This was mentioned in an earlier article that suggests the meaningful Intellectual Property is in the configuration file rather than the code injection method. All major MITB trojans share the same “Zeus style” web-inject configuration format to target many brands at the same time. This is where the real value of a MITB lies, and given its brand-specific, is no tied to the delivery platform at all.

All three methods outlined in this report will result in the same compromised page where 99% of the content comes from citibank, but some additional form fields or malicious JavaScript fragements are injected locally – even though EV-SSL is used and the padlock is visible.

The above results are possible using all three methods.

2.2       What next?

Over the next few articles we will look in greater detail at the 3 methods of hooking mentioned above. We will also touch on the security features available in Mac OS X (10.6 and 10.7) and how effective they are for this kind of attack.


Zeus Code Update Part 2 – Who is behind the recent changes?

Executive Summary

In our TrustDefender Labs report last month, we looked at different samples of the notorious Zeus trojan that are based on the leaked source code. We focused on the changes the authors did to the encryption of the configuration files in order to circumvent automated detection tools and to stay undetected for longer. So the analysis was quite limited to a fairly narrow set of changes.

This time, we look at similar Zeus trojans from a different angle. We consider the entire set of changes and we try and estimate the complexity of those changes, which may give us an insight into the level of understanding shown by the respective authors when altering the Zeus source code.

Much to our surprise we were able to conclude that these changes were made either by the original Zeus author or by authors who know the source code very, very well and are specialists in developing malware.

In any case, the release of a series of versions, with quite substantial changes, shows that whoever is working on the code is quite capable of making extensive and sometimes fundamental changes in a short space of time.

We can therefore expect the pace of development to continue into the future, and even if the original author is no longer working on the code, we expect further versions to emerge at short intervals.


Rather than looking in minute detail at every routine, which would be painstaking, and take too long to be viable, we look at the overall interactions between functions – which functions call other functions, and we then map that call pattern back to the reference copy of Zeus at the time of the source code release. This lets us see which new functions have been introduced, which have been deleted and which have been changed.

This is a much smaller problem, is possible to automate, and still gives us a good feel for the changes made. There are still some challenges – for instance, the way Zeus is built means that sometimes several functions are folded into one, and sometimes they are not. This is done by the Zeus author to evade detection from signature scanners. Also, some functions are interchangeable, so any of a set may be called. Lastly, compile-time defines can be used to include or remove functionality, possibly so that some functions can be sold at a premium.

However, we can compensate for all these.

Once this is done, we can then take a more detailed look at a smaller set of functions that stand out as a result of this analysis.

This approach does not pick up all changes – for instance, small changes in logic in functions do not affect the flow, and may not therefore be picked up. However, even with this limitation, the results are useful.

The IDA Pro program was used extensively in this analysis, as this has a great deal of functionality enabling the cross referencing of functions.

Benchmark Copy

We used a benchmark copy of Zeus to compare the other copies to. The copy was chosen to be very similar to the copies of Zeus created by compiling the source code. However, it is an in-the-wild copy – we did not create it by compiling the source code.

It is though not an exact map to the source code, and therefore we also took care to compensate for this in our analysis.


The copy of ICE IX we used had MD5 checksum of 62f770d7db6dd6825b793ec5c456d7e2 and a size of 99840 bytes.

When we analysed this copy we found it was generated from 58 source modules which contained 634 routines . All of the source modules were present in the original Zeus source. Of the 634 routines, only one of them could be said to be new code. All the others were from the original Zeus source code, and although there may have been minor logic changes to these, in essence, the code remains the same.

The one routine added was not complex, being a string manipulation routine to convert a 16 byte hash to an ASCII string.

We would have to class ICE IX as containing only the most basic of changes, which could be done with little understanding of how the Zeus code fits together.

In addition, though we did not verify this ourselves, it has been reported elsewhere  that the author has also introduced a string handling bug which causes a memory leak.

Ironically, this sample turned out to be closer to the Zeus source code than the representative sample we had been previously using.

RC4 replaced with AES

The next copy of Zeus considered is the one where the RC4 algorithm was replaced by AES. The sample used had an MD5 hash of d67d38800d6463d3db835f64224654e6 and a size of 200192 bytes.

The sample contained 655 routines in 59 modules. There was one new module introduced, which contained 11 functions used to disguise kernel calls.

In total there were 23 new functions. The other new functions w ere added to existing modules. 3 were added to the CoreInject module to handle thread injection, and 9 to the Crypt module to replace the RC4 algorithm with AES.

This is a much bigger set of changes than with ICE IX.

However, there are still some interesting points.

As noted in our previous paper, there are some anomalies with the way the AES algorithm is called. AES is only ever used to encrypt 16 bytes at a time, never the entire block to be encrypted. This suggests that the author was unfamiliar with the AES code which is imported. The likelihood is that it was found somewhere on the internet and just copied in. The net effect is that the new encryption is technically weaker than the old.

The new module disguises the  way that kernel calls are made. It does this by pushing Kernel module names onto the stack, and then searching the stack to match the names with hash values. This is nothing new – malware has been doing this for a long time; indeed, I remember using this as a technique to detect if a program is malicious several years ago. This therefore adds nothing to the security of the malware, and makes it more likely, not less likely that it will be detected by security programs. It also does not fit in with the ‘ethos’ of the rest of the malware. Everywhere else, if a string needs to be disguised, then the CryptedStrings routine is used. The disguise is also not used consistently. Only a few kernel calls are protected in this way, with no obvious reasons why these should be selected over other system calls. In short, this may be another piece of pre-existing code that the author has imported.

Lastly, the three thread handling routines are very similar to the old thread handling, but use the new module to disguise some of the system calls.

Overall, more knowledge of the Zeus architecture was needed to make these changes than for ICE IX, but they are still not substantial.

Registry Storage Version

The sample used had an MD5 hash of 8807fbdc494e946e25bfdad74cd756d9  and a size of 169984 bytes. It was obtained from the wild – the only one of the three samples where this was the case.

This version of Zeus changes the way that data is stored in the registry and as other researchers have noted, also uses a peer to peer network as its command and control infrastructure.

It contains 79 modules and 788 routines. It is therefore immediately apparent that the changes are on a whole different scale than the other two samples, with 21 new modules and around 241 new routines.

As well as the new functionality, some of the existing modules were almost completely rewritten, most notably the socket handling. Altogether, 110 old routines were retired, and 137 routines were altered.

There has also been some rationalising of code, with the hash routines and random number handling code moved out of the Crypt module into their own modules, and the PESETTINGS  code moved from the Core module into its own module.

The new routines incorporate quite substantial changes. A brief summary follows.

The registry code has been altered to change the name registry subkey names are generated. Previously, only three keys were used, their names were randomly generated, and a note of the keys used was stored in encrypted form in the PESETTINGS area. Now the keys used are string representations of base 20 numbers. There is a complex algorithm, described in our previous paper, used to generate these numbers. This allows more data to be stored in the registry, which may have been needed as a result of the changes to the communications architecture.

The communications architecture has been changed to use a peer to peer network. Other researchers  have noted that this appears to be based on the Kademlia protocol. This means that the botnet is more robust, and cannot be taken down so easily. This change will also require a change to the C&C code to also use the new peer to peer architecture.

The Mersenne Twister algorithm has been added to the random number code.  This may have been copied from code available on the internet – a Google search found the exact same code. It is not clear that the author understands the purpose of the algorithm. It is intended to generate random number sequences. However, in the code it is just used to transform the random number generated by the original code into a different random number.

The crypt code has been changed to allow for the easier use of different encryption algorithms. Currently this is not actually used, so may be a preparatory architecture change for future versions.

Several new kernel calls are hooked
  • nspr4.dll::PR_Poll
  • wininet.dll::InternetSetOptionA
  • wininet.dll::InternetSetStatusCallback
  • wininet.dll::InternetSetStatusCallbackW
  • ws2_32.dll::WSARecv
  • ws2_32.dll::recv

The HTTP inject mechanism has support for regular expression matching added. This also means that the way that configuration data controlling this activity is stored is changed. Previously this was stored in the configuration area using an ID of 20007. The new data is stored in a different format using ID 30003. Items are separated using the ‘magic’ data ‘ERCP’. This may stand (when little endian reversed) for Perl Compatible Regular Expression. Items with ID of 30004 and 30005 were also added. These changes will also need a change to the Zeus configuration builder code, so that the new formats of configuration data can be packaged.

Code has been added to rebuild the import table, and also to adjust it after any kernel hooks are removed. Code has also been added to adjust any relocation entries during the routine decryption process, which will otherwise stop the decryption failing if the program is loaded anywhere other than 0×400000.

There is some special code to handle two security urls and set a cookie:
  •  https://*/ebc_ebc1961/ebc1961.asp*=RemoteLogon*
  •  https://securentrycorp.*/Authentication/zbf/index?*domainId=*
The overall impression is that there are a large number of changes that have been made to quite different areas of the program, and that the person doing this was very familiar with the architecture of Zeus. The changes made are sympathetic to the way Zeus ‘does things’.

Other copies of Zeus

During the investigation, we also noticed that several routines in this copy of Zeus were also present in earlier copies we got from the wild. This suggested some other lines of research. It’s possible to get some idea of the evolution of malware by looking at the changes from version to version.

If we see two copies with the same changes, then this will not have occurred by chance. The most likely scenarios are that either the same author has produced the two versions, or that two groups of malware writers are sharing source code with each other.

We were able to find four in-the-wild copies of Zeus which showed a distinct evolution. The first copy was from June 2011. The next copy was the copy under analysis, which was from September 2011. Two further copies were from October 2011.

The June 2011 copy contained 700 routines. It changed the way  the HTTP inject mechanism happens, and the way that configuration data controlling this activity was stored, introducing ID 30003 and others. The way the botnet C&C was contacted changed, with alternative URLS being generated and tried on a daily basis if the original C&C becomes unavailable.

The September 2001 copy contained 788 routines. It added base 20 registry key naming, peer-to-peer networking.

The two October 2011 copies are still awaiting full analysis. However, they added a third routine to the collection of encrypted subroutines . This requires corresponding changes to the builder program that creates Zeus, and is not a trivial change. They contained 833 and 823 routines.

Regular Expression Handling

The fact that the copies all contain regular expression handling is very interesting. The version of source code released was However, regular expression handling was only added to Zeus in version 2.1, which was released around October 2010 .

We therefore went back again in our archives and located a copy of the 2.1 Zeus release to compare the regular expression handling. It was effectively identical.

This means that someone out there has the 2.1 source of Zeus, which was never publically released, and is still actively working on it.

Is the original Author Still Active?

From the changes we see that there is intense ongoing development with this branch of Zeus.

We now stray into the realms of conjecture. Someone has access to the source code for the 2.1 version of Zeus which was never publically released. This person making these changes is obviously very familiar with the Zeus architecture and has made complicated changes. The replacement of the communications architecture with the peer to peer architecture is a non-trivial change and requires back end changes to the C&C as well. The addition of a third encrypted subroutine requires changes to the build process. The addition of a new format for the configuration inject data requires changes to the configuration packaging code. These indicate the author has an understanding of the whole Zeus package, not just the malware client itself.

The way the changes are made is sympathetic to Zeus. The modules added contain small numbers of routines and are logically organised. The CryptedStrings routines are used to hide interesting strings from casual view. Often when a new person takes over maintenance of code, they start doing things in their own preferred way which is different to the original author.  However, this does not appear to be happening here.

The copies are in the wild, suggesting a buyer or buyers are readily available.

The Zeus source code was released around the weekend of 7th May . The first version of this new branch of Zeus was detected at the beginning of June 2011 – less than one month later. This is a very short space of time for someone new to Zeus to read and understand the code, and then to create such an extensive derivative work.

We have to wonder therefore, if this is actually still the work of the original author. He announced his retirement, and released the source code. However, this may have just been a smokescreen. Certainly, whoever is continuing to maintain the Zeus code is very familiar with the whole Zeus environment, not just the malware itself. It could also be someone who has worked closely with the original author in the past, or who the author has trained up to take his place.

Are there any signs that this might not be the original author? Well, possibly. In the June 2011 version, the new configuration data handling introduced two memory handling subroutines that were placed in their own module, and not in the standard memory handling module. The fragmenting of routines into different modules is also arguably finer-grained than with the original code.

As with all such guesses, only time will tell. All we can do now is sit back and wait for further information.


The first two copies analysed have fairly trivial changes which are (in my opinion) not the work of the original author.

The third copy is far more interesting. There is a case to be made from the availability of 2.1 source code, the complexity of changes, and the short period between the release of the source code and the emergence of versions of this variant, that the original Zeus author is still at work.

This is still conjecture at this point, and it may also be due to other authors familiar with coding this type of malware.

In any case, the release of a series of versions, with quite substantial changes, shows that whoever is working on the code is quite capable of making extensive and sometimes fundamental changes in a short space of time.

We can therefore expect the pace of development to continue into the future, and even if the original author is no longer working on the code, we expect further versions to emerge at short intervals.

Applications used

The applications used to research this document were:
  • IDA PRO 6.2
  • ActiveState Perl
  • 010 Hex Editor
  • Editplus text editor
A series of IDA scripts and perl programs were used to auto-analyse each Zeus sample and create a cross-reference listing of routines. A further series of perl programs were then used to analyse and compare the cross reference listings.

New IceIx (Zeus variant) changes its encryption method (again)

Executive Summary

In our last in-depth report we looked at enhancements of the notorious Zeus trojan that focus solely on making life harder for automated detection tools and tracking software. We looked at three variants that are based on the leaked source code. The fear is that a proliferation of too many different variant will make life harder to detect and track the various trojans.

One of the variants is called IceIx and on October 13 we noticed the presence of a new in-the-wild IceIx Zeus variant. We therefore decided to take a brief look. The sample had a size of 169,984 bytes and an MD5 of ed34b46a4524c7d05e45200eaf09f765. It contained exactly the same number of routines at the previous variant, 634. There were minor changes to around 20 of the routines, the rest were unchanged.

As you’ll see below, the changes are minimal, but the result is that all automatic decyrption routines will fail!

Well, it seems that the bad guys continue to “tweak” the encryption algorithm and the arms race continues up until we finally implement some proactive solutions rather than reactive countermeasures.

RC4 Variant

This version of Zeus is very similar to the initial ICE IX release, but has the RC4 algorithm tweaked. In the standard algorithm, a 256 byte ‘state’ table is initialised with the RC4 key, and the data is then decrypted as follows.

The modified algorithm changed the way the x and y values are altered.

The areas affected in the decryption process are indicated in red in the diagram (please see our previous paper[1] for an explanation of the processes).

Although the areas affected seem extensive, in fact only a trivial change is needed to the rc4 algorithm for a security researcher to be able to decrypt the configuration file.

Notes on altering a Cryptographic Algorithm

For a layman to alter a cryptographic algorithm is usually bad. Seemingly trivial changes may introduce flaws that a cryptographer can exploit, and the chances are that the resulting output may be less resistant to cryptographic attack.

For a Zeus author, a slight lessening of cryptographic resistance probably does not matter. After all, the key and algorithm is provided with the Zeus source anyway. The end goal is to make life harder for a malware analyst, not a cryptographer, and so in this case the trade off is presumably acceptable to the author.

Configuration file download

The previous variant added extra parameters, ‘id’ and ‘hash’ to the HTTP command used to get the configuration data. This version changes the names of the parameters to ‘bn’ and ‘sk’.

The configuration file available at the ZeusTracker site has a version number 0×01010500.


The botnet name used by this variant is rotewa11.


It seems as though this Zeus author has found at least one buyer even though his changes to Zeus are minor. Is seems that advertising does pay, even for malware.

This is the first time we have seen a Zeus variant using and altered version of a standard cryptographic algorithm, although no doubt it will not be the last.



Zeus Trojan Update – New Variants based on leaked Zeus Source Code – TrustDefender indepth report

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. 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.

  1. Zeus applies a permutation algorithm to its ‘BaseConfig’ data area to create a key used by the RC4 encryption algorithm.
  2.  This key is used to search the Zeus exe for a marker used to store another data area, the ‘Overlay’ area.
  3. Once found, the key is then used to decrypt the entire Overlay data area, recovering data identified as INSTALLDATA.
  4. This INSTALLDATA data area contains an  XOR key and size information used to decrypt code which Zeus needs to carry on its execution.
  5. Zeus now copies itself to a new location, updates the Overlay area with new data it calls PESETTINGS, and starts the new copy.
  6. Zeus XORS its ‘BaseConfig’ data with another data area to extract a second RC4 key, and a URL.
  7. The URL is used to download the Zeus configuration file.
  8. The RC4 key is used as the first stage in decryption.
  9. 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.
  10. The UCL decryption algorithm is used to decompress parts of the configuration file, which can now finally be viewed by security researchers.
  11. 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 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


 6 Appendix – technical details

This section looks in more details at the specific changes

6.1 Ice IX

The sample used had a size of 99840 bytes and an MD5 checksum of 62f770d7db6dd6825b793ec5c456d7e2.

More information can be found in the TrustDefender Labs report. Please email us at to get a copy.

6.2 Registry Storage Version

6.2.1 Registry Changes

More information can be found in the TrustDefender Labs report. Please email us at to get a copy.

6.2.2 EnterCriticalSection/LeaveCriticalSection blocks

More information can be found in the TrustDefender Labs report. Please email us at to get a copy.

6.2.3 Hash Algorithm

More information can be found in the TrustDefender Labs report. Please email us at to get a copy.

6.2.4 Crypt handling

More information can be found in the TrustDefender Labs report. Please email us at to get a copy.

6.2.5 UDP Connection

More information can be found in the TrustDefender Labs report. Please email us at to get a copy.

6.3  AES Encryption

More information can be found in the TrustDefender Labs report. Please email us at to get a copy.



[3] Cryptographers are welcome to disagree with this cavalier statement. And of course, today’s uncrackable algorithm can become instant junk if advances in cryptographic theory or computing technology occur.

[4] Although I haven’t collared a tame cryptographer to verify this

Man-In-The-Browser 101 or “it works as designed” (Win & Apple Mac)

1 Executive Summary

Everybody is talking about Man-In-The-Browser (MITB), so I thought we’d do a little 101 session on how these Man-In-The-Browser Trojans work. As there is way too much focus on the big guns such as Zeus/SpyEye out there, I thought we’d use one of the less known Trojans as an example and even discuss the implications on Mac OS X as well.

While the exact details are different, Man-In-The-Browser threats are also valid on Apple’s OSes (on iOS, sand-boxing and signing makes things pretty difficult, theoretically not impossible, and a lot easier if the device is jail-broken).

2 Introduction

For this paper, we’ll use a sample with MD5 of 3618ff28e3c0d48a09dbae5b5b42585a which seems like a new variant of BankPath/Multibanker trojan. It has a Virustotal detection of 9/43 (20.9%) –

While we looked at a Bankpatch Trojan in very much detail in an earlier post (, this one seems to be different and we only want to focus on the MITB features as a part of the broader MITB discussion.

Man-In-The-Browser threats are malware that operate within your browser and have full access to the current Internet session and can change the web-page, add content, remove content, steal information and much more. Please note that it doesn’t matter whether the site is using SSL (or even EV-SSL) as the malware gets access to the content before its encrypted.

3 How does MITB work?

3.1 Windows

Now let’s have a look how all major Trojans do this at the example of Bankpatch and Internet Explorer. When the Internet Explorer opens a connection to the Internet, it will call a function named “InternetConnect” which resides within the wininet.dll module that every Windows installation has.

This is illustrated below:

MITB Trojans will now just “hook” into this first call between the Internet Explorer Application and the Windows System, so that the Trojan get full control over everything that is transmitted in this “call”.

3.2 Mac OS/X

But what about Mac OS X? As mentioned earlier the details are a little different, but the result is same. If a web browser is using the system API to manage its Internet connections, then malware simply needs to hook CFReadStreamOpen(), CFReadStreamRead() or CFReadStreamWrite()  in a similar way to the one described above.

3.3 Hooking

On a high level, it looks now as follows


On Windows, we will be able to accomplish this with just a change of 5 bytes in the Internet Explorer process! wow.

On Mac OS X we could take advantage of the lazy linking system used for resolving external symbols, and simple overwrite the resolved address with one of our own. So it would only take 4 bytes on Mac OS X (simply the address we want to call inserted into the appropriate location). This could be done either before or after the symbol resolution has occurred.

The interesting thing is that this is very easy to accomplish, so let’s have a look what Bankpatch is doing:

On a good system, a call to “InternetConnect” will go to the following location


Don’t be scared at the technical details, most of the info is not relevant, but what’s relevant is that the first three lines are always the same for every single function and is called “prologue”. An obvious question is why do we need this prologue?

3.3.1 Works as designed

And you can believe this or not, but this prologue was designed to enable “hot-patching” (see Microsoft Wait a sec… hot patching??? You heard right… The first two bytes are not needed at all, but it is designed to allow a redirection of this function.

Can someone repeat this for me??? Man-In-The-Browser by design from Microsoft??? wow.

That’s pretty much what it is.

In order to “hook” into this call, the malware needs to do two things.

  • Firstly it needs to jump to its own codebase so that the malicious code is executed.
  • Secondly it needs to make sure that the original code is called (otherwise no internet connection would be established) as well.


The first part can be accomplished with 5 bytes (a JUMP instruction + 4 bytes address). As the prologue (that is not really needed) is exactly 5 bytes long, the malware can just overwrite the prolog and everything is fine… That’s convenient and easy.  The picture isn’t much different on Mac OS X. We just need to overwrite the address of the destination function (say CFReadStreamOpen) in the target executable look up table.

3.4 Let’s put this all together

Let’s see how Bankpatch uses these first 5 bytes to get access to the full internet traffic


So instead of the normal prologue, there is an unconditional jump (jmp 009b841f) basically telling the CPU to execute the Bankpatch code whenever InternetConnect is called. After Bankpatch does its work, it will then obviously call the original function so that the internet connection is established.

That wasn’t too hard, was it?

3.5 Mitigation approaches

If we replace the original prologue, then Bankpatch will not do any harm anymore. On Mac OS X, we can simply force the dynamic linker to look up the correct symbol again. Problem solved… without knowing any details, … Without any blacklist, heuristics, … Straight and simple…

Well, in reality its not so simple as the Trojan can just change those few bytes again and restore the hook, but we hoped to shed some light on how MITB Trojans do their dirty work, regardless of platform.

To make matters worse, signed binaries don’t help here either. On Windows, only the disk image is signed and once the file is loaded into memory, anyone can make any changes to it as there is no signature to the memory image.

On Mac OS X, lazy symbol resolution is part of the OS design and unavoidable.

4 Conclusion

As you can see the actual hooking of the browser isn’t a major hurdle and can be done easily. What is obviously more interesting is what Trojans do once the hooking has been done. This is where the MITB malware configuration comes into play with its bank-specific definitions and different behaviours depending on a particular situation. We have covered real-world examples in a number of other post re Zeus, Carberp, Gozi, etc.

The thing that is more amazing is actually that every single MITB Trojan uses these kind of hooking techniques, but hardly any Antivirus Engines or Security Suites look at these things.

Of course the TrustDefender Forensics Engine does.

Torpig – back to the future or how the most sophisticated trojan in 2008 reinvents itself

1         Executive Summary

We have seen many different examples how improvements in the security landscape have forced the bad guys to change tactics and achieve their results via different, potentially less useful, methods.

A prime example is the introduction of UAC in Windows 7 together with the default user not running as administrator. This poses a tricky question for malware developers: Do I ask for elevation (UAC) and risk that users get suspicious, or do I do whatever I can without administration privileges?

Well the answer has been given. We’ve analysed Zeus before and Zeus will not bring up the UAC and will only infect the currently logged in user.

In this TrustDefender Labs report we look at a new strain of the notorious Torpig Trojan that gained massive publicity in 2008 when it was distributed together with the Mebroot / MBR virus. In this report we look at a new variant that will do an impressive amount of things completely without administrator privileges.

On a positive note, the lack of privileges restricts the trojan’s ability to hide itself deep in the system and is much easier to detect and remove.

2         Introduction

Torpig was basically the Zeus Trojan of 2008, as it was deployed as part of the Mebroot deployment vector. Its impressive feature list made it the Trojan of choice at that time.

We’ve covered Mebroot/Torpig back in 2008/2009; more details are on the TrustDefender blog here and here.

In the last few months, more and more Torpig Trojans appeared without the Mebroot component.  It was pretty obvious that this was done to make Torpig work on newer operating systems such as Windows Vista and Windows 7 where the introduction of UAC and the removal of the admin-rights for the default user forced the Trojan writers to adapt.

Unfortunately these security improvements didn’t make the problem disappear; it only made their job harder.

So in essence, Torpig is still very impressive with the following features:

  • Works perfectly fine in Windows 7
  • No UAC
  • Everything runs from usermode
  • Browser hooking works nicely
  • HTML web injection works like a treat
  • Completely silent



  • It doesn’t feature any self-defences at all
  • Torpig is visible as a process in task manager
    • E.g. rundll32.exe C:\DOCUME~1\support\LOCALS~1\Temp\1.tmp,_IWMPEvents
    • Only current user is infected, not the whole machine
    • If you kill that process, Torpig is disabled
    • If you remove that file, Torpig is gone
    • Other side effects:  If IE runs as a separate user, Torpig will not be able to inject its HTML code anymore!

Other Trojans went down the same path. For Zeus 2+, the situation for example is as follows:

  • No UAC appears
  • Zeus runs as current logged in user
  • Browser hooking still possible

BUT Zeus is also easily detectable, easily removable, and has almost no self-defences.

From Zeus manual:

So let’s look at Torpig a bit more in detail as it employs a number of interesting techniques that are very similar, but also different to the Zeus/Spyeye/Gozi/Carberp’s of the world.

One of the main differentiating factors is how the HTML injection mechanism works, and obviously HTML injection is used quite heavily to attack bank websites.

Another interesting observation is that Torpig will hijack search results (e.g. Google) and most likely perform Clickjacking. This is something we noticed with Carberp as well and we believe that there is so much money to be made with this, it too important not to do it.

3         Installation

We looked mainly at the Torpig sample with MD5 of 70675a7053ae38adb77d70a056956684.

It was first seen on April 10, 2011.

3.1       C&C DNS generation algorithm

One interesting fact is that while we installed the Trojan on April 10, even 2 months later it still successfully finds responding C&C servers that are up-and-running!

It achieves this by using an algorithm where Torpig will generate new domains daily to connect to on its quest to get access to a C&C server.

The fact that after 2 months our Torpig Trojan still finds responsive C&C servers says a lot about our current efforts in disrupting this infrastructure!

3.2       System modifications

As mentioned in the introduction, the main purpose of the Torpig Trojan is to also infect Windows Vista/7 machines, so even though we installed the Trojan on a Windows XP SP3 machine with full admin rights, the payload does exactly the same thing as if it was running as non-administrator. With one exception as it will add itself to the global Autostart registry to infect all users and not just the current one.

After the initial binary is executed, it will drop a DLL into the user’s temp directory and add the following command to the Autorun registry (only to HKCU – Current User):

rundll32.exe C:\DOCUME~1\support\LOCALS~1\Temp\1.tmp,_IWMPEvents

The interesting part is that they could have developed this as an executable, but then the Zeus executable would show up in the task manager. Using rundll32.exe (which is a legitimate Microsoft component) it can “hide” behind it.

The command above means that the system will load the 1.tmp DLL file and invokes a function call to the function _IWMPEvents.

3.2.1       It tries to infect the whole system, if possible

Even though the payload only affects the current user, Torpig will actually drop another DLL and tries to load this into the process with admin rights, if possible.

That means that if your user has administrator rights, all (!) users will be infected. If the user doesn’t have admin rights, only the current user is infected.

This is the Autorun in HKLM (Local Machine):

3.3       Code injection into other processes

As part of the installation, Torpig will inject executable code into other (system) components. Most notably into “explorer.exe”, which is a process that runs in the user’s context (no admin rights needed). Torpig did the same thing quite heavily before as well (back in 2008).

3.3.1       Basic user-mode rootkit techniques

Torpig will employ some very basic usermode rootkit techniques, such as very limited file hiding techniques. For example, the Torpig code within the explorer.exe process will create a temporary file:

The file is hidden in the file system with a hooking of FindFirstFile/FindNextFile and won’t be visible in the Windows explorer. However the “old” tab-completion trick still works (just open a command prompt and let the tab auto-complete the filename).

3.3.2       Named pipe !mscom$

In the “old” days back in 2008, Mebroot and Torpig used named pipes quite extensively to enable the various components to communicate.

It almost surprised us to see that one of the named pipes is exactly the same (\\\\.\\pipe\\!mscom$). Also the protocol used for the communication is still the same with some extensions. Chapter 8 (Appendix A) is dedicated to the named pipe communication.

3.3.3       32 bit vs 64 bit

Torpig successfully installed and operated on 32 bit systems.  It successfully installed on 64 bit systems as well, but it didn’t initialize properly (e.g., the named pipe !mscom$ wasn’t created).

However the DLL’s were dropped and loaded with rundll32.exe in almost exactly the same way.

3.4       Operating System / Brower compatibility

We tested various browsers and according to its technical capabilities, Torpig will work with Internet Explorer and Firefox. We see here the same improvements that we have seen with almost all other Trojans – that Torpig enhanced itself to work on Firefox due to its increased popularity.

However not all browser / OS seem to work.  Here is the matrix:

  • Windows XP, Vista, 32 bit
    • Worked fine with IE 7,8
    • Worked fine with Firefox 3.5 and 3.6. Didn’t work with Firefox 4 (!)
    • Windows 7, 32 bit
      • Didn’t work with IE 8 (!)
      • Worked fine with Firefox 3.5 and 3.6. Didn’t work with Firefox 4 (!)
      • Windows 7, 64 bit
        • Didn’t work at all. Not even the named pipe was created

3.5       Logical components

Torpig is made up of two main logical components.

The web browser code communicates with the explorer.exe code via the named pipe. The internet request then (e.g. to the C&C server) will be done from the explorer.exe process.

Note: It is pretty obvious that the fact that the internet requests are done by the explorer.exe process has numerous advantages. First of all, no browser plugins can see the traffic (as the traffic doesn’t occur in the browser), but also local firewalls and security solutions will not see anything.

3.6       C&C server communication

The C&C server communication is encrypted with a custom encryption mechanism and it looks pretty much unchanged from the one used before (described here:

3.6.1       HTTPS Certificate

The requests to the C&C server are encrypted with SSL and a self-signed HTTPS certificate is used. This is possible due to the fact that the explorer.exe does the communication and “only” the content is then injected directly into the web browser’s process. So the web browser itself doesn’t even see any reference to the C&C server!

The following HTTPS certificate was used for the communication.

The “Valid from” date of 13 September 2010 surprised us a little bit as it is quite “old”…

3.6.2       The use of Geographic IP lookup

It seems that the C&C server quite heavily uses geo IP lookups to determine what should happen and whether a system should be infected or not. We successfully infected a machine in Australia, while we haven’t had such “luck” in the UK or Germany.

4         HTML content injection (MITB)

4.1       Browser hooking

Torpig uses the same mechanism as everybody else to hook the web browser process.

By hooking these functions, Torpig can get full control of the web browser traffic and can change whatever it wants. Please note that this also applies to HTTPS (EV-SSL) traffic.

4.2       Approach

Before we go into too much detail of how it works, let’s have a look at how Torpig uses the HTML content injection (Man-In-The-Browser).

First let’s be clear what we’re talking about. These instances below are examples of one particular configuration file of Torpig. All the examples we saw used a different approach for the HTML content injection than what we have seen in most Zeus/Spyeye configuration files.

This particular sample will not show anything suspicious before the user actually provides his authentication credentials (including 2-Factor-Authentication code). Before this information is sent to the “real” banking server, Torpig will inject additional form fields to steal more data complementary to the stolen login credentials.

So in this sense, Torpig doesn’t even attack the authentication system as such, but rides at the back of the existing session.

After all the provided information is collected and sent to the C&C server, Torpig “simulates” a correct login by using JavaScript to POST the login information to the login server

4.2.1       Identity theft (MITB) examples

In this section we provide screenshots to various banking sites. The target list for the Torpig trojan can be found in the Appendix and in no way is this list exhaustive

After logging in (with a fake account), the following screen appears:

Torpig’s configuration file checked every single entry to make sure it is correct. For example, it will check with Luhn’s algorithm whether the credit card number is actually a valid number!

While in most cases, we have seen “just” one additional page injected; we also came across an example where multiple pages will be injected.

First, they ask for Card related info:

Then query identity related info:

Ok, so how does this work in detail?

4.3       HTML injection details

This 10 page section is only available in the full indepth report. Please request one from

4.3.1       Curiosities

This section is only available in the full indepth report. Please request one from

4.3.2       Flaws in the system

This section is only available in the full indepth report. Please request one from

4.4       Conclusion

This section is only available in the full indepth report. Please request one from

5         Hijacks search results (Clickjacking)

A more and more popular feature even for transactional banking Trojans are the hijacking of search results.

Let’s assume you search for “Porsche 911” in Google.

Clicking on the first link (which should get us to Wikipedia) will send us to the following page:


Another example: Searching for “Get Firefox 3.6” leads us to the following page…

Doesn’t look too good, that result page.

Another example:  (check out the link in the status bar that will be invoked when clicking on the first hit)

6         Removal

Torpig can be fully removed by deleting the two files from the Autorun registry that are referenced from the following two locations:

  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, and
  • HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

Be sure to delete the right entry; in our case it was the entry with the rundll32.exe that references a .tmp file in a temp directory (Caution: be sure to know what you do in the registry editor as mis-usage could result.)

rundll32.exe C:\DOCUME~1\support\LOCALS~1\Temp\1.tmp,_IWMPEvents

Simply remove the two entries and delete the files from the hard drive.

Reboot the computer and you are clean.

7         TrustDefender

7.1       TDpro

Torpig uses the “usual” techniques to hook into the browser process. In addition to the code injection (executable and HTML) to the various components, one unique feature of Torpig is that the communication to the C&C server is done from the explorer.exe process. So even if there is a browser plugin or firewall checking all internet requests from the web browser, there is nothing to look at.

TrustDefender fully detects and protects users and enterprises from this threat, both on a process level (code injection), but also from the TCP/IP level (Secure Lockdown).

Below are a couple of screenshots from a walkthrough with TrustDefender with a demo site.

First it detects the malware.

And then the “Safe & Secure” mode will fully protect against it.

7.2       TDzero

As TrustDefender Zero utilizes our patent-pending page fingerprinting approach, it will detect the modifications to the page and therefore provide the financial institutions an early-detection system that doesn’t rely on blacklists, heuristics, updates or any downloads… It is completely transparent and an effective tool to protect against Man-In-The-Browser attacks of all sorts.

8         Appendix A: named pipe communication

This section is only available in the full indepth report. Please request one from

8.1       Static target list output (same tool we used back in 2008)

This section is only available in the full indepth report. Please request one from

8.2       Dynamic communication

This section is only available in the full indepth report. Please request one from

9         Appendix B: attached information to download

This section is only available in the full indepth report. Please request one from