Malware z13.exe

Mickaël Paradis and Benoit Hamelin, Arc4dia Labs
2015 03 19

Introduction

We report here on a reverse engineering effort to better understand how z13.exe infests a system. From our analysis, this malware bears the signature of a banker trojan. Although we have not yet confirmed its insertion in a web browser to steal banking credentials, we can see that it leverages methods and algorithms seen in Zeus and the most recent version of Tinba (Tiny Banker). In addition, it it is reported by most antivirus software as miscellaneous banker variations. Since the leak of the Zeus source code in 2011, forks of well-known versions of banker trojans have become commonplace.

We first look at the dropper program, which unwraps the malware behaviour from encrypted modules. Second, we show how it transfers its attack code to a hollowed-out child process. Third, we follow its injection into Windows Explorer, using the so-called Heaven’s Gate technique.

Fourth, we examine the various tricks the malware does to cloak itself, as well as to persist on the infected system.

Entry Point

At first glance, the malware doesn’t reveal much with static and dynamic analysis. Only with careful tracing does it reveal all its tricks. It starts as a common MFC program. It sets up a dialog named chat tool from a loaded resource segment. It’s from the initialization of this dialog that the code Link starts to act like a malware.

It loads in memory a copy of the file on disk and then seeks a value into this memory that indicates the start of an encrypted block. The block is decrypted on the heap as follows:

Once decrypted, the execution jumps into this new code segment, which executes various recon tasks to determine whether the host is already infected. At the end of this code segment, another memory block is decrypted using the same procedure. This second blockcontains antiVM behaviour and an interesting forking process detailed in the next section. This type of architecture shows modularity in the conception of the malware. The developers make independent block with different features and those blocks, revealed for execution one at a time, determine the malware behaviour.

The imports for each code segment are found by first pushing the names of all routines it needs on the stack. Then, the string kernel32.dll is retrieved from the process environment block (PEB). The module is found among those loaded, so the code fetches LoadLibrary and GetProcAddress from its the export table. Those two functions are then used to resolve all other function names that were previously pushed on the stack.

Malicious behaviour transfer

The malware is using a wellknown but interesting technique called process hollowing, which consists in rewriting the memory of another process without touching the PEB. This technique is usually used to cloak a malicious process into a legitimate process. For example, “C:\malware.exe” could hide into “C:\windows\notepad.exe”, but in this case, the hollowed process is the same as the original one. It is therefore not used for cloaking but as a way to slow down the reversing.

The implementation of process hollowing starts by creating a suspended target process. The original memory sections of the target process are first unmapped with NtUnmapViewOfSection . The new sections are then written into the hollowedout process. The suspended process is now ready to resume except for one detail: the thread EP (entry point) is not valid anymore. Hence the parent process gets the main thread context with GetThreadContext , corrects the EP at offset 0xB0 and sets back the thread context with SetThreadContext . The hollowedout
process is then resumed with new program code.

At this point, the malicious computation has transferred into the child process. In order to continue our trace study, we must attach to the child process. This can be done by manually placing a breakpoint on the new EP with a memory patching tool like ProcessHacker. The EP address is found at offset 0xB0 in the thread context structure just before the SetThreadContext function.

With the breakpoint set in the child process, we set our debugger up as JIT and resume execution of the parent process. The latter will resume the hollowed out process, so the JIT debugger will break on the EP. The main task of the child process is to inject a remote thread into the Windows Explorer. To prepare for this, it simply asserts debugging privileges, so it may attach as a debugger to all application running as the same user.

Injection in Windows Explorer

The malware finds its injection target by listing the system processes with the function NtQuerySystemInformation, called with the enum SYSTEM_INFORMATION_CLASS set to 0x5 (SystemProcessInformation) . It then performs the same hash comparison procedure used to resolve the imports in order to find the SYSTEM_PROCESS_INFORMATION structure related to explorer.exe. It gets from that structure the PID of explorer.exe, of which it retrieves the handle using OpenProcess.

When ready to inject, the malware tests the remote process architecture with isWow64Process. The injection occurs either ways, but with the difference that it passes through the Heaven’s gate for a 64bits process.

The Heaven’s gate is a simple far jump with the code selector register (CS) set to 0x33, indicating x64 instructions. Its a simple CPU switch between 32bit and 64bit mode. In sysWoW64, this switch is implemented in the function wow64cpu!X86SwitchTo64BitMode FS:[0xC0]. In order
to keep control over the return address, the injector implemented a widget with a call to offset 0x0 and setting up the return address 0x5 higher on the stack, yielding a return following immediately this fake procedure, into the rest of the injected code.

Once in 64bits mode, the injection is completed with CreateRemoteThread. The inverse mechanism is used to return to x86 mode, setting the CS to 0x23.

The use of this hybrid type of malware is increasingly used by malware authors to adapt to the dual architecture Windows ecosystem. The main thread injected into explorer.exe is behaving as we would expect from any banker trojan. It starts by hooking ZwResumeThread, which is called each time a new process is created by explorer.exe.

The added hook is straightforward. It injects code into each new process if the access rights allow it. Note that the injection still supports both 32bits and 64bits architectures. The main thread injects also into every currently running process. The injected thread in explorer.exe also tries to beacon its C&C using the new popular thing in the banker world, DGA (domain generator algorithm), with the difference that it generates IP addresses instead of domain names. The malware owners set up a large range of possible IP addresses for their C&C. The DGA queries thousands of IPs until it receives a valid answer from an active C&C. This method of communication is now very popular, as it is very effective against C&C takedowns.

Persistence and cloaking

The malware is using common sandbox evasion behaviours. It searches indicators specific to virtual environments like vmtoolsd.exe (VMWare), VBoxService.exe (VirtualBox) or SbieDll.dll (Sandboxie). It does so by iterating over the module and process list using CreateToolhelp32Snapshot . This is easily worked around with memory patching or a VM setup without virtualisation tools.
Before infecting the host, the mutex “qazwsx” is tested to avoid reinfection. It also attempts to open the file “C:\myapp.exe” with C reateFile. If the returned handle is valid, the process is terminated without infecting the host. This could be a way for the authors to easily avoid infecting the host in the development process. It tests the string “C:\windows\explorer.exe.\” similarly. Persistence is achieved by dropping a copy of the malware in the AppData folder. The name of this new file is an obfuscated value that terminates in wnisxpeo.exe . Here is the deobfuscation algorithm:

The file time of the dropped file wnisxpeo.exe is copied from svchost.exe. This is a common approach to lower the file suspicion.

An autorun registry key is created by the injected explorer.exe process to secure persistence after reboot.

Finally, the dropper is deleted from disk once its task is done. It does so by creating a simple batch file starting by “ms” and followed by a random numerical value. The script is placed in the path “C:\%UserDir%\AppData\Roaming” and executed.