Gozi MitB trojan targets IE 64bit, GData shows.

GData research shows Gozi going after 64-bit IE and also after Chrome.

For some time, banking Trojan Gozi has been using interesting technologies to implement its man-in-the-browser functionality, or MITB for short. Banking Trojans use the MITB form of attack to manipulate the network traffic between a customer and their bank in order to steal the customer's money. On the one hand, Gozi is the first banking Trojan that uses man-in-the-browser functionality in a 64-bit browser, namely Internet Explorer. On the other hand, Gozi's use of a method called "function table hooking", which Gozi uses for the Google Chrome browser, is also remarkable.
...
There were some Trojans that could run on 64-bit operating systems before but even within these, only 32-bit browsers could be attacked. One of the reasons for that is that hooking in 64-bit processes is extremely complex.
...
Due to the aforementioned difficulties, Gozi uses a type of hybrid of these two technologies. First, Gozi looks for an unused memory area at the end of the executable code of the library. An unused memory area practically exists there at all times because Windows splits memory into fixed blocks ("alignment"). So, unless the last memory block happens to be used completely, the rest is filled with fill bytes ("padding"). In order to not have to manipulate the byte code of a function, as in inline hooking, Gozi writes separate branch instructions into these fill bytes. This technology is also called "code caving".
...
All functions in Chrome that handle encrypted SSL network traffic read the addresses from the corresponding functions of this table. Gozi hence uses a technology called function table hooking, i.e. this table is manipulated in such a way that the Gozi code is executed first (here: mspaperf.dll):
This method is particularly interesting if you look at how it differs from classic hooking variants. The classic variants overwrite data in memory blocks that are normally not writable (code section and EAT). Hence, the memory access rights must be changed, which is relatively easy to detect. Even after setting the hooks, the file in the memory can be compared to the file on the hard drive in order to find memory modified by hooks. In the table hooking function, however, the overwritten function pointers are in the data section of the browser's binary file. Hence, there is no need to change any memory authorisations. In addition, the data section always contains dynamically changeable data so that a change is not suspicious by itself, in contrast to the manipulation of the code section and the EAT.

Function table hooking is therefore much harder to detect than the classic EAT hooking and inline hooking variants. link

The hash for the analyzed trojan at the bottom of the blog, is known at VirusTotal since Sept. 2012.