Talk to you later

Thousands of unsuspecting chat users clicked on a malicious link a few months ago. A spam message contained a link that led to a worm being downloaded, which, in turn, downloaded a component that sent more copies of the spam message.

This article will look into the detail of the malicious executable that sent the spam messages. Variously dubbed ‘Phopifas’, ‘Dorkbot’ and ‘Rodpicom’, we will walk through its code and see how it persuades users to click the malicious link.

SEH (Structured Exception Handling) is a common technique used by malware to obfuscate the execution path or misdirect debuggers. Phopifas takes advantage of the SEH technique to discourage analysts from probing further.

After setting up a cursor and window with the name ‘Tabs Example’, which is not shown, the malware goes into an exception handling loop which repeats 1,048,575 (0xFFFFF) times. The malware sets up a decrementing counter that is triggered every time it encounters an exception. The intentional exception is triggered by calling the LoadLibraryA API with the library name 0x3E8.

After painstakingly completing the exception loop, the malware jumps to the decryption routine.

Using the VirtualProtect API, the malware changes the protection of its encrypted area to PAGE_EXECUTE_READWRITE, making it executable, readable and writable.

Phopifas uses a simple XOR decryption algorithm (XOR DWORD PTR DS:[EBX], EAX) with decrementing key values starting with 0x00053E73. Each decryption uses a dword taken from the starting location of the encrypted area and XORed with the key. The pointer (EBX) only moves one byte at a time, thereby decrypting each byte four times (with the exception of the first three bytes).

The total size of the encrypted area is 1,456 (0x5B0) bytes.

Using a simple XOR algorithm for decryption is usually a giveaway, but for this malware it isn’t. This simple XOR is embedded in a labyrinth of 615 JMP instructions. Figure 1 shows a typical JMP instruction in the malware code. These JMP instructions only skip a few bytes which are not used in the execution of the malware. These so-called garbage bytes are used to harden the emulation. Every execution of the XOR instruction should be done after passing through this series of JMP instructions.

The 615 jumps are not designed to frustrate the analyst; they are designed to exhaust the limitations of emulator engines. Some engines might deem these jumps to be infinite, thereby deciding to terminate the emulation process.

Figure 1. A typical JMP instruction in the malware code.

After decryption, the malware parses the PEB (Process Environment Block) to get the imagebase of kernel32.dll. From the given imagebase, the malware computes the hash values of each of the exported API names of kernel32.dll until it finds the equivalent hash value of the API it needs. The hash value of the APIs are computed using simple ADD (addition) and ROL (rotate left) instructions.

The malware doesn’t store the imagebase value to a memory location, thus it needs to parse the PEB every time it needs to use an API.

The first API to be resolved is LoadLibraryA. Using this API, the malware tries to get the imagebase of kernel32.dll. Yes, it parses the PEB to get the imagebase of kernel32.dll and it also uses the LoadLibraryA API to get the same imagebase. The malware checks whether the location contains an ‘MZ’ value. If ‘MZ’ is not found, the malware terminates.

If kernel32.dll is found, it tries to get the imagebase of ‘WakeUpRage.dll’. If the library exists, the malware will also terminate.

The resource section of the malware contains the key string, the malware size and the encrypted malware code. The malware extracts these pieces of information by using the LoadResource API to load the individual resources into the memory.

The first resource taken is the key string ‘rfvM6AVLq8mLb r4duRPqFKEDYAAY9g0MHGmBDAcKwjn3o’. It saves this string to a memory location for later use.

The malware finds and loads another resource (‘12800’) and again stores it in a memory location. It converts the string ‘12800’ to an integer using the StrToIntA API. The integer value is used as the size in allocating a new virtual memory space for the encrypted malware code.

The rest of the resource section contains the remainder of the encrypted malware code. This is allocated to the memory location prepared earlier by the VirtualAlloc API with the size 12800.

After obtaining all the required hex bytes from the resource section of the malware body, Phopifas performs a simple decryption using an XOR instruction. The XOR key is the string ‘rfvM6AVLq8mLbr4duRPqFKEDYAAY9g0MHGm BDAcKwjn3o’, which was taken earlier as the first resource value.

The malware will read one byte from the allocated memory and XOR it to one character taken from the key string. There are two pointers at work here. One is for the bytes in allocated memory and the other is for the key string. The pointers move one byte forward after every XOR operation. When the pointer used for the key string reaches the end of the string, it will reset to zero to point back to the first character.

After decryption, the malware spawns a new process using the original executable. It overwrites the image of the new process by writing the newly decrypted code using a combination of the GetThreadContext and WriteProcessMemory APIs. The decrypted code is simply injected into the newly running process.

The malware transfers control to the newly spawned process and terminates the original one. This methodology effectively executes other payloads of the malware while avoiding any breakpoints set by analysts.

Following the execution of the newly created process, the malware creates a mutex, ‘{D8E33D0B-0106-46E7-AD6D-225A1797C7CE}’, to avoid running multiple instances of itself (see Figure 2).

Figure 2. A mutex is created.

The malware determines the country of residence of the infected user by checking the locale of the operating system (LOCALE_SYSTEM_DEFAULT 0x800 and LOCALE_SABBREVCTRYNAME 0x07) using the GetLocaleInfoA API.

Phopifas traverses the list of running processes using the CreateToolhelp32Snapshot, Process32FirstW and Process32NextW APIs. It checks whether ‘skype.exe’, ‘msmsgs.exe’ or ‘msnmsgr.exe’ exist in the list of processes – each of which is an executable used by a messaging application.

Once the malware has taken control of the messaging applications, it sends spam messages to the users found in the application. The messages (the content of which depends on the locale of the originating computer) include a download link for other malware. Figure 3 shows a typical spammed message sent through a messaging application.

Figure 3. Typical spammed message.

Table 1 shows a (non-comprehensive) list of the messages sent, based on country codes. The country codes are checked within the malware code.

Figure 4 shows the unicode strings of the spam message found in the malware’s memory. The unicode values will be translated based on the locale setting of the machine and the language set by the messaging application. The same unicode values will be converted to their equivalent characters for the given locale.

Figure 4. Unicode strings of the spam message found in the malware’s memory.

Every one of us uses some sort of messaging application. Whether standalone or web-based, we all use messaging applications to communicate with our colleagues, friends and families. Their ubiquity is the reason why malware authors exploit the human factor to target them.

As with email spams, if we don’t click on the links contained in the spam messages, the malware won’t be downloaded. We should all be cautious of the messages we receive, even if they appear to have come from family members or friends – their accounts could be under the control of malware.