Reversing Encrypted Callbacks and COM Interfaces

Author: Sudeep Singh

Introduction
In this paper, I would like to discuss about viruses which make use of COM Interfaces to implement their
functionality and how we can effectively reverse these binaries.

As an example, I will take a virus, which was recently found in the wild and uses certain interesting
techniques.

For the purpose of clarity and context, I will walk through the code execution flow.

We will also be looking in depth at how the network communication is encrypted before sending it to the
callback server, how the response is decrypted and parsed to extract the malicious binaries.

This paper is targeted towards those who are familiar with malware analysis at the same time those who
have experience with malware analysis might find new techniques to effectively analyze viruses.

Purpose
One of the main reasons I wrote this paper was to explain in depth the different stages involved in viruses
that exchange data with the callback server using encrypted channels.

Most write ups of viruses online, do not discuss these stages. With an understanding of the techniques
used by viruses to secure the exchange of data over network, it will become easier to identify the type of
data exfiltrated from machines and the main purpose of the virus.

Stage 1 - The Dropper

The dropper is a Nullsoft SFX file.

How do we know that it is an SFX file?

From PEiD:
From Section Headers:

.ndata section is specific to Nullsoft SFX files.

If you want to check even further, you can reverse the binary and find the following code section where it
looks for the “Nullsoft Inst” marker:
Now that we know it is an SFX file, we can extract its contents using 7-zip. SFX file makes use of CRC32
and Zlib for compression, which is supported by, 7-zip.

We see that it consists of the following files:

1. rzkxixls.exe
2. setup.dat
3. rs.dat

The dropper will extract these files to the %temp% directory. Once it has extracted these files, it will
create a new process to execute rzkxixls.exe from the %temp% directory as shown below:
 Stage 2 - Execution of Dropped Files
The dropped file, rzkxixls.exe is a virus compiled in VB.

How do we know that?

From PEiD:

From the entry point in Debugger and also one of the loaded modules is MSVBVM60.dll

It also has the VB5!6&* Marker.

Since we know that this is a virus written in VB, we can analyze it easily by tracing the calls to
DllFunctionCall().

The reason we do this is because viruses written in VB will dynamically obtain the function pointers for
APIs imported from kernel32.dll, ntdll.dll and other modules by calling DllFunctionCall().

Before we analyze it further, let us quickly run a Call Trace on the virus. We must ensure that, this is done
inside a sandbox, since to obtain a Call Trace of the virus, we will be executing it.

I have written a pintool, which will obtain the sequence of CALL instructions along with the instruction
addresses. By looking at the output, we can clearly see that it performs code injection into another process
using the following sequence of APIs:

150d06 => CreateProcessW

151014 => DllFunctionCall
150d27 => NtUnmapViewOfSection
150d49 => NtAllocateVirtualMemory
150d77 => NtWriteVirtualMemory
150db7 => NtWriteVirtualMemory
150db7 => NtWriteVirtualMemory
150db7 => NtWriteVirtualMemory
150ded => ZwGetContextThread
150e17 => NtWriteVirtualMemory
150e4c => ZwSetContextThread
150e69 => ZwResumeThread

As you can see, we can quickly identify the method used for code injection by the binary using the Call
Trace pintool. This particular method for code injection is used by several viruses these days and has
become common.

Now that we have a brief overview and understanding of the virus, let us analyze it in the debugger.

We set a breakpoint at DllFunctionCall() as mentioned above and run the binary.

Once we break at DllFunctionCall, follow the return address (at the top of the stack) into the code section.

Now, set a breakpoint at the instruction, jmp eax. The function pointer of the API will be returned in eax.
After running the binary we can see that the address of EnumWindows() function was returned in eax.
EnumWindows() function is used in this case only to introduce control flow obfuscation. Since this API
takes an application defined callback function as one of the parameters:

BOOL WINAPI EnumWindows( _In_ WNDENUMPROC lpEnumFunc, _In_ LPARAM lParam );

