Deep Dive into a Custom Malware Packer

Introduction

In this article we will look in depth at a Custom Packer used by a Malware that was recently found in the wild. This packer is interesting for several reasons. It uses several layers of packers including the well-known UPX Packer which is only used to mask the underlying custom packers.

It also uses a clever way of injecting code into a remote process and resuming its execution from there. I have included necessary screenshots with snippets of assembly language code sections along with comments, stack parameters for API calls and views of memory dump. This will help in following the article while the unpacking method is described.

An Overview

Since the unpacking method is described in depth and there are several layers, I am giving a high level overview of the algorithm at first before going in depth.

  1. It uses a UPX packer which is used only for the purpose of masking the underlying custom packers. UPX packers as we know can be easily unpacked.
  2. The first layer of a custom packer uses a lot of code which has been placed only to increase the size of code we have to go through while reversing. With the help of few example code snippets, this has been explained. It’s used to deter reverse engineering.
  3. It stores the encrypted subroutine at a particular offset within itself. This subroutine is later decrypted and executed.
  4. In the second stage, the decrypted subroutine performs another level of unpacking. There is an encrypted malicious executable embedded inside the main image which is decrypted in two phases.
  5. After the decryption of the malicious executable, it proceeds to modify the header of the main image. It copies the various sections of the malicious executable like PE Header, .text, .rsrc, .reloc to the start of main image.
  6. It then calls the AddressOfEntry point of the malicious executable. This code will spawn a new process, svchost.exe in a suspended state.
  7. It then proceeds to inject the malicious code in svchost.exe process and resume its execution.

Unpack the UPX

This executable uses a clever way of packing. It uses a well-known packer called UPX which is detected by most automated sandboxes and packer identifiers like PEiDand ProtectorID.

So, we start by unpacking the UPX packer. As already known, UPX packers can be unpacked using the ESP + hardware breakpoint trick. So, let us unpack it using this method.

This is how the Original Entry Point of a UPX packed binary looks:

We step over the PUSHAD instruction which will save the contents of all the registers on the stack.

Once we step over PUSHAD, we will follow ESP in memory dump and set a Hardware Breakpoint at the WORD present at that memory location. The reason this is done is: once the unpacking completes, POPAD instruction will be executed that will restore the contents of registers.

As a result, this memory location will be accessed and modified. So, we set the hardware breakpoint as shown in the screenshot below:

Once we run the executable after setting the hardware breakpoint, we break at the following memory location:

Next, we set a breakpoint at 0x004170B4 to skip over the loop.

Once we step over this, we reach the Original Entry Point at 0x00402690.

In most cases, this is the unpacked executable and now you can start stepping through the code to understand the malware. So, let’s continue with that.

Identification of Unnecessary Code Sections

This is how our Original Entry Point at 0x00402690 looks like after unpacking UPX:

This looks good, so let’s continue.

After tracing the code further from OEP, we reach a CALL to the subroutine at address, 0x00401020.

In most cases, you would reach the code corresponding to malware after this. So, let’s see:

This subroutine contains a lot of code which has been placed to deter reverse engineering. For instance, if you check the section of code below:

1
2
3
MOV DWORD PTR SS:[EBP-58],F47117C3
CMPDWORD PTR SS:[EBP-58],F8EC0A77
JNZSHORT Shipment.0040108F     ; this jump will always be taken

It moves a constant DWORD into a memory location, [EBP-58] and then compares it with another constant DWORD, followed by a check for whether they are unequal. Since they will always be unequal, the Jump will be taken.

Similar lines of code were observed in multiple places in the subroutine which were added only to increase the size of code that we have to go through while reversing.

Similarly, another section of code:

1
2
3
4
5
MOV DWORD PTR SS:[EBP-54],F498C7E5
MOV EDX,DWORD PTR SS:[EBP-54]
IMUL EDX,DWORD PTR SS:[EBP-54]
ADD EDX,DWORD PTR SS:[EBP-54]
MOV DWORD PTR SS:[EBP-54],EDX

It moves a constant DWORD into [EBP-54], and then moves it to EDX, multiplies with itself, and then adds it to the result and stores back in the memory address.

