Studying Zeus 2.X

Question

I'm doing some study on Zeus 2.x, trying to wrap my head around how it works. By using this code. I've built my own builder to work on my test environment.

Right know I want to do a very specific thing, which is extracting from memory the webinjects configuration. The first experiments I did was to attach to IExplorer and monitor calls to functions I know Zeus hooks, like HttpSendRequest*. I was expecting that at some point while stepping through those executions I'd see the injections configuration loaded into memory. I've tried to automate the proccess setting a breakpoint upon call of this function and using OllyDbg's Memory Watch plugin, which dumps every string it encounters.

So now I want to pinpoint and understand exactly where should I look to see this decrypted configuration in memory.

My assumptions so far:

• I'm unable to see anything strange because the HttpSendRequestX function I'm setting a breakpoint is actually the original, unchanged from Wininet;
• Dumping memory of the machine and analysing it offline is not enough, since the structure which holds the webinjects (BinStorage) is loaded in memory when it's needed and then discarded (free'd)

At this point I was thinking to monitor calls to VirtualAlloc and place a breakpoint on memory write on those newly allocated areas (at some point Zeus is bound to place there the encrypted configuration and then decrypt it).

But this is still a long shot. Any ideas? Also I'm doing most of this work by attaching on IExplore.exe, should I do it on explorer.exe instead?

Any tips are appreciated !

Answer 1

Answering my own question for further reference:

Zeus and many other MiTB capable trojans use API hooking as preferred method to inject malicious code in the webpages before they are rendered by the victim. API hooking is sort of like doing a MiTM of a system call, whereby the bot intercepts the call, takes ownership and control, performs some malicious action and then returns control to the original function. Something like:

call network_function:

JMP XYZ ----> JMPs to malicious code 
..                |
..                |
...           <---- returns to the original function

So, in this scenario, in order to extract the web injects, the best bet was to understand the logic of the trojan. That is, after a user opens a URL in the browser, this URL will be matched with a list containing the configuration of which URLs to inject. This will surely be performed on Wininet functions such as HttpSendRequest, HttpOpenRequest, etc. If we breakpoint on that function in the main process of IExplore.exe (in an infected machine) we'll see the first instruction to be that JMP instruction we've talked about. If we then proceed to step into, we'll access the actual instructions using the structure BinStorage and other, all related to Zeus. Since there is still a lot of code to go through and the interest was to retrieve the webinjects, one approach is to monitor for decryption / decode instructions (Zeus's configuration is stored encrypted; it only makes sense that if we monitor the instructions responsible for this operation will lead us to the actual decrypted content).

In this case searching for the sequence of bytes

 MOV ANY, ANY
 XOR ANY, ANY
 INC EAX
 DEC ESI

If we breakpoint after the last instruction and then inspect the contents of the memory address pointed by the destination operands in the MOV/XOR operations we will most likely find the decrypted payload (i.e. our dynamic configuration section).