We will follow the first parameter passed to this API in the code section and set a breakpoint at it. In our
case, this address is: 0x0014d458.

Run the binary and break at above address. We have now reached the main code section of the binary.

This is a self modifying code stub. The subroutine at address: 0x0014db68 will be used to modify the
encrypted code present at the address: 0x0014d464.

Let us enter the self modifying code stub:

At first, it loads a large value (0xDDDDFDDD) in the ECX register and then runs a LOOP to introduce delay
in execution.

This is followed by the decryption routine. It makes use of the MMX XOR instruction instead of the general
XOR instruction. The reason to do this is to bypass code emulation. Since code emulators have to
implement the instruction set of x86 processors, they do not implement the complete instruction set.

It is a known method for viruses to make use of undocumented FPU/MMX instructions to defeat the code
emulators.
Once the self modifying code has executed, we will return to the decrypted code section:

In this code section it first makes use of common anti debugging techniques by checking the fields
NtGlobalFlags and BeingDebugged in the Process Environment Block.

After this, it executes the CPUID instruction with eax set to 1 (CPUID_GETFEATURES) and checks the
value of the bit, CPUID_FEAT_EDX_MMX. This check is done to see if the CPU supports MMX instructions.

This is followed by another delay execution routine, which loads a large value into ECX register and runs a
loop.
It now starts resolving the function pointers and Calls the APIs. Below code section corresponds to the
subroutine used to resolve the function pointers:

Instead of getting the function pointers of wrapper APIs like VirtualAlloc(), it gets the address of low level
APIs like ZwAllocateVirtualMemory()

Below is a Call to ZwAllocateVirtualMemory() to allocate memory within its own process address space:

It then searches for the marker, 0x3a58583a within itself and copies the encrypted code to the above
allocated memory followed by the decryption routine.
We can again see the use of MMX instructions and MMX registers in the decryption routine.

It creates another instance of itself using CreateProcessW() in SUSPENDED_STATE.

Unmaps the image base of the newly created process using ZwUnmapViewOfSection().

Now, it proceeds to perform the code injection using the following method. I will be mentioning the steps
used for code injection without going in much detail since this is commonly used.

1. Creates a replicated process using CreateProcessW() in SUSPENDED_STATE.

2. Unmaps the image base in the newly created process using ZwUnmapViewOfSection().
3. Writes the sections of the decrypted malicious code from its own address space to the newly
created process’s address space using ZwWriteVirtualMemory().
4. Uses ZwGetContextThread() to get the context of primary thread in remote process.
 5. Uses ZwWriteVirtualMemory() to update the image base address in the PEB of remote process.
6. Uses ZwSetContextThread() to update the entry point of the primary thread in the remote process.
7. Uses ZwResumeThread() to resume the execution of primary thread in remote process.

Since the remote process is in SUSPENDED_STATE before the call to ZwResumeThread, in order to debug
it, we will modify the entry point of primary thread in remote process by editing the code in our own
address space just before the call to ZwWriteVirtualMemory().

We replace the bytes at the entry point with EB FE which correspond to short relative jump so that the
execution pauses at the entry point in remote process.

We can then attach the debugger to it and trace the code.

Debugging the Remote Process

In the remote process, it will open the setup.dat file (extracted previously from the SFX file) in read only
mode.

The contents of setup.dat file will be decrypted using the decryption routine below:

1. The first byte of setup.dat file indicates the size of the cyclic key, in our case 0x08.
2. The next 0x8 bytes corresponding to the cyclic key will be copied to a local buffer.

3. An array of size 0x100 bytes consisting of bytes 0x00 to 0xFF will be generated.

4. This array of bytes will be permutated and modified using the bytes of the above 8 byte cyclic key.

Below screenshot shows the algorithm for permutation:

Once the permutated table is generated, it goes through another phase of permutation as follows:
 1. Read a byte from the front end of permutation table.