However, this value is not relevant to us for reversing.

Decryption of Custom Unpacking Subroutine

Proceeding in this way and skipping over sections of code that use code similar to above, we reach a CALL to VirtualAlloc with the stack parameters as shown below:

It allocates a new memory with a size of 0x1830 bytes.

It is important to note that, VirtualAlloc is a good way of locating the Original Entry Point of an executable. The reason being, while unpacking it’s common to see a CALL to VirtualAlloc which allocates a new memory region. Encrypted data is copied to this memory location and then decrypted.

If the data at this memory location is executed later on, then it means we have unpacked it or reached the original entry point (it’s possible that there is more code obfuscation later).

In our case, the call to VirtualAlloc() allocates a new memory region at base address, 0x00C50000

Tracing the code further we reach a CALL to subroutine at 0x004016F0 as shown below:

Tracing this subroutine further, we locate our first decryption routine:

The encrypted data is stored at memory address, 0x405028as shown below:

Here is a high level overview of the decryption subroutine:

  1. It reads one DWORD at a time from the encrypted data.
  2. It modifies the DWORD by passing it to a subroutine at 0x00401A80
  3. The DWORD modified above is passed to a second subroutine at 0x004014E0
  4. The final modified DWORD is written to the newly allocated memory region at 0x00C50000
  5. There is a counter which is used to keep track of the number of DWORDs read from the Encrypted Data section. A total of 0x12A DWORDs are read, modified and written to the newly allocated memory region.

Below is the code explanation with comments:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
MOV EDX,DWORD PTR SS:[EBP-C]; counter
MOV EAX,DWORD PTR DS:[EDX*4+405028]; read a DWORD from the encrypted data stored at 0x0405028
MOV DWORD PTR SS:[EBP-54],EAX
MOV ECX,DWORD PTR SS:[EBP-54]
PUSH ECX; pass the DWORD to the subroutine
CALL Shipment.00401A80  ; First DWORD modification routine
ADD ESP,4
MOV DWORD PTR SS:[EBP-54],EAX; modified DWORD is stored in [EBP-54]
MOV DWORD PTR SS:[EBP-58],0AB6C
LEA EDX,DWORD PTR SS:[EBP-58]
MOV DWORD PTR SS:[EBP-5C],EDX
MOV EAX,DWORD PTR SS:[EBP-58]
OR EAX,9E2F; OR 0AB6C with 9E2F
MOV ECX,DWORD PTR SS:[EBP-5C]
MOV EDX,DWORD PTR DS:[ECX]
AND EDX,DWORD PTR SS:[EBP-58]
IMUL EAX,EDX
ADD EAX,DWORD PTR SS:[EBP-58]
MOV DWORD PTR SS:[EBP-58],EAX
MOV EAX,DWORD PTR SS:[EBP-54]
PUSH EAX; pass the modified DWORD to the subroutine
CALL Shipment.004014E0
ADDESP,4
MOV ECX,DWORD PTR SS:[EBP-C]
MOV EDX,DWORD PTR SS:[EBP+8]
XOR EAX,DWORD PTR DS:[EDX+ECX*4]
MOV ECX,DWORD PTR SS:[EBP-C]
MOV EDX,DWORD PTR SS:[EBP+8]
MOV DWORD PTR DS:[EDX+ECX*4],EAX
MOV EAX,DWORD PTR SS:[EBP-C]; get the previous value of counter
ADD EAX,1; increment the counter
MOV DWORD PTR SS:[EBP-C],EAX
MOV ECX,DWORD PTR SS:[EBP-C]
CMP ECX,DWORD PTR SS:[EBP-1C]; check if counter <= 0x12A (total size of the data to be decrypted)
JB SHORT Shipment.004017F2
MOV DWORD PTR SS:[EBP-8],F4617F55
MOV EDX,DWORD PTR SS:[EBP-8]
IMUL EDX,DWORD PTR SS:[EBP-8]
MOV DWORD PTR SS:[EBP-20],EDX
MOV ESP,EBP
POP EBP
RETN

Here is the first DWORD modification routine:

