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 INCLUDED 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. PUSH 800048DE CALL DWORD PTR DS:[ PUSH 80002381 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:[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 INSTRUCTIONS 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:[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. 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. 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: 77E37251 ADVAPI32.CreateServiceW 77DE5BED ADVAPI32.CloseServiceHandle 77DF0E4A ADVAPI32.QueryServiceStatusEx 77DF25D8 ADVAPI32.StartServiceA 77DED705 ADVAPI32.OpenSCManagerA 77DEE2AE ADVAPI32.OpenServiceA 7C810647 kernel32.CreateThread 7C80B4DF kernel32.GetModuleFileNameA 7C809F01 kernel32.InitializeCriticalSection 7C80BAB1 kernel32.lstrcmpiA 7C80180E kernel32.ReadFile 7C86158D kernel32.WinExec 7C83647C kernel32.GetPrivateProfileIntA 7C9010E0 ntdll.RtlLeaveCriticalSection 7C85D653 kernel32.MoveFileExA 7C901000 ntdll.RtlEnterCriticalSection 7C8323A9 kernel32.LockFile 7C80B6B1 kernel32.GetModuleHandleA 7C80ADB0 kernel32.GetProcAddress 7C8356A3 kernel32.MoveFileExW 7C8359FF kernel32.GetTempFileNameW 7C80B984 kernel32.UnmapViewOfFile 7C80B915 kernel32.MapViewOfFile 7C809478 kernel32.CreateFileMappingA 7C801625 kernel32.DeviceIoControl 7C831F7B kernel32.DeleteFileW 7C810770 kernel32.CreateFileW 7C82F88F kernel32.CopyFileW 7C809930 kernel32.GetCurrentProcessId 7C8307A5 kernel32.GetTempPathW 7C8017E5 kernel32.GetSystemTimeAsFileTime 7C80E44D kernel32.GetModuleHandleW 7C832B9E kernel32.GetPrivateProfileStringA 7C831EF5 kernel32.DeleteFileA 7C810A87 kernel32.GetFileSize 7C810D97 kernel32.WriteFile 7C860B1F kernel32.GetTempFileNameA 7C835E12 kernel32.GetTempPathA 7C830A82 kernel32.QueueUserWorkItem 7C802442 kernel32.Sleep 7C809AF4 kernel32.VirtualFree 7C809A61 kernel32.VirtualAlloc 7C835D9C kernel32.WritePrivateProfileStringA 7C809B57 kernel32.CloseHandle 7C801A24 kernel32.CreateFileA 7C8314F5 kernel32.SetFileAttributesW 7C812792 kernel32.SetFileAttributesA 7C8092B8 kernel32.GetTickCount 7C8286FE kernel32.CopyFileA 7C90FE21 ntdll.RtlGetLastWin32Error 71B2B2C0 MPR.WNetOpenEnumA 71B2AC75 MPR.WNetEnumResourceA 71B230D7 MPR.WNetCloseEnum 76BF1EB8 PSAPI.GetMappedFileNameA 76BF1E20 PSAPI.GetMappedFileNameW 77E987CB RPCRT4.UuidCreateSequential 7CAB4FD0 SHELL32.ShellExecuteW 77FA8E23 SHLWAPI.PathAddExtensionA 77FA707E SHLWAPI.PathRemoveExtensionA 77F67CA9 SHLWAPI.PathFileExistsW 77F70D83 SHLWAPI.SHGetValueA 77F780C4 SHLWAPI.PathFindFileNameA 77F76494 SHLWAPI.PathAppendA 77F73C33 SHLWAPI.SHSetValueA 77FA6F6F SHLWAPI.PathFileExistsA 77FA14D9 SHLWAPI.SHDeleteValueA 77F66813 SHLWAPI.PathRemoveExtensionW 77F66F97 SHLWAPI.PathFindFileNameW 77F6967F SHLWAPI.SHSetValueW 77F64597 SHLWAPI.SHGetValueW 77D4ACE9 USER32.CharUpperBuffA 77D4DF6B USER32.DefWindowProcA 77D6F002 USER32.CharLowerBuffA 77D5760B USER32.IsCharAlphaA 77D4DED3 USER32.SetWindowLongA 77D6A101 USER32.RegisterDeviceNotificationA 77D6EA45 USER32.GetMessageA 77D48BCE USER32.TranslateMessage 77D4BCBD USER32.DispatchMessageA 77D664EF USER32.UnregisterDeviceNotification 77D4E666 USER32.DestroyWindow 77D5190B USER32.CreateWindowExA 771C4D3C WININET.InternetCloseHandle 771C827C WININET.InternetReadFile 771BB195 WININET.InternetSetOptionA 771B7153 WININET.InternetQueryOptionA 771C60C9 WININET.HttpSendRequestA 771C3674 WININET.HttpOpenRequestA 771C573E WININET.InternetOpenA 771C308A WININET.InternetConnectA 771C7519 WININET.InternetCrackUrlA 7300E3C9 WINSPOOL.AddPrintProvidorW 7C92D195 ntdll.LdrAddRefDll 7C966671 ntdll.RtlRandom 7C901295 ntdll.RtlInitUnicodeString 7C9243CE ntdll.atol 7C910339 ntdll.RtlImageNtHeader 7C91BA32 ntdll._snwprintf 7C9718AA ntdll._snprintf 7C90281D ntdll.strncpy 7C90D08E ntdll.ZwCreateEvent 7C902435 ntdll.memset 7C9015F8 ntdll._chkstk 775285D3 ole32.CoInitialize 774F41C0 ole32.CoUninitialize 77526009 ole32.CoCreateInstance

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.

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 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.

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. Safe computing to all!