2. Read a byte from back end of permutation table.
3. Swap the above 2 bytes.
4. Add the above 2 bytes and store it as the result.
5. Use the result above as an offset into the permutation table and read a byte. This byte becomes the
1 byte XOR key that will be used to decrypt the contents of setup.dat file.
6. The loop continues till the entire setup.dat file is decrypted.

After decryption, we receive a mangled output. If we look at the memory dump, we can observe the MZ
DOS header, however it is mangled. So, another subroutine is called to demangle it.

Below is the demangling subroutine:

After it is executed, we can see the embedded executable in memory dump. This means that setup.dat was
an encrypted binary.

It again allocates memory, copies the decrypted binary there and then resolves function pointers
imported from various modules to update the function pointer table.

It then parses the PE header of the binary, calculates the OEP and then executes the decrypted binary as
shown below:

OEP of the decrypted binary:

 Network Callback Stage
Now that we understand the structure of the binary and the code execution flow, let us fast forward to the
network communication.

We will run the binary and observe the network traffic. This will give us an overview of the network
callbacks.

It sends an HTTP GET request to the IP address: 176.9.245.16

The HTTP response is interesting as it is encrypted. We will look into the specific code section to
understand how it decrypts the response.

But first, let us see how the virus encrypts the data before sending it to the callback server.

Encryption Stage
It uses the Win32 Crypto APIs imported from advapi32.dll to perform the encryption along with custom
encryption routines.

Below are the main steps:

1. It uses CryptGenRandom() to generate a key of length 0xf4 bytes.

2. The above key will be used to permutate a 0x100 bytes array.
3. This 0x100 bytes array will then be used in the XOR encryption routine to encrypt the data
collected from the machine.
4. The binary also has a public key embedded in it, which will be used in the final stage of encryption.

The public key in our case is:

MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwQCDMHOqOBOGSrxtrAWaGj/OF
Gc6PqeJSgM0KTZnqBsSP71Mo3ZRqDFJHl/VxV/OyNzOYzE4NEXAmHADjG5YnhhnXAud1FG
/iuXJsj6v+I0wpKHhmwQdb8RfdM4/T3VAaLE11xBAUboJ+1TGzRbpBTnvddJ9EIqZlUf8eft7
DHN09SDE/kp3m3RKBRig0xhL1qzIkRgcmdBjfRowW/LM/JfuU/iYY7YU8OPG+YBQhT9YSeF
gbQORArtr3ivQcujIsD+nm/PEv6pcxznPg/KOTYfRs+xtn42AgwJpDmpv4t2+sOHQ1ZWNwds
4XOw8GS8M7WwwPYbVa12R/eXffcZPUQIDAQAB

This public key is stored in base64-encoded form. It is base 64 decoded to convert from ASCII to
binary.

5. Now, the above public key is used to encrypt the key generated in step 1 as shown below:
 a) Acquires a handle to the CSP of type, PROV_RSA_FULL with the flags CRYPT_VERIFYCONTEXT
| CRYPT_MACHINE_KEYSET.
b) It then calls CryptDecodeObjectEx() to decode the above public key from binary to a
structure of type: X509_PUBLIC_KEY_INFO
c) Uses CryptImportPublicKeyInfo() to import the public key from the structure decoded
above.

The public key algorithm type in our case is: 1.2.840.113549.1.1.1, which means that RSA is used
to both encrypt and sign the message.

d) Now, CryptEncrypt() is used to encrypt the key generated in Step 1 using the Public Key
above. The size of the encrypted key is 0x100 bytes.

6. It concatenates 0x100 bytes of encrypted key with 0x61 bytes of encrypted data.
7. It then, Base64 Encodes the complete binary blob.
8. This is followed by URL encoding the result of above step.

The resulting encoded and encrypted data will be sent in the HTTP GET request as you can see in the
network communication screenshot before.

The attacker’s server will retrieve the encrypted key by reversing the steps mentioned above:

1. URL decode the data.

2. Base64 decode the data.
3. Extract the first 0x100 bytes.
4. Use the RSA private key corresponding to the above public key and CryptDecrypt() function to
recover the original encryption key.
5. This encryption key will be used to encrypt the HTTP response.