Here is an explanation of the code with comments:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
PUSH EBP
MOV EBP,ESP
SUB ESP,14
ROL DWORD PTR SS:[EBP+8],6; the encrypted DWORD is rotated left by 6 positions
MOV DWORD PTR SS:[EBP-8],96
MOV DWORD PTR SS:[EBP-4],FFCE4D33
MOV EAX,DWORD PTR SS:[EBP-8]
CMP EAX,DWORD PTR SS:[EBP-4]
JNZ SHORT Shipment.00401AAC ; this jump will always take place
.....
MOV EAX,DWORD PTR SS:[EBP+8]; the encrypted DWORD is moved back in EAX
MOV ESP,EBP
POP EBP
RETN

The result of the first DWORD modification routine is passed to the second subroutine at: 0x004014E0

Here is the second DWORD modification routine:

Here is the code with comments:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
PUSH EBP
MOV EBP,ESP
SUB ESP,38
MOV DWORD PTR SS:[EBP-8],6375; this is the XOR key used to modify the DWORD
MOV DWORD PTR SS:[EBP-10],FBCA85D0
MOV EAX,DWORD PTR SS:[EBP-10]
AND EAX,7D; 0xFBCA85D0 AND 0x7D
MOV ECX,DWORD PTR SS:[EBP-10]
AND ECX,0D4; 0xFBCA85D0 AND 0x0D4
SUB EAX,ECX
IMUL EAX,DWORD PTR SS:[EBP-10]
MOV DWORD PTR SS:[EBP-10],EAX
MOV DWORD PTR SS:[EBP-18],6D
MOV EDX,DWORD PTR SS:[EBP-10]
IMUL EDX,DWORD PTR SS:[EBP-18]
ADD EDX,DWORD PTR SS:[EBP-18]
MOV DWORD PTR SS:[EBP-18],EDX
MOV EAX,DWORD PTR SS:[EBP+8]; value of the first modified DWORD
XOR EAX,DWORDPTR SS:[EBP-8]; XOR the first modified DWORD with 0x6375
MOV DWORD PTR SS:[EBP+8],EAX; store it back in memory
MOV DWORD PTR SS:[EBP-4],5

After returning from the second subroutine, it will write this modified DWORD in the newly allocated memory region:

Here is an explanation of the code with comments:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
ADD ESP,4
MOV ECX,DWORD PTR SS:[EBP-C]
MOV EDX,DWORD PTR SS:[EBP+8]
XOR EAX,DWORDPTRDS:[EDX+ECX*4]
MOV ECX,DWORD PTR SS:[EBP-C]
MOV EDX,DWORD PTR SS:[EBP+8]
MOV DWORDPTRDS:[EDX+ECX*4],EAX
MOV EAX,DWORD PTR SS:[EBP-C]; get the previous value of counter
ADD EAX,1; increment the counter
MOV DWORD PTR SS:[EBP-C],EAX
MOV ECX,DWORD PTR SS:[EBP-C]
CMP ECX,DWORD PTR SS:[EBP-1C]; check if counter <= 0x12A (total size of the data to be decrypted)
JB SHORT Shipment.004017F2
MOV DWORD PTR SS:[EBP-8],F4617F55
MOV EDX,DWORD PTR SS:[EBP-8]
IMUL EDX,DWORD PTR SS:[EBP-8]
MOV DWORD PTR SS:[EBP-20],EDX
MOV ESP,EBP
POP EBP
RETN

Once the decryption has completed, we have the decrypted data present at 0x00C50000 as shown below:

Now, it calls the decrypted subroutine at 0x00C50000 as shown below:

Unpacking the Custom Packer – Stage 1

Once we step into this subroutine we are the first decrypted subroutine as shown below:

Here is an explanation of the code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
NOP
NOP
NOP
NOP
NOP
PUSH EBP
MOV EBP, ESP
SUB ESP,18
PUSH EBX
PUSH ESI
PUSH EDI
CALL00C50013
POP EBX
SUB EBX,13; EBX points to the start of decrypted subroutine, 00C50000
CALL 00C501FA; Get kernel32.dll base address and API addresses
OR EAX,EAX
JE 00C50143
CALL DWORDPTRDS:[EBX+491]; kernel32.GetProcessHeap
MOV DWORD PTR SS:[EBP-4],EAX
PUSH DWORD PTR SS:[EBP+10]; 0x5244
PUSH8
PUSH DWORD PTR SS:[EBP-4]; base address of the heap
CALL DWORDPTRDS:[EBX+495]; Allocate the heap
OR AX,EAX
JE 00C50143
MOV DWORD PTR SS:[EBP-18],EAX

