REVERSING RORPIAN – DHCP Hijacking Malware
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.
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.
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]
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
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 .
Since 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.
CALL DWORD PTR DS:[
CALL DWORD PTR DS:[
JMP SHORT 00401268
THE REST OF IT
The 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:,0D
0040125E XOR DWORD PTR DS:[4060F0],64E3
00401269 ROL DWORD PTR DS:[4062D0],6
00401287 SHR DWORD PTR DS:,0A
00401291 XOR DWORD PTR DS:[40623C],1EC7
0040129E SHL DWORD PTR DS:[4062B4],0B
004012AB MOV DWORD PTR DS:,6989
004012B9 MOV DWORD PTR DS:,EBX
After 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:,EDI
00401279 TEST EAX,EAX
0040127B MOV DWORD PTR DS:,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.
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.
The jump instruction, JB 008A76B9, from Figure 3, jumps to the very start of the decryption algorithm (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.
When the instruction pointer reaches the address 0x008A7948, it means that it is done decrypting our malware code.
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.
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:
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.
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 )
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:
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.
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 RORPIAN
One 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.
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.
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.
Safe computing to all!