Data Exfiltration Stage

One of the interesting facts about this virus is that it performs network communication with the callback
server using the IWebBrowser2 Interface.

Most viruses will perform the network callback by executing the APIs imported from ws2_32.dll like
connect(), send() or APIs like HttpOpenRequestA(), HttpSendRequestA() from wininet.dll.

Those cases are easy to debug and identify while tracing the code. However, when a binary performs
network callbacks using the COM Interface, tracing the code is not so easy.

Let us now look at the code section, which is used for network callback.

At first it initializes the COM library for the current thread using CoInitialize(). The next function called is
CoCreateInstance().
To debug the code further, we must understand what type of object is being instantiated in this case. We
can do this by checking the 1st and 4th parameter of the API as shown below:

Here is the definition of the CoCreateInstance() API:

HRESULT CoCreateInstance(
_In_ REFCLSID rclsid,
_In_ LPUNKNOWN pUnkOuter,
_In_ DWORD dwClsContext,
_In_ REFIID riid,
_Out_ LPVOID *ppv
);

The first parameter corresponds to the CLSID (Class ID) and the forth parameter corresponds to the IID
(Interface ID).

In our case,

CLSID = {0002DF01-0000-0000-C000-000000000046}
IID = {D30C1661-CDAF-11D0-8A3E-00C04FC9E26E}

In order to find the meaning of the CLSID and IID, we need to look up the Windows Registry, specifically
these keys: HKEY_CLASSES_ROOT\CLSID\ and HKEY_CLASSES_ROOT\Interface\

After looking up the above CLSID and IID values we can see that in our case, the CLSID corresponds to
Internet Explorer (Ver 1.0) and IID corresponds to IWebBrowser2.
It is also important to understand the return value of CoCreateInstance. It will return a pointer to the COM
object.

After executing CoCreateInstance, we get the return value as: 0x0018e77c

If we follow this in the memory dump, we get: 0x0018f628

This is the actual COM Object itself. If we follow it in memory dump again, we can see a table of function
pointers:

All the methods of IWebBrowser2 Interface are invoked by calling the function pointers from the above
table. However, these function pointers are not resolved by the debugger to any symbol name. This is the
reason, tracing the code of COM interfaces in debugger requires us to find the function names as well.

If we trace the code further, we see the following sequence of API calls:

UuidCreate(): This is used to create a 128-bit UUID which is later used as the class name of the Window.
It is important to note that UUID is generated randomly. In our case, the UUID is: {6F601261-8C73-4E4B-
8565-E3DA3E8242E0}
RegisterClassExW(): This is used to register a class with the Window Procedure at: 0x100051da. It is
always useful to set a breakpoint at the window procedure since it will have some important functionality
besides creating the Window.

In our case, we can see that the Window Procedure compares the Window Message code with 0x113,
which corresponds to WM_TIMER window message. If the window message code is not equal to 0x113
then the control is transferred to the default window procedure. So, we know the window message of
interest.

FindWindowA(): It then checks for the presence of any Windows in the system with the Class Name
equal to the UUID created previously. This is similar to the cases where a virus checks for a specific Mutex
Name to check if there is any other instance of the virus running on the machine.

GetSystemMetrics: It uses GetSystemMetrics() function to retrieve the values of the maximum possible
width and height of the screen as shown below:
0x3E corresponds to SM_CYMAXIMIZED and 0x3D corresponds to SM_CXMAXIMIZED.

CreateWindowExA: It creates a Window with the class name set to the UUID created before and
the dimensions of the window are set to the maximum possible width and height of the screen.

SetWindowLongW: It sets the user data (GWL_USERDATA) associated with the window created
above. The user data consists of the pointer to the COM object.

If we trace the code further, we can see the calls to IWebBrowser2 Interface. This is where we
need to find the function names. The calls look like shown below:
The debugger does not provide any information about the function name.

