Malware Journey Day 2

3 min readDec 9, 2023

I still need a lot of handholding for analyzing malware. Ive learned so far that based on the .NET malware analyzed yesterday looking for reoccurring patterns is critical. I also found it interesting how the malware picked up on it being analyzed in a VM and didn't send out any data which we would've spot through wireshark.

Thanks to OALabs, I was able to further analyze PandaBanker sample.

When analyzing PandaBanker for the first time, it was interesting there were no functions at all. I later found out a packed sample can hide the functions of the executable. Another way of finding packed samples is obfuscated strings.

Through x32dbg analyzed the instructions after push EAX seemed to be useful in investigating what each function was doing. This is because at the end of each function, EAX is generally returned.

Getting into x32dbg

I created a breakpoint at CreateFileW to see if the malware is attempting to interact with any of my files/programs on my system.

I am seeing this, after some research I am still clueless about what exactly this .bat file is doing.

I also saw AppData\Roaming appear frequently in my debugging process. I decided to delete everything in that folder to see if anything will be created. Nothing did which is interesting since its showing up in the API function CreateFileW. Im still unsure why this is happening.

Other interesting stopping points I ran into throughout my analysis was not hitting proper breakpoints. Examples can be WriteProcessMemory. This will allow the malware to write to a target process, I was trying to find where it was writing to but had 0 progress.

Due to me struggling I attempted to look at another source to unpack the PE file.

I am skipping over x32dbg and going straight to PEBear to unpack my sample. What is so great about this tool is analyzing section headers which shows attributes with the overall goal of it deobfuscating each of the functions.

A section table looks like this

My understanding of this comes mostly from exploit development. The Raw Address is just an offset to the data in that section. Virtual Address is the location in memory the section is at.

Due to my dump, currently, the addresses are not aligned up since I didn't dump from memory. Doing this through x32dbg is simple bu simply placing a breakpoint at NtAllocateVirutalMemory. These are my arguments and I want the Baseaddress which is where memory will sit/allocated. That is the 2nd arg.