We launch the malware and see that it creates new files at a regular interval in its current directory. These files are fairly large (multiple megabytes) and contain seemingly random data with filenames that start with temp and end with some random-looking characters, something like the ones shown in Example C-101.

temp062da212
temp062dcb25
temp062df572
temp062e1f50
temp062e491f

Next, we search the malware for evidence of encoding techniques using static analysis. The PEiD KANAL plug-in, FindCrypt2 plug-in for IDA Pro, and IDA Entropy Plugin fail to find anything of interest. However, a search for xor instructions yields the results shown in Table C-5.

The instructions labeled ❶ in Table C-5 represent the clearing of a register and can be ignored. The instructions labeled ❷ are contained in library functions and can also be ignored. We are left with two functions of interest: sub_40128D ❸ and sub_401739 ❹. Additionally, at 0x0040171F is in an area of code ❺ that has not been defined as a function.

We’ll refer to sub_401739 as heavy_xor since it has so many xor instructions, and sub_40128D as single_xor since it has only one. heavy_xor takes four arguments, and it is a single loop with a large block of code containing many SHL and SHR instructions in addition to the xor instructions. Looking at the functions called by heavy_xor, we see that single_xor is related to heavy_xor since the caller of single_xor is also called by heavy_xor, as shown in Figure C-48.

Figure C-48. Relationship of encryption functions

Looking at the xor instruction at ❺ in Table C-5 (0x0040171F), we see that it is in a function, but the function was not automatically identified due to lack of use. Defining a function at 0x00401570 results in the creation of a function that encompasses the previously orphaned xor instruction. As seen in Figure C-48, this unused function is also related to the same cluster of likely encoding functions.

To confirm that heavy_xor is the encoding function, let’s see how it is related to the temp files that were written to disk. We can find where the data is written to disk, and then trace backward to determine if and how encoding functions are used. Looking at the imported functions, we see WriteFile.

Checking the cross-references to WriteFile, we find sub_401000, which takes as arguments a buffer, a length, and a filename, and opens the file and writes the buffer to the file. We’ll rename sub_401000 to writeBufferToFile. sub_401851 is the only function that calls writeBufferToFile, and Example C-102 shows the contents of sub_401851 (which we rename doStuffAndWriteFile), leading up to the call to writeBufferToFile at ❶.

lea     eax, [ebp+nNumberOfBytesToWrite]
push    eax
lea     ecx, [ebp+lpBuffer]
push    ecx
call    sub_401070 ❷   ; renamed to getContent
add     esp, 8
mov     edx, [ebp+nNumberOfBytesToWrite]
push    edx
mov     eax, [ebp+lpBuffer]
push    eax
call    sub_40181F ❸   ; renamed to encodingWrapper
add     esp, 8
call    ds:GetTickCount ❺
mov     [ebp+var_4], eax
mov     ecx, [ebp+var_4]
push    ecx
push    offset Format   ; "temp%08x" ❹
lea     edx, [ebp+FileName]
push    edx             ; Dest
call    _sprintf
add     esp, 0Ch
lea     eax, [ebp+FileName] ❻
push    eax             ; lpFileName
mov     ecx, [ebp+nNumberOfBytesToWrite]
push    ecx             ; nNumberOfBytesToWrite
mov     edx, [ebp+lpBuffer]
push    edx             ; lpBuffer
call    writeBufferToFile ❶

Working from the start of Example C-102, we see two function calls to sub_401070 at ❷ and sub_40181F at ❸ that both use the buffer and length as arguments. The format string "temp%08x" at ❹ combined with the result of GetTickCount at ❺ reveals the source of the filename, which is the current time printed in hexadecimal. IDA Pro has labeled the filename, as indicated at ❻. From the code in Example C-102, a good hypothesis is that sub_401070 at ❷ is used to fetch some content (let’s call it getContent), and that sub_40181F at ❸ is used to encrypt the contents (which we’ll rename encodingWrapper).

Looking first at our hypothesized encoding function encodingWrapper (at 0x0040181F), we see that it is merely a wrapper for heavy_xor. This confirms that the functions depicted in Figure C-48 are our encoding functions. The function encodingWrapper sets up four arguments for the encoding: a local variable that is cleared before use, two pointers both pointing to the same buffer that is passed in from doStuffAndWriteFile, and a buffer size that is also passed in from doStuffAndWriteFile. The two pointers pointing to the same buffer suggest that the encoding function takes source and destination buffers along with a length, and that, in this case, the encoding is performed in place.

Next, we identify the source of the content that is encoded and written to disk. As we mentioned earlier, the function getContent (at 0x00401070) appears to acquire some content. Looking at getContent, we see a single block of code with numerous system functions, as shown in Example C-103.

GetSystemMetrics
GetDesktopWindow
GetDC
CreateCompatibleDC
CreateCompatibleBitmap
SelectObject
BitBlt
GetObjectA
GlobalAlloc
GlobalLock
GetDIBits
_memcpy
GlobalUnlock
GlobalFree
ReleaseDC
DeleteDC
DeleteObject

Based on this list, it is a good guess that this function is trying to capture the screen. Notably, GetDesktopWindow (bolded) gets a handle to the desktop window that covers the entire screen, and the functions BitBlt and GetDIBits (also bolded) are related to retrieving bitmap information and copying it to a buffer.

We conclude that the malware repeatedly takes snapshots of the user’s desktop and writes an encrypted version of the screen capture to a file.

In order to verify our conclusion, we can take one of the captured files, run it back through the encryption algorithm, and retrieve the originally captured image. (This assumes that the algorithm is a stream cipher and that encryption is reversible; that is, encryption and decryption do the same thing). Since we have few clues about the algorithm used, the easiest way to implement this is to use instrumentation and let the code perform the decoding for us.

Since the code already has instructions that take a buffer, encrypt it, and then write it to a file, we’ll reuse them as follows:

We can implement this strategy manually using OllyDbg or use a script-based approach to provide more flexibility. We’ll look at the manual approach first.

#!/usr/bin/env python

import immlib
def main():
    imm = immlib.Debugger()
    imm.setBreakpoint(0x00401875)             # break just before pushing args for encoding
    imm.Run()                                 # Execute until breakpoint before crypto
    cfile = open("C:\\temp062da212",'rb') ❶
    buffer = cfile.read()                     # Read encrypted file into buffer
    sz = len (buffer)
    membuf = imm.remoteVirtualAlloc(sz) ❷     # Allocate memory within debugger process
    imm.writeMemory(membuf,buffer)
    regs = imm.getRegs()
    imm.writeLong(regs['EBP']-12, membuf) ❸   # Set stack variables
    imm.writeLong(regs['EBP']-8, sz)
    imm.setBreakpoint(0x0040190A)             # after single loop
    imm.Run()