The cybercriminal gangs developing and distributing Zbot have been highly active recently, as seen here and here, so let’s dig into the code again.

On a day to day basis, malware researchers locate a sample of interest, which can seem similar to isolating a grain of sand on a beach, and investigate it in the lab.  Some tools are utilized to capture information generated by the sample which typically include changes to what Windows runs at startup, browser default page settings, newly installed programs or libraries, generated network traffic, and, if neccesary, unpacked/decrypted copies of the sample.  With most samples, this information collection process is straight forward, but Zbot is smarter than your average malware.

These tools are very effective for analysis because it can be easy to determine which changes came from which programs.  After unpacking a regular malware sample, it is possible to control it using a debugger and walk through interesting sections of code to see how it works.  This ease of analysis is where Zbot separates itself from typical malware.

The first action recent zbot variants perform is to unpack themselves (sdra64.exe, F836BA2BA0CEE2B8F0CFEE31BB535515), and instead of performing any immediate botnet-related tasks, it injects this unpacked code into the winlogon.exe process and terminates itself.

This injection is interesting for two reasons. First, the winlogon process is very sensitive.  For instance, asking a tool like process explorer to terminate the winlogon process can cause a blue screen of death.  Even if an anti-virus scanner detects this payload in memory, it is tough remove because it has to be careful not to take down the winlogon process with it. So the selection of this process target in particular was carefully done.  Secondly, the payload of this injection requires running inside the actual winlogon process for initial activation.  The payload attempts to piggy-back off of a “non-IO worker” thread running uniquely within the winlogon process via the CreateTimerQueueTimer() function. If the payload is artificially injected into another process, the payload will not exhibit its malicious behavior. This runtime requirement makes it difficult to emulate the payload’s environment for research purposes.

A portion of the payload does not only execute from within the winlogon process, however. The activated code running within winlogon (described above) also injects a copy of itself into the first real svchost.exe process that it finds.  It uses the same thread piggy-backing techniques employed in the winlogon process.  One of the first tasks that this newly injected payload performs is the downloading of the encrypted configuration file.  Later, after this configuration fetching task is complete, it injects this same payload into all other processes, which then engage API hooks to intercept the victims’ online banking web traffic.

These injection and information stealing tasks are all coordinated with the payload residing in the winlogon process via named pipe inter-process communication mechanism.  The pipe is typically accessed via the file name “\\.\pipe\_AVIRA_2108″ and uses a mutex with the same name (_AVIRA_2108) to guard against simultaneous access to this resource by multiple payloads in other processes.  This named pipe is watched for a series of number commands which perform particular actions, some of which are listed below:

05: opens local.ds
06: closes local.ds
07: opens user.ds
08: closes user.ds
09: closes sdra64.exe
10: opens sdra64.exe
14: intentionally causes a NULL pointer dereference (crashes the winlogon process, resulting in a BSOD)

In the screenshot provided below, we can see a piece of code that executes immediately after downloading the encrypted configuration data.  It sends the command “6″ to the named pipe which tells the winlogon payload to close the “local.ds” data file, which resides in the %SYSTEM%\lowsec directory.  It then writes a fresh “local.ds” file to this directory, and instructs the winlogon payload to re-open this data file with the “5″ command.

Svchost Example Zbot Commands

Separating the malware execution into code chunks that reside in different processes makes it difficult to analyze what this bot actually does. With each chunk camouflaged inside a real process, the separation also makes it difficult to properly clean off your system once infected, due to the infection being spread all over legitimate processes.