We will step into the first subroutine at 0x00C501FA which is used to get the address of different APIs:

Here is explanation of the code with comments:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
PUSH EBP
MOV EBP, ESP
SUB ESP,4
CALL00C502BF; Get base address of kernel32.dll
MOV DWORD PTR SS:[EBP-4],EAX
PUSH EAX; Base address of kernel32.dll
CALL00C5030E; Get address of GetProcAddress
MOV DWORDPTRDS:[EBX+48D],EAX; Store this address in memory
LEA EAX,DWORDPTRDS:[EBX+426]; Pointer to LoadLibrary
PUSH EAX
PUSH DWORD PTR SS:[EBP-4]
CALL DWORDPTRDS:[EBX+48D]; Get Address of LoadLibrary
MOV DWORDPTRDS:[EBX+489],EAX
LEA EAX,DWORDPTRDS:[EBX+442]; Pointer to HeapAlloc in the image
PUSH EAX
PUSH DWORD PTR SS:[EBP-4]
CALL DWORDPTRDS:[EBX+48D]; GetAddress of HeapAlloc
....
MOV DWORDPTRDS:[EBX+491],EAX
MOV EAX,1
JMP SHORT00C502BD
XOR EAX,EAX
LEAVE
RETN

It uses the subroutine at 0x00C502BF to get the base address of kernel32.dll by parsing the PEB structure. This is a common method used by shellcodes and various malwares to dynamically find the base address of kernel32.dll:

The next subroutine at address, 00C5030Eis used to get the address of GetProcAddress API which will later be used to get the address of different APIs.

It proceeds to find the address of different APIs using GetProcAddress as shown below:

All these function pointers are stored in memory, as shown below:

Now that it has retrieved the pointers to some APIs, it starts with another decryption routine.

The code of malicious executable is located at memory address, 0x004054D0

First, let’s take a look at this encrypted data:

If you look at this encrypted data, you will observe a pattern. After every DWORD, we have the WORDs 0x0050 or 0x0051 corresponding to ASCII values P. or Q.respectively.

Now, let’s check the decryption routine. It is mentioned below with comments:

1
2
3
4
5
6
7
8
9
10
MOV ESI,DWORD PTR SS:[EBP+C]; points to encrypted data (0x004054d0)
MOV EDI,DWORD PTR SS:[EBP-18]; points to the newly allocated heap
MOV ECX,DWORD PTR SS:[EBP+10]; size of the encrypted data
ADD ESI,2; skip the WORDs 0x0050 or 0x0051
LODS DWORDPTRDS:[ESI]; read the encrypted DWORD into EAx
ROL EAX,6; rotate left by 6
XOR EAX,DWORD PTR SS:[EBP+14]; XOR with 0x278C
STOS DWORDPTRES:[EDI]; store the result in destination
SUB ECX,6; decrement counter by 6 (4 for the DWORD and 2 to skip over the WORDs, 0x0050 or 0x0051)
JNZ SHORT00C5004

This subroutine is easy to understand. It reads a DWORD from the encrypted data, rotates it left by 6 bit positions and XORs it with the XOR key 0x278C.

The resulting data is stored at the newly allocated heap at address, 0x0018F520:

As can be seen in the screenshot above, it is the MZ header of the malicious executable. However, it is not completely decrypted.

Unpacking the Custom Packer – Stage 2

Once the first decryption routine has completed, it proceeds to allocate a new heap, which will be used to store the final decrypted malicious executable:

