IE64 hooking

A technology called hooking is usually used to implement man-in-the-browser functionality. There, program interface calls of network libraries (IE: WININET.DLL) are diverted to the Trojan’s source code to manipulate SSL-encrypted network traffic in an unencrypted state.

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. There are two classic hooking methods:

Export address table hooking

Each program library (DLL) contains a table of provided program interfaces, which is called the export address table (EAT). The table contains a list with the assignment of interface names to interface addresses. During hooking, the interface addresses in the list are now manipulated in such a way that the interface suddenly points to the Trojan’s source code, which provides the man-in-the-browser functionality. 

However, this method does not readily work like that in 64-bit processes. This is due to the fact that the EAT for 64-bit processes is also a table with 32-bit addresses, towards the start of the program library. However, with a distance of 32 bits, a Trojan in a 64-bit address space cannot ensure that it can refer to its own source code.

Inline hooking

The first program instructions of the target functions are manipulated. The target functions are the functions that are supposed to be hooked, in this case the SSL function. Here, the malware exploits the fact that Windows program interfaces in 32-bit processes always start with the same five bytes:

The first instruction (mov edi, edi) is a so-called hot-patch point, which is designed in particular for the (legitimate) hooking of functions. The next two instructions are used to prepare the stack frame of a function. 

64-bit libraries, however, do not have five fixed bytes at the start of a function. Hence, the inline hooking of 64-bit libraries would require the byte code to be analysed using a disassembler. However, this is an extremely complex and error-prone process. 

Gozi has to use hybrid technology

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

Gozi first starts with EAT hooking

The interface addresses in the EAT are now manipulated in such a way that they point to the corresponding branch instructions in the "code cave". Since the "code cave" is still within the library, no 64-bit distances are required for these pointers. In this context, EAT hooking is thus possible without problems. It is only the branch commands within the "code cave", where there is sufficient space, that can implement branches with 64-bit distances.

Chrome hooking

There is one major difference between the implementation of hooks in Google Chrome and Internet Explorer or Firefox. Chrome uses the same library as Firefox (nspr4), but it is not integrated as a dynamic library (DLL) but rather statically integrated directly into Chrome’s code. However, Chrome contains an internal table that contains the functions for inbound (ssl_Read) and outbound (ssl_Write) SSL-encrypted network traffic:

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

G Data BankGuard offers protection

The upcoming G Data Security Generation 2014 contains improved BankGuard technology for secure online banking. It will also protect both Chrome and the 64-bit version of Internet Explorer. 

More information about this improved G Data technology and the new product generation is available at and after CeBIT 2013! 

For fellow researchers: The SHA256 of the sample is e388d31e6fde7bdf1f395c29e158c24bb0a87829c6f19511de46e4ef6e054ce0