Analyzing Dropper:

The same as the shellcode, Dropper also used a decryption function to transform themselves by XOR with 0xCC value. Then, it was parsing kernel32.dll and getting the addresses of APIs.

In addition to getting the address of LoadLibrary function in kernel32.dll, Dropper used a decryption function to get the address of other libraries.



Figure 7. APIs were getting by Dropper from DLLs

In order to make difficulties in the process of static analysis, shellcode was built by using encryption and decryption to get the addresses of APIs from DLLs, and Stack.

Thanks to APIs’ name and location on Stack, we recognized more clearly the tasks of shellcode. Firstly, Dropper had accessed to the following keys in the Registry:

  • HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Word\Resilency
  • HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Word\Resilency

In this analysis, our version of Office 2007 was 12.0.

This is an assembly code showing access to Office application which was analyzed and annotated with name of functions:

After accessing the registry, the Dropper transformed 0x12800 bytes, beginning at location of the 0x8030 offset, from .DOC file to a buffer allocated by GlobalAllocfunction.

The data in the buffer was decrypted by XOR with the 0xBB value.

Then, we were surprised to see the “MZ” letters, the signature of PE File, on screen. As a result, this Dropper extracted a PE file encrypted in .DOC file and allocated at the 0x8030 value, patched the necessary bytes to create a PE file, which aims of avoiding the detection of the AV.

In addition to writing a PE file into the Credentials folder with the name Credentials.dll, this Dropper also performed the following tasks:

  • Creating key Software\Microsoft\Windows\CurrentVersion\Run\Credentialswith“rundll32.exe%USERPROFILE%\ApplicationData\Microsoft\Credentials\Credentials.dll, SSSS”
    • The DLL will be enabled when the operating system boots.
  • Creating a fake .DOC file in the TEMP folder, 0x6E00 bytes of data retrieved from the original .DOC file are at the 0x1AFE2 location.
    • Creating a fake .DOC file in order to fool users.
  • If “Software\KasperskyLab” key existed, ExitProcess function would be executed.
  • Running this fake .DOC file using WinExec

This is the assembly code showing that the Dropper had executed the analyzed functions:

Analyzing Credentials.dll:

After decrypting and patching this .DLL file, we received a completed file. This file had been packed by UPX and ACProtect 1.3x-1.4x DLL -> Risco Software Inc. When unpacking this file, we received several results:

Thanks to the specific characters, we recognized that this file were originated from Chinese.

Subsequently, we analyzed .DLL file by IDA Pro. In the Export Section, there are four functions. The SSSS function, one of four found functions, had been used to run DLL through rundll32.exe.


Figure 8. The functions had been exported by Credentials.dll

When observing the Import Section, we paid more attention to two functions –GetProAddress function and LoadLibrary function – which were often used to get the address of APIs from DLL. In addition to, many familiar functions were here such as CreateFileA, CreateProcessA, HttpSendRequesA, InternetReadFile, RegSetValueExA…

This means these APIs were loaded while running the DLL. In order to analyze easily, we renamed the memory area corresponding to the name of the APIs.


Figure 9. The APIs functions were found in the analysis

The API, named “HttpOpenRequestA”, created a connection via port 80 to a certain webserver. After tracing a function calling this API, we found that“InternetConnectA” API used a first parameter, a URL of webserver. Besides, we found that this URL, responsible for calling decryption function to create a URL to support a connection, is of location in the SSSS function.

After debugging the SSSS function by IDA Pro, we found the task of the SSSS function:

The SSSS function called a function responsible for decrypting URL:


This DLL used three hosts to upload three .jpg file to the victim’s computers.

After checking the version of the operating system, we received the numbers (4, 6, 8), corresponding to a “SysWOW64” directory and 64-bit OS. In addition, we found a PE file embedded into the DLL.

This function was encrypted by the 0x90 key and was decrypted while running the DLL. The returned result was written into the Temp folder and overwrote the original DLL. The DLL-64bit file included some information:

  • Its content is the same as the DLL-32bit file.
  • .Init section was overwritten by the URL’s data, encrypted by the DLL-32bit.
  • Debugging information:

Then, the SSSS function called the Embedding function from Credentials.dll. The Embedding function is responsible for checking whether it was running byrundll32.exe or not. If it is true, it will call a function performing the following tasks:

The sub_10039Fb function decrypted a URL to transform a result into a global memory of the program.


Figure 11. The mainTask function performed the main task of the Credentials.dll.

We received a returned result when tracing the mainTask function:

The mainTask function processed URL depending on the version of OS and transmitted decrypted URL to connect via port 80. Then, the iexplorer.exe downloaded three .jpg file from the hosts and saved as up[random].msi at the Task folder in Application Data.


Figure 12. A file was downloaded from one of the URLs

A file was downloaded from a server, via port 80:


Figure 13. A task connected to the host and downloaded a file.

After this file was downloaded, the DLL found and checked whether this file was a PE file or not. If true, a process was created and executed the downloaded file.

The extensions:

Some information was found when analyzing the .DOC file:

The IP address of the hosts:

Host IP

The information of the server (



The information of the server (


The information of the server (


The conclusion:

This .DOC file is the means of an intentional attack.



The reference:








(Part 1)

No Comments
Post a Comment