Malware Journey Day 4

Yesterday I learned that the PE file is what allows the operating system to understand how to run the executable. Now it is time to go back to packed malware. Packers are just ways to obfuscate or compress an executable. From looking at PEbear yesterday I learned that looking at signatures could possibly help me if the pattern recognized a packer. Also looking at strings or even the amount of imports can be a good indicator. Finally looking at the entropy could show if the data is encrypted. With that out of the way, its time to dynamically unpack some samples.

Big thanks to zero2auto for the amazing walkthroughs

Looking at Dridex, I first opened it up in PEStudio.

I see it is possibly attempting to reach out to another server(This is a guess)

I did also did an analysis through PEStudio by looking the libraries and other sections. Im beginning to realise PEStudio is great just for pre analysis.

Jumping to x32dbg I set 3 breakpoints. VirtualAlloc,VirtualProtect,CreateProcessInternal. Malware would use VirtualProtect to modify memory protections. So setting a breakpoint there would be a good idea. VirtualAlloc would be used for malware in the case it needed to inject something into the process.

When first running the program I will hit my breakpoint VirtualAlloc. I would want to get to the end of the function and dump EAX. Initally it will show as all 00’s. But running my program once more will fill the dump with values.

Above I can regonize this is the beginning of a PEHeader. More specifically I am looking at the MS DOS header. Looking through the dump I can find the beginning of an unmapped executable in memory from my first dump. Then my mapped version when my sample did go through memory in dump 2. Overall what VirtualAlloc did was essentially just map this executable into memory.

On my 3rd run I ran into VirtualProtect. VirtualProtect from what I explained before is modifying the memory.

The below sample was before virtualProtect

When I hit virtualProtect

This looks quite different.

After Resuming execution from VirtualProtect, I see the unpacked payload below

A next good step since I reached the payload is looking at it through process hacker. Since this memory is located at 10062b0, I would match that in process hacker.

After dumping this section of memory I open it in PE Bear.

As expected the imports from this are all unresolved since I dumped it from memory.

My next steps are to unmap this section, which means changing the section headers.

After changing my section sizes I still find plently of empty space, which means I can increase the size of reloc.

Now that the section headers are resolved, my libaries and the function names are resolved

The purpose of all of this was correcting offsets since we dumped this from memory. At this point it is unmapped.

I want to do another sample for extra practice which will be seen below.

My first step will be a glance at pestudio. Seeing it at a high entropy tells me that it is possibly packed.

When running this sample through x32dbg, I found that after setting the breakpoints I used on dridex, it seemed that the program either finishing running or an antidebug got caught.

I added an additional breakpoint for IsDebuggerPresent. To no suprise it got caught after running

The next step is to run till NtResumeThread, which is used for injection techniques by the malware author. Best practice to analyze this is to create another attachment in x32dbg

When looking at the 2nd x32dbg sample and reaching the VirtualAlloc function, I regonize a possible shellcode

Best next process would be to follow and dump it through register EAX. The below looks to be obfuscated shellcode. Possibly a second run would show something different

After finding that unmapped hex is showing UPX in the ASCII, we can move forward to the next steps. All that was done was running through VirtualAlloc and mapping the returned value. Next is looking at the address and again matching it to processhacker. After getting the packed file placed it in CFF Explorer will give details on as well as unpack the file. Then again, we can also place it in PEStudio as a final check to verify it is unpacked.

The above sample gave me issues. Maybe the next sample can clarify several questions.