1
2
3
4
5
6
7
8
9
10
PUSH DWORD PTR SS:[EBP+18]; 0x8C00
PUSH 8
PUSH DWORD PTR SS:[EBP-4]
CALL DWORDPTRDS:[EBX+495]; Allocate a new Heap
OR EAX,EAX
JE 00C50143
MOV DWORD PTR SS:[EBP-14],EAX
PUSH DWORD PTR SS:[EBP-14]; pointer to newly allocated heap
PUSH DWORD PTR SS:[EBP-18]; pointer to first stage of decrypted data
CALL 00C5036E; second decryption routine

Let’s check the second decryption routine at address, 0x00C5036E:

Here is an explanation of the code with comments:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
PUSHAD
MOV ESI,DWORD PTR SS:[ESP+24]; source points to first stage of decryption
MOV EDI,DWORD PTR SS:[ESP+28]; points to newly allocated heap
CLD
MOV DL,80
XOR EBX,EBX
MOVS BYTEPTRES:[EDI],BYTEPTRDS:[ESI]; move one byte from source to destination
MOV BL,2
CALL 00C503F1
JNB SHORT00C5037C
XOR ECX,ECX
CALL 00C503F1
JNB SHORT00C503AB
XOR EAX,EAX
CALL00C503F1
JNB SHORT00C503BB
MOV BL,2
INC ECX
MOV AL,10
CALL00C503F1
ADC AL,AL
JNB SHORT00C5039D
JNZ SHORT00C503E7
STOS BYTEPTRES:[EDI]
JMP SHORT00C5037F
CALL00C503FD
SUB ECX,EBX
JNZ SHORT00C503C4
CALL00C503FB
JMP SHORT00C503E3
LODS BYTEPTRDS:[ESI]; move the byte from source into EAX
SHR EAX,1; shift right the value in EAX by one position
JE SHORT00C5040D exit the decryption routine ifthis value inEAX is 0
ADC ECX,ECX
JMP SHORT00C503E0
XCHG EAX,ECX

After this subroutine has completed, we will have the decrypted malicious executable at address, 0x00194780

This decrypted malicious executable is located at the address, 0x00194780

Self-Modification of Main Image Header

It is followed by a call to VirtualProtect to modify the protection of the first 0xC000bytes at 0x400000 (ImageBaseAddress) to 0x40 which corresponds to PAGE_EXECUTE_READWRITE as shown below:

The stack parameters are:

Now it sets the first 0xC000 bytes at the ImageBaseAddress to null bytes (0x00). This is done because it will be overwritten with the contents of the decrypted malicious executable.

1
2
3
4
XOR AL,AL; AL stores the nullbyte
MOV EDI,DWORD PTR SS:[EBP+8]; EDI points to the ImageBaseAddress, 0x400000
MOV ECX,DWORD PTR SS:[EBP-8]; 0xC000
REP STOS BYTE PTR ES:[EDI]; repeatedly store 0xC000 null bytes at 0x400000

After this, it will copy the sections of the decrypted executable to the ImageBaseAddress one by one (PE header, .text, .rsrc, .reloc and so on):

1
2
PUSH DWORD PTR SS:[EBP-14]; pointer to new decrypted image
CALL 00C5016F

Using the below Subroutine, it will get the SizeOfHeaders of the decrypted executable.

1
2
3
4
5
6
7
8
PUSH EBP
MOV EBP, ESP
MOV EAX,DWORD PTR SS:[EBP+8]
MOV EAX,DWORDPTRDS:[EAX+3C]
ADD EAX,DWORD PTR SS:[EBP+8]; pointer to PE header of new decrypted image
MOV EAX,DWORDPTRDS:[EAX+54]; SizeOfHeaders, 0x400
LEAVE
RETN4

It then proceeds to copy the PE header from the decrypted executable to the ImageBaseAddress:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
PUSH EAX; 0x400
PUSH DWORD PTR SS:[EBP-14]; pointer to decrypted image
PUSH DWORD PTR SS:[EBP+8]; pointer to base address of image of main module
CALL 00C50157
PUSH EBP
MOV EBP, ESP
PUSH ECX
PUSH ESI
PUSH EDI
MOV ECX,DWORD PTR SS:[EBP+10]
MOV EDI,DWORD PTR SS:[EBP+8]
MOV ESI,DWORD PTR SS:[EBP+C]
REP MOVS BYTE PTR ES:[EDI],BYTE PTR DS:[ESI]; copy 0x400 bytes from decrypted executable to Image Base Address
POP EDI
POP ESI
POP ECX
LEAVE
RETN0C

