Skillset

We have seen our fair share of malware codes from time to time. With the help of disassemblers and debuggers, we have a shot of understanding them. But malware are not that simple to understand, one has to know assembly language. But even knowing the language is not enough by itself, most of the latest malware, if not all, are either packed, encrypted or anything in between.

This paper will be the first of many; in helping us understand deciphering codes that malware has to offer. We will walk through detailed specifics on our way to continuing to help you understand how malware works.

Rorpian worm is the first in line. We will discuss some of its decryption algorithm, how and where it injects its code and some of its common malware activities.

INITIAL DECRYPTION

Rorpian initially allocated a virtual memory space to copy itself. But it doesn’t copy the code as is. It uses a simple decryption algorithm that preserves some of the original malware code and at the same time generates part of the second decryption algorithm.

The malware started decrypting codes at the very end of the file in memory. It decrypted the code using the algorithm shown in Figure 1. Each and every passed on the algorithm generates a single byte and copies it to the allocated virtual memory.

It started slowly. Due to the fact that it is decrypting the code starting at the end of the file, it only produced zeros for at least a couple of hundred bytes. After a couple more dozen bytes, we finally came out with some hexadecimal values that seems unreadable to the naked eye. But after finishing the initial decryption algorithm, we can see that it actually produced almost the same copy of the original malware in the memory. Well, almost.

Figure 1

DISSECTION OF THE INITIAL DECRYPTION

Let’s now take a closer look at the decryption algorithm. The decryption algorithm, shown on Figure 1, looks similar to a regular decryption routine that we seldom see in a malware. But if we take a closer look, you will find out that everything is not what it seems.

The value from DWORD PTR SS:[EBP+10], contains the COUNTER or the number of iterations this block of code will be executed. Its initial value is 0x16000 and will end up at 0. (The counter is counting backwards.)

After executing the first 3 instructions of this decryptor,

MOV EAX,DWORD PTR SS:[EBP+10]

MOV ECX,DWORD PTR SS:[EBP+10]

PUSH EAX,

EAX and ECX registers will contain the value of the counter which is initially 0x16000 and the content of the EAX is then saved to the top of the stack.

Every time the block of code is executed, the first few things that it does is to initialize EAX and ECX with the latest value of the counter and save it at the top of the stack.

And here is that part of the code that applies the “not everything is what they seem to be”.

The following codes below looks complicated but they are not. It actually doesn’t do anything. The last jump instruction, JGE 00401249, will always jump to address 00401249.

1. MOV EAX,DWORD PTR DS:[4064EC]

2. MOV DWORD PTR DS:[EAX],4DDB

3. MOV EAX,DWORD PTR DS:[4064EC]

4. MOV EAX,DWORD PTR DS:[EAX]

5. ADD EAX,004064EC

6. SUB EAX,DWORD PTR DS:[4064EC]

7. ROL EAX,2

8. SUB EAX,2D09

9. ROR EAX,3

10. AND EAX,1CCD

11. CMP EAX,4C

12. JGE 00401249

Let’s see.

At instruction 1, EAX contains any word value from address 0x004064EC (assume that it is 0x004060EC),

EAX = 0x004060EC

At 2, the address pointed by EAX will contain 0x4DDB,

At 3, EAX = 0x004060EC (same as instruction 1)

At 4, EAX will now contain 0x4DDB

At 5, EAX = 0x4DDB + 0x004064EC = 0x0040B2C7

At 6, EAX = 0x0040B2C7 – 0x004060EC = 0x51DB

At 7, EAX = 0x0001476C (after the ROL instruction)

At 8, EAX = 0x0001476C – 0x2D09 = 0x11A63

At 9, EAX = 0x6000234C (after the ROR instruction)

At 10, EAX = 0x6000234C AND 0x1CCD = 0x4C

At 11, the result of CMP EAX,4C will always be TRUE because after the computation, the result will always be 0x4C, therefore At 12, it will always jump to address 0x00401249 .

NOT INCLUDEDSince it will always jump to address 0x00401249, the instructions below will never be executed. The malware includes call to APIs (Application Programming Interface) all throughout the file, but most of them are not called or executed.

PUSH 800048DE