Let us try to understand how the methods exposed by the IWebBrowser2 interface are called.

10005550 MOV EAX,DWORD PTR SS:[EBP-4] ; pointer to COM object

10005553 MOV ECX,DWORD PTR DS:[EAX] ; COM object itself
10005555 LEA EDX,DWORD PTR SS:[EBP-8]
10005558 PUSH EDX
10005559 PUSH EAX
1000555A CALL DWORD PTR DS:[ECX+94] ; Call function at offset 0x94 in the
function table.

In order to find the function names, we will look up the C/C++ header files provided along with
compilers like MSVC. In our case, we will check the header file, ExDisp.h.

Below is the specific code section we need to check:

#if defined(__cplusplus) && !defined(CINTERFACE)

MIDL_INTERFACE("D30C1661-CDAF-11d0-8A3E-00C04FC9E26E")
IWebBrowser2 : public IWebBrowserApp
{

// This corresponds to C++

}

#else /* C style interface */

typedef struct IWebBrowser2Vtbl

{
BEGIN_INTERFACE

HRESULT ( STDMETHODCALLTYPE *QueryInterface )(

// This corresponds to C

The structure of interest to us is IWebBrowser2Vtbl. Also, notice the IID (Interface ID) passed to
MIDL_INTERFACE. It corresponds to the IID of IWebBrowser2 interface as we saw before.

Now, we need to locate the function name, which corresponds to the function at offset 0x94.

Since the size of each function pointer = 0x4 bytes, we can calculate the position of function in the
above structure as:

Position = Offset/4 + 1

We are adding 1 since the offset starts at 0. In our case,

Position = 0x94/4 + 1 = 0x26

Function at position 0x26 in the IWebBrowser2Vtbl structure is get_HWND defined as shown

below:

HRESULT ( STDMETHODCALLTYPE *get_HWND )(

__RPC__in IWebBrowser2 * This,
 __RPC__out SHANDLE_PTR *pHWND);

It takes 2 parameters, the first is the pointer to the COM object and the second is the pointer to the
variable that receives the handle of the window.

This way, we can easily analyze all the methods exposed by the IWebBrowser2 interface.

We get the handle to the window corresponding to the CLSID of Microsoft Internet Explorer.

SetWindowLongW: It calls SetWindowLongW() to set the GWL_EXSTYLE of the Internet Explorer

window to WS_EX_NOACTIVATE. This way, the window will not become the foreground window
even when the user clicks it.

It calls SetWindowLongW() again to set the GWL_STYLE of the Internet Explorer window to
WS_CHILD as a result of which it will not have a menu bar.

SetParent: It then sets the parent window of the Internet Explorer as the window created above
(with the UUID).

IWebBrowser2.put_Visible: It calls the put_Visible method to set the visible property of the
Internet Explorer window to hidden.

SysAllocString: It allocates a string to store the URL to which the network callback will be made.
IWebBrowser2.Navigate2: It calls the Navigate2 method exposed by the IWebBrowser2
interface to navigate to the above URL.

Once we execute this function, it will send a GET request to the callback server.

As we observed previously that it receives an encrypted response. Let us see how this response is
decrypted.

IWebBrowser2.get_Document: It calls the function at offset 0x48 in the IWebBrowser2 interface

to retrieve the pointer to IDispatch interface of the document object, which will be used to fetch
the HTTP response.

IUnknown_QueryInterface_Proxy: Next it queries the IDispatch interface of the document object

for the IID of IHTMLDocument2 as shown below:
If we look up the IID: {332C4425-26CB-11D0-B483-00C04FD90119} in the
HKEY_CLASSES_ROOT\Interface key in Windows Registry, we can see that it corresponds to
IHTMLDocument2 interface.

The above function will return us a pointer to the IHTMLDocument2 interface.

Now, to trace the code further, we need to understand the IHTMLDocument2 interface and the
methods exposed by it. We look up the header file, Mshtmlc.h and find the interface defined here:

typedef struct IHTMLDocument2Vtbl

{
BEGIN_INTERFACE

HRESULT ( STDMETHODCALLTYPE *QueryInterface )(

__RPC__in IHTMLDocument2 * This,
/* [in] */ __RPC__in REFIID riid,
/* [annotation][iid_is][out] */
__RPC__deref_out void **ppvObject);

It is also important to note that we should check the Interface definition for C and not C++ since
the order of methods exposed by the interface differs between the two.

IHTMLDocument2.get_readyState: It uses this function to determine if the object has completed

loading the data.
IHTMLDocument2.get_body: It calls the function at offset 0x24 in the IHTMLDocument2
interface to retrieve the body object of the HTML response.

This will return us a pointer to the IHTMLElement Interface.

Once again, we look up the header file, Mshtmlc.h for the methods exposed by the IHTMLElement
Interface as shown below:

typedef struct IHTMLElementVtbl

{
BEGIN_INTERFACE

HRESULT ( STDMETHODCALLTYPE *QueryInterface )(

__RPC__in IHTMLElement * This,
/* [in] */ __RPC__in REFIID riid,
/* [annotation][iid_is][out] */
__RPC__deref_out void **ppvObject);

IHTMLElement.get_innerText: It then calls the function at offset, 0xf0 in the IHTMLElement

interface to retrieve the inner text in the HTML response.

Here innerText refers to the content in the HTML response between the tags: <html><body> and
</body></html>, which in our case is the encrypted response.

Once the encrypted response is read, it is converted to ASCII from UNICODE.

 Response Decryption Stage
The encrypted response is first decoded from ASCII to binary using Base64 Decoding algorithm.

Now, let us see the main decryption routine:

It takes 3 input parameters:

 1. Pointer to the encrypted binary response.
2. Size of the encrypted data.
3. 0xF4 bytes key

The decryption routine will first generate a Permutation Table of size 0x100 bytes using the 0xF4
bytes decryption key.

This permutation table is then used again in XOR decryption of the binary response. This
decryption routine is similar to the one we saw previously.

You can see the decrypted response in the memory dump below:

Parsing the Decrypted Response

In the next stage, it parses the decrypted response. First it verifies that the length of response
received is equal to the original length expected.

The original length is stored as the second DWORD in the response, in our case: 0x03E5D4. This is
the total length – 0xC bytes because the first 0xC bytes store data for verification.
In the second stage of verification, it calculates the hash of the total decrypted response using a
single byte key, 0x7F as shown below:

The calculated hash is compared with the hash stored in the decrypted response as the first
DWORD, in our case, 0xAF7EF27A

It then compares the strings stored in the response with “core”. The strings stored in response
are: “clk”, “ppc” and “core”. This is done to locate the correct offset, which will be used to locate
the binary in the response.
Once it locates the string, “core”, it will copy 0x3E58A bytes to a new buffer.

It then extracts the binary from the response as shown below:

1. Reads the size of the binary at offset: 0x40C

2. The binary is stored at offset, 0x614.
3. It copies 0x5600 bytes of the binary to a new buffer.

Similarly it extracts the second binary embedded in the decrypted response by copying, 0x38800
bytes to a new buffer.
Once both the binaries are copied from the decrypted response to new buffers, it parses the
binaries.
Binary 1:

It copies the sections of the binary one by one to a new buffer. It then parses the PE header,
locates the AddressOfNames in Export Directory and reads the module name, MozSvcs64.dll.

The decrypted binary will be written to the file, MozSvcs64.dll.

In this way, we can see how the decrypted response is parsed to extract malicious binaries to
carry the attack forward.
Conclusion
After reading this paper, you will be able to reverse the encrypted network communication
performed by most viruses these days and gain a better understanding of the data being
exfiltrated, the data received in response from attacker’s server and code execution flow.

Also, as we can see, even the modern day viruses do not use complex encryption methods or
custom encoding techniques. There is a lot more scope in the encryption of data exchanged with
the callback servers.

References
http://msdn.microsoft.com/