It proceeds in this way to copy the .text, .rsrc and .reloc sections one by one to the Image Base Address:

  1. Copy 0x8400 bytes of .text section from the decrypted image to 0x401000
  2. Copy 0x200 bytes of .rsrc section from the decrypted image to 0x40A000
  3. copy 0x200 bytes of .reloc section from the decrypted image to 0x40B000

Decrypted Malicious Executable

It then calls the AddressOfEntryPoint of the malicious executable:

1
2
3
4
MOV EAX,DWORD PTR SS:[EBP-10]; pointer to PE header
MOV EAX,DWORDPTRDS:[EAX+28]; address of entry point
ADD EAX,DWORD PTR SS:[EBP+8]
CALL EAX; 0x408D60

Let’s now trace the code inside the malicious executable:

This section of code will first retrieve the addresses of following APIs:

NtQueryInformationProcess

ZwReadVirtualMemory

ZwMapViewofSection

NtCreateSection

ZwResumeThread

It then proceeds to create a new process called svchost.exe in Suspended State (Process Creation Flag is set to 0x4):

Stack parameters:

Code Injection into New Process

This virus uses an interesting way to inject the malicious code in the newly created process and later resume the execution of it. Unlike most malwares which make use of WriteProcessMemory() to inject the code in the Process Address Space of a remote process, it does not call WriteProcessMemory() at all.

It also helps in bypassing certain security mechanisms where system drivers detect the code injection by monitoring WriteProcessMemory API invocations in user mode.

Once the new process is created, it queries the remote process to retrieve Process Information by calling ZwQueryInformationProcess API as shown below:

The stack parameters are:

The output will be stored at the memory address 0x0012FD9C. It uses this to get the Process Environment Block address of the remote process as shown below:

In this case, PEB of svchost.exe is at the address, 0x7FFDA000

It then proceeds to find the ImageBaseAddress of svchost.exe by reading the value at offset 0x8 in PEB

1
2
3
4
5
6
7
8
9
10
11
12
13
14
MOV DWORD PTR SS:[EBP-AC],EAX
MOV EDX,DWORD PTR SS:[EBP-14]; pointer to PEB base address of new process
ADD EDX,8; PEB + 8 has the ImageBaseAddress of svchost.exe
MOV DWORD PTR SS:[EBP-DC],EDX
LEA EAX,DWORD PTR SS:[EBP-9C]
PUSH EAX
PUSH 4
LEA ECX,DWORD PTR SS:[EBP-8C]
PUSH ECX
MOV EDX,DWORD PTR SS:[EBP-DC]
PUSH EDX
MOV EAX,DWORD PTR SS:[EBP-A8]
PUSH EAX
CALL DWORD PTR SS:[EBP-B4]; ZwReadVirtualMemory

Stack parameters:

It reads 0x4 bytes from the address 0x7FFDA008 in the process address space of the svchost.exe process and stores it at 0x0012FD28 as shown below:

The ImageBaseAddress of svchost.exe is 0x10000000

It then proceeds to create a new section within itself using ZwCreateSection API:

Stack parameters:

The handle of the new section is stored at the address 0x0012FD94:

After this, it calls ZwMapViewOfSection to map the newly created section (handle, 0x150) in itself.

Stack parameters:

The base address of the mapped view of Section is stored at 0x0012FD30:

The address of the mapped view of section is: 0x00A20000. The size of mapped view is 0x7CA0.

It then proceeds to copy 0x7CA0 bytes from 0x004010B0 to the mapped view at 0x00A20000:

