Malware Journey Day 18

Recently learned items to unpacking a file automatically is

malwoverview.py -b 1 -B HASH -o 0 

Following the link

I am going to try this approach to a self injecting process. From what I know there are 4 types of injections for malware.

PE injection

Process Hollowing

Thread Execution Hijacking

Dll hijacking

For self injection it is overwriting the PE file which was already initially malicious. All the sample does is unpack itself and allocate memory for itself via VirtualAlloc, this is for the shellcode. This could also be unpacking the dll and load it via LoadLibraryA. Most common is a write into a section of the PE file and change the protections.

So PE overwriting aka UPX.

Thanks to OALabs for a good analysis of the Redaman malware.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Into the analysis of Redaman,

Appears I am not so lucky from the start. No samples found with the hash found in PEStudio.

From this screenshot alone I see multiple indicators of using WINAPI’s for process injection

Due to there being no signature, it is a good assumption this executable is packed.

From this above picture I can also confirm it is packed since ondisk address is different to in memory addresses.

Due to this process being self injecting, it is good to monitor the virtualAlloc functions.

I reached my first VirtualAlloc function in x32dbg

Hitting NtAllocateVirtualMemory I see it is writing to itself, this is what is expected of PE overwriting.

Looking at the baseaddr it is pointing to itself(FFFFFFFF)

Reaching the end of VirtualAlloc I dump the EAX since that is what will get dumped when returned

When running the program until I hit the next VirtualAlloc I see this

This appears to be my shellcode, but not the executable itself since there is no sections.

Due to there being shellcode, I am setting a breakpoint at VirtualProtect. This is because VirtualProtect will allow the Shellcode to run by changing the protections.

When continuing to run I want to file the MZ header

This looks werid to be an mz header. I do see the MZ prefix, but seems to have lots of content missing in the 64 bytes. Also I see sections so Im unsure to be doubtful currently.

After restarting the program and retracing my steps, this image looks more appropriate.

This memory section belongs here

I dumped this and looked through PEStudio and HxD tells me I dumped this in an unmapped format. The below image tells me this looks like a legit exe file.

Whats more interesting is I can see that VirtualProtect is changing the protections of the section where the PE header is. This is 400000

This is a clear PE Overwrite. To prove this, the below image is right after the return of VirtualProtect. Dumping this to memory map

I get this. Here we have a memory section for the dumped address

Moving onto IDA

This above image from Ida shows very clearly this sample is being packed.

Here I also see LoadLibraryA, which is a common function used for dll injections.

This above image looks like it is loading a function RtlDecompressBuffer from ndll. This is unzipping something. No idea what. hahaha

Anyways, since I know LoadlibraryA is being called, lets set a BP in x32dbg and find the path to the unmapped exe

Yay, I unpacked it