CALL DWORD PTR DS:[

PUSH 80002381

CALL DWORD PTR DS:[

JMP SHORT 00401268

THE REST OF ITThe instructions starting at address 00401249, are not all relevant to the whole decryption routine.

The list of instructions below is only modifying a specific memory location:

0040124F SHR DWORD PTR DS:[4061B8],6

00401256 SHR DWORD PTR DS:[406104],0D

0040125E XOR DWORD PTR DS:[4060F0],64E3

00401269 ROL DWORD PTR DS:[4062D0],6

00401287 SHR DWORD PTR DS:[406318],0A

00401291 XOR DWORD PTR DS:[40623C],1EC7

0040129E SHL DWORD PTR DS:[4062B4],0B

004012AB MOV DWORD PTR DS:[406058],6989

004012B9 MOV DWORD PTR DS:[406308],EBX

RELEVANT INSTRUCTIONSAfter weeding out the instructions listed above, the rest of the codes are explained below:

00401249 XOR DWORD PTR DS:[4061A8],EDI

- EDI, starting address of allocated memory, is stored at 0x004061A8

0040125D POP EAX

EAX contains the counter

00401268 DEC ECX

decrements the counter

00401270 MOV DWORD PTR SS:[EBP+10],ECX

saving the counter to [EBP+10]

00401273 OR DWORD PTR DS:[406254],EDI

00401279 TEST EAX,EAX

0040127B MOV DWORD PTR DS:[406174],EAX

checks if the counter plus the starting address of the allocated memory is the same as the starting address of the allocated memory

00401281 JE df5a4cf5.004012C4

this instruction will jump out of the decryption routine

0040128E MOV EAX,DWORD PTR SS:[EBP+8]

EAX contains the starting address of allocated memory

0040129B ADD EAX,DWORD PTR SS:[EBP+10]

EAX contains the address of allocated memory plus counter

004012A5 MOV ECX,DWORD PTR SS:[EBP+C]

ECX contains the starting address of the running program

004012A8 ADD ECX,DWORD PTR SS:[EBP+10]

ECX contains starting address of the malware and counter

004012B5 MOV CL,BYTE PTR DS:[ECX]

CL contains the byte pointed by the ECX

004012B7 MOV BYTE PTR DS:[EAX],CL

copies CL to the allocated memory

004012BF JMP df5a4cf5.004011F1

jumps back to the start of the decryption routine

After a long analysis of this decryptor, only few bytes change from the original codes. The whole 0x16000 iterations of the decryptor code just basically copy the malware to the allocated memory.

The decryptor doesn’t do much, but we saw that some codes even though it looks complicated, they basically just don’t do anything. Even API calls can be deceiving. All throughout the malware code: the original file has lots of instructions that are NOT needed; there are lots of APIs that don’t belong on the actual malware activities. They are designed to make analysis harder.

There are still some layer of sort-of decryptor that lies somewhere in the malware code. But now, we will look into the decryptor that generates the actual malicious codes.

DECRYTOR 2

It started by allocating another virtual memory. This decryptor is way longer than the previous one. We will not walk through each and every code for this decryptor; we will just point to the locations where we can find the important aspect of any decryptor in general.

This decryptor is running at the virtual memory, 0x008A0000, previously created by the initial decryptor.

The initialization of the registers and memory variables before the actual decryption starts at 0x008A7652 (Figure 2). While the end of the whole decryption routine is at address 0x8A7942(Figure 3). A total of 752 (0x2F0) lines of code.

Figure 2

Figure 3.

The jump instruction, JB 008A76B9, from Figure 3, jumps to the very start of the decryption algorithm (Figure 4).

Figure 4.

Another important aspect in analyzing a decryptor is where it will jump out after decrypting everything. In this decryptor, we can find that exit point at address 0x008A7948(Figure 5), just right below the jump to the very beginning of the decryptor algorithm.

Figure 5.

When the instruction pointer reaches the address 0x008A7948, it means that it is done decrypting our malware code.

THE MALWARE

When analysing a malware that is highly encrypted, the first thing to determine if we are doing it right is, if we see some strings generated. The strings in Figure 6 can be seen after the decryptor 2 is fully executed. It has rich information regarding the malware operation. (The IP address was intentionally modified to avoid unnecessary infection from the reader.)

Rorpian tries to download and executes the file from the IP address shown.

Figure 6.

APPLICATION PROGRAMMING INTERFACE (API)

APIs are built-in functions from Windows DLL files; they are the very heart of any Windows application. By listing the APIs used by the malware, we can basically have an idea on what the malware does.

Below is the partial list of APIs(Application Programming Interface) used by Rorpian:

DROPPED FILE

Rorpian drops a copy of itself in the %temp% folder, with a filename format of srvYYY.tmp. The filename always starts with “srv” followed by the unique processID of the malware, in hexadecimal value, and the extension TMP. This TMP file will be injected to spoolsv.exe process.

The malware also drops an INI file using the TMP’s filename. Figure 7 shows the code snippet for creating the srv files.

Figure 7.

CODE INJECTION

Code injection is the method of loading or adding the malware code to a running process. It can be the complete malware or just a partial code. Injecting codes to a running process ensure that the malware is still running even if the original file execution terminates.

Rorpian injects its code to spoolsv.exe process. One way to know if it already injected its code is by selecting spoolsv.exe process in Process Explorer (from sysinternals) and looking for the file SRVxxx.TMP from the list of files loaded.

(See Figure 8 )

Figure 8.

AS A WORM

Once Rorpian is loaded in spoolsv.exe process, it launches its other malicious activities like dropping files in a shared folder. Rorpian dropped files if a network shared folder is found in the infected machine. The dropped files listed below can be seen in the shared folder:

setupXXXXX.fon

setupXXXXX.lnk

myporno.avi.lnk

pornmovs.lnk

autorun.inf

XXXXX in the filename is a random number generated by Rorpian. The file setupXXXX.fon is an exact copy of the first dropped file, srv52C.tmp, which is loaded in the spoolsv.exe process. The lnk files are shortcut files which exploits the vulnerability that automatically launches the setupXXXX.fon. The autorun.inf file is also created to launch the malware when the shared folder is accessed. Figure 9 shows the snapshot of the code that will drop the files and Figure 10 shows the dropped files in the shared folder.

Figure 9.

Figure 10.

DHCP Hijacking

DHCP (Dynamic Host Configuration Protocol) is designed to assign dynamic IP addresses to the computers connected to the network. It greatly helps network administrator in allocating the IP addresses for the computers connected to a given network. It also helps to avoid using duplicate IP addresses.

The DHCP protocol makes sure that the IP addresses given to a single machine will not be in conflict with the rest of the devices. The DHCP server can automatically assign the IP address, subnet mask, default gateway and DNS servers for any client computer connected to the network.

Figure 11.Normal DHCP network setup

DHCP hijacking is a method of intercepting the client’s request for IP addresses from the DHCP server. The hijacking computer intercepts the request before it reaches the valid DHCP server. Note that – the hijacker machine can be any machine connected to the network. Its main purpose is to give the client an IP addresses that is suited for its malicious goal.

Figure 12.Hijacked network setup

HIJACKED BY RORPIANOne of the main payload of Rorpian is to hijack the DHCP requests made by the computers connected to a network.

Once a single machine is infected by Rorpian, it immediately checks if it is connected to a network. It also checks if the network uses DHCP protocol. Once those checks had been satisfied, it will launch a network listener.

This network listener intercepts DHCP request from the client machines connected to the network. It basically acts as a DHCP server but it only changes the DNS server IP of the client machines.

The new DNS server is a malicious server registered to Rorpian. Any attempts to connect to any website will be checked first against this malicious DNS server. Some reports say that it may also ask for a browser update, (It is not evident during the writing of this paper), which may lead to downloading the malware.

Figure 13.

If the DNS server is not active (as of the case in this writing) you will get a “Server not found” error from your browser as shown in Figure 13. You might find a hard time troubleshooting the problem, because they worked before. You can even scan your machine for viruses but it will show nothing. Perhaps, one of the machines connected to the network is infected by Rorpian.

Figure 14 shows part of the code responsible for the DCHP hijacking. It uses common APIs, like inet_addr and socket, from the Ws2_32.dll; this DLL file contains APIs related to network connections, network protocols, internet access, and so on.

Figure 14.

CONCLUSION

Reversing Rorpian is a bit challenging task. We won’t be able to walkthrough the code if we haven’t seen that it is injecting its code to spoolsv.exe. We can only observe the decryption and the dropping of the srvYYY.tmp file while we are reversing the original malware. But most of its activities are executed within the spoolsv.exe process.

Another interesting fact about Rorpian is its DHCP hijacking. It is a subtle way of redirecting users to a malicious website or a way of downloading the malware. Who would have guessed that somebody just messed up with your DNS server?

We have seen that DHCP hijacking is just a matter of programming. Given the existence of malware capabilities like code injection, code hooking, complicated encryption algorithm, memory manipulation – DHCP hijacking is not really far-fetched. This kind of attack is just around the corner. We will see more of these in different varieties and different combinations. But who is being caught in the crossfire? Of course, us, the users who thought that we were still safe because we installed a couple of antivirus in our computer.

We need more proactive approach against DHCP hijacking. Maybe AV companies needs to have a way of determining if DNS or DHCP setup has been compromised. Or, maybe we can also proactively check if something or someone is waiting to intercept a machine’s request for a DHCP configuration and see if it is valid. Or, maybe, we need to educate our users to be vigilant in anything and everything security.

More Posts by Author

About InfoSec

InfoSec Institute is the best source for high quality information security training. We have been training Information Security and IT Professionals since 1998 with a diverse lineup of relevant training courses. In the past 16 years, over 50,000 individuals have trusted InfoSec Institute for their professional development needs!

Join our newsletter

File download

First Name

Last Name

Work Phone Number

Work Email Address

Job Title

Does your employer pay for training?

What is your timeline for training?

InfoSec institute respects your privacy and will never use your personal information for anything other than to notify you of your requested course pricing. We will never sell your information to third parties. You will not be spammed.

Comments

What is Skillset?

Skillset

Practice tests & assessments.

Practice for certification success with the Skillset library of over 100,000 practice test questions. We analyze your responses and can determine when you are ready to sit for the test. Along your journey to exam readiness, we will:

1. Determine which required skills your knowledge is sufficient
2. Which required skills you need to work on
3. Recommend specific skills to practice on next
4. Track your progress towards a certification exam