1
2
3
4
5
6
7
8
9
10
11
12
13
MOV EDX,DWORD PTR SS:[EBP-7C]
ADD EDX,1
MOV DWORD PTR SS:[EBP-7C],EDX
MOV EAX,DWORD PTR SS:[EBP-7C]
CMP EAX,DWORD PTR SS:[EBP-2C]; check if counter <= 0x7CA0
JNBSHORT Shipment.00408F88
MOV ECX,Shipment.004010B0
ADD ECX,DWORD PTR SS:[EBP-7C]
MOV EDX,DWORD PTR SS:[EBP-84]
ADD EDX,DWORD PTR SS:[EBP-7C]
MOV AL,BYTEPTRDS:[ECX]; read one byte at a time from 0x004010B0
MOV BYTEPTRDS:[EDX],AL; store it in the view
JMP SHORT Shipment.00408F60

Once this is done, the mapped view contains the code of malicious subroutine:

It uses another call to ZwMapViewofSection to map its section (that has the code of malicious subroutine) into svchost.exe process:

Stack parameters:

Here, 0x150 is the handle of the section object and 0x154 is the handle of svchost.exe process.

The base address of the newly mapped view will be present at 0x0012FD30:

Our malicious subroutine has been mapped at the address 0x000C0000 in svchost.exe process address space.

In this way, even without using a call to WriteProcessMemory it was able to inject the code of malicious subroutine in process address space of svchost.exe.

It then calls VirtualAlloc to allocate memory in its own Process Address Space:

Stack parameters:

The new memory region is allocated at address, 0x00C60000

Modification of Original Entry Point in Remote Process

It proceeds with a call to ZwReadVirtualMemory to read the PE Header of svchost.exe process and store it at the newly allocated memory region, 0x00C60000

Stack parameters:

Once it has the PE Header of svchost.exe at address, 0x00C60000, it parses that to find the size of Image of svchost.exe process:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
MOV DWORD PTR SS:[EBP-AC],EAX
MOV ECX,DWORD PTR SS:[EBP-80]
MOV EDX,DWORD PTR SS:[EBP-80]
ADD EDX,DWORDPTRDS:[ECX+3C]; EDX points to PE Header of svchost.exe
MOV DWORD PTR SS:[EBP-88],EDX
MOV EAX,DWORD PTR SS:[EBP-88]
MOV ECX,DWORDPTRDS:[EAX+50]; At offset 0x50 in the PE Header we have the SizeOfImage.
MOV DWORD PTR SS:[EBP-30],ECX
MOV EDX,DWORD PTR SS:[EBP-88]
MOV EAX,DWORDPTRDS:[EDX+28]; AddressOfEntry point of svchost.exe
MOV DWORD PTR SS:[EBP-B8],EAX
LEA ECX,DWORD PTR SS:[EBP-9C]
PUSH ECX
MOV EDX,DWORD PTR SS:[EBP-30]
PUSH EDX
MOV EAX,DWORD PTR SS:[EBP-80]
PUSH EAX
MOV ECX,DWORD PTR SS:[EBP-8C]
PUSH ECX
MOV EDX,DWORD PTR SS:[EBP-A8]
PUSH EDX
CALL DWORD PTR SS:[EBP-B4];ntdll.ZwReadVirtualMemory

Stack parameters:

It reads 0x6000 bytes (SizeOfImage of svchost.exe) from the ImageBaseAddress of svchost.exe and stores at 0x00C60000 in its Process Address Space.

The original entry point was located previously and stored in [EBP-88]. The RVA of AddressOfEntryPoint of svchost.exe is 0x2509.

Let’s look at the disassembly of the code at Original Entry Point in svchost.exe at present:

It is important to note here. Most malwares in the recent past used GetThreadContext() and SetThreadContext() to modify the Original Entry Point of the Primary Thread which will be executed in the remote process to trigger the malicious code execution. In this case, it does not use calls to GetThreadContext()and SetThreadContext() APIs to modify the Original Entry Point at all.

It then proceeds to modify the code at original entry point using the code below:

Here is the explanation of the code with comments:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
MOV DWORD PTR SS:[EBP-AC],EAX
MOV ECX,DWORD PTR SS:[EBP-80]
ADD ECX,DWORD PTR SS:[EBP-B8]; Original Entry Point of svchost.exe
MOV BYTE PTR DS:[ECX],90; opcode of NOP
MOV EDX,DWORD PTR SS:[EBP-80]
ADD EDX,DWORD PTR SS:[EBP-B8]
MOV BYTE PTR DS:[EDX+1],68; opcode of PUSH Memory Address
MOV EAX,DWORD PTR SS:[EBP-80]
ADD EAX,DWORD PTR SS:[EBP-B8]
MOV ECX,DWORD PTR SS:[EBP-28]
MOV DWORDPTRDS:[EAX+2],ECX; pointer to code of subroutine which was already mapped into new process
MOV EDX,DWORD PTR SS:[EBP-80]
ADD EDX,DWORD PTR SS:[EBP-B8]
MOV BYTE PTR DS:[EDX+6],0C3; opcode of RET
MOV DWORD PTR SS:[EBP-7C],0
JMP SHORT Shipment.00409131

After modification, the disassembly of the code at the Original Entry Point looks like shown below:

As can be seen, the OEP is modified so that it jumps to the subroutine at address 0x0C0000 and executes it. 0xC0000 is the location at which the malicious subroutine was injected previously in svchost.exe process.

It then makes another call to ZwCreateSection to create a new section within itself with the section handle, 0xEC.

Then it calls ZwMapViewOfSection and maps this newly created section at the address, 0x00A30000.

Once this is done, it will copy the bytes from the previously modified PE header of svchost.exe to this location.

It then calls ZwMapViewOfSection once again to map the bytes at 0x00A30000 to the ImageBaseAddress of svchost.exe process as shown below:

Stack parameters:

Now, the modified PE header has been written to the process address space of svchost.exe

It then calls ZwResumeThread to resume the execution of primary thread in svchost.exe.

This Primary Thread executes from the Original Entry Point of svchost.exe. Since that was modified previously to redirect the execution to malicious injected subroutine, it proceeds to successfully execute the malicious code within the context of svchost.exe

Debugging the Remote Process

Once it calls ZwResumeThread the execution of malicious subroutine is resumed in the context of svchost.exe process. To be able to debug it we need to modify the Original Entry Point before the code is injected in svchost.exe process.

This is how the code can be patched.

Please note that the memory addresses in the steps below may differ from the analysis done before because this was a new debugging session. The algorithm remains the same.

  1. It calls VirtualAlloc()to allocate a new memory region at 0x00C90000
  2. It calls ZwReadVirtualMemory to read 0x1000 bytes from the svchost.exe process into the newly allocated memory region.
  3. It then calls ZwReadVirtualMemory again to read SizeOfImage (0x6000) bytes from svchost.exe process into the newly allocated memory region at 0x00C90000.
  4. It then creates a new section within itself by calling ZwCreateSection.
  5. It maps the view of the newly created section by calling ZwMapViewOfSection which is mapped at the base address 0x01190000.
  6. It then proceeds to modify the Original Entry Point in the newly allocated memory region.
  7. After this, it copies 0x6000 bytes from the newly allocated memory region at 0x00C90000 to the mapped view at 0x01190000
  8. We need to patch the bytes in the mapped view which will be mapped to the Original Entry Point in remote process. In our case, it will be the bytes at 0x01192509.

    At present we have at address, 0x01192509

    1
    2
    3
    01192509 90         NOP
    0119250A 68 00000C00     PUSH 0C0000
    0119250F C3         RETN

    We will patch with EB FE which is a short relative cyclic jump as shown below:

  9. It again calls ZwMapViewOfSection to map the section object to the remote process.
  10. It then resumes the thread in remote process by calling ZwResumeThread.The original entry point in remote process will be 0x01002509. Since we patched the bytes before, the code execution will pause at the Original Entry Point.

    We will now be able to attach our Debugger to svchost.exe process. Let us now patch the bytes at the Original Entry Point in remote process and restore them:

    After patching, we set a breakpoint at the OEP and run, so that we break at the OEP:

    Now we can proceed with debugging the malicious subroutine in svchost.exe process.

Conclusion

After reading this article you should be able to unpack malwares which use a similar technique to pack their code and prevent debugging.

It also allows us to see the new ways in which malware authors are trying to bypass the AV and prevent analysis of malwares.

Original Post: http://resources.infosecinstitute.com/deep-dive-into-a-custom-malware-packer/

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Up ↑