This post will explain how to reverse engineer Trickbot malware. This sample is packed using a commodity packer. Packing is a common technique used by malware authors to make analysis more difficult to analyze malware. We will use pestudio for initial analysis, DetectItEasy, PE Bear, HxD and x64dbg.
Tools
PEStudio, x64dbg, PE Bear, CFF Explorer, HXD
Disclaimer
You are dealing with a real malware sample. Run and Analyze it in a controlled environment (sandbox) with no connections to the internal network or internet. I am not responsible for any consequences or damages you may incur while handling this sample.
Static Analysis:
Hash
MD5: 96985dff8be2912fe2d02752b5d4a073
Using pestudio, CFF explorer or Process Hacker, check to see if ASLR is enabled and disabled ASLR with CFF Explorer (Dll can move, Image is NX Compatible). Since hybrid analysis loads the same malware (process injection maybe?) set breakpoints on CreateProcessInternalW, WriteProcessMemory and ResumeThread. This is to see if the malware creates a process, and writing the unpacked binary to the process. Resume thread is just incase they dont use WriteProcessMemory
Run the malware (F9) and we hit the entry point, run the malware again and hit the first breakpoint CreateProcessInternalW where a new process is created. Run the malware again and we hit the next breakpoint WriteProcessMemory.
To look at the stack window for the arguments passed on the WriteProcessMemory function, we look at it's MSDN page. The first argument is the handle to the process they are writing to, the 2nd is the base address of the process and the 3rd argument is a pointer to the buffer where the data is contained (see below).
We follow the 3rd agrument in dump (follow DWORD in dump).
Luckily for us on the first try, we get a PE file on the dump section. This first stage of unpacking is pretty straight foward since we found the buffer that contains the unpacked payload in memory.
Next, othe dump section, right click, chose follow in memory map, then right click again in the Memory map section and chose dump memory to file option to dump the file to desktop as stage2.bin.
Open the file in a Hex Editor (HXD) and remove/delete the extra data that was in the buffer and have your File start with the MZ (4d 5a) header.
Next open stage2 file in PE bear to see if we need to unpack it further. We see that the curved out PE file has no imports but has 2 sections only (text which is big & rsrc which is small) which indicates it a packed file vice the payload.
Load the file in x32/x64 dbg to try to unpack it. Since we dont know if it is self or remote process injections, we set breakpoints to API's for both techniques which are VirtualAlloc (specifically the return to VirtualAlloc), VirtualProtect, CreateProcessInternalW, WriteProcessMemory and ResumeThread. FYI- Once on VirtualAlloc and want to get to ret to VurtualAlloc, navigate through the jmp statements by using use the "enter" key to follow jmp and call statements. You can also use the "-" and "+" keys to navigate forward and backward between addresses. For example if you have pressed "enter" and jumped to the new address you can simply press "-" to jump back. The return has the base address where the memory has been allocated. When we hit this return, EAX will have the address of the new memory segment thats been allocated.
Run the malware (F9) and hit the entry point breakpoint (BP) first. Continue running the malware and you'll see that it hits the next BP CreateProcessInternalW. Looking at the stack window, we see that it creates a file in the AppData Roaming disk check folder. Continuing to run the malware, Debugging stops and crashes. Maybe the malware knows it's not running in the temp directory as a means of hiding itself. We reaload the binary in the temp/AppData Roaming Disk check section as it's the same malware and reset all our breakspoints and run the binary again.
This time we hit the entry point BP, then the return to VirtualAlloc BP. Since EAX is zero'd out (00000) we dont see the newly allocated address hence we step back (debug > step back or f7) from it and run (f9) it again. Make sure the EAX address that is available is not reserved but allocated by confirming this in the Memory Map section which is explicit if it is ot not. If it is, run (f9) the binary again and hit the ret to VirtuaAlloc BP (2nd call to VirtualAlloc), the new EAX address can be dumped (follow in dump) if it is not reseved.
Run (f9) the binary again and you'll see portions of what appears to be a PE (this program cannot be run in dos mode..., rsrc, text sections) in the dump section. This is as a result of self injection (virtualAlloc).
Next right click the dump section and chose follow in memory map. The right click and chose Memory Breakpoint, Execute, Singleshoot (f2) options to set a breakpoint on execute. Run until hit that breakpoint and not worry about writing a PE file but executing it. Dont forget to diable all other breakpoints.
Run the binary and once it executes, you get a PE (MZ header is dump section). Ricght Click on this section, chose follow in memory map then dump memory to file as stage3 remembering to keep the memory address on the stage3 name incase we have to rebase as its helpful. Check the dumped bin file in PE bear to unmap it as its in its mapped format. Copy the ViruallAdresses to the Raw addresses as well as the VirtualSize to the raw size so everything matches.
Next fix the imagebase to match the memory address on the stage3 file. This is located under optional header. Save the PE as stage3.exe. Open the PE in resource hacker and one of the two big files is the configuration file which contains the IOC's.
IOC's can be retrieved by dumping out the resource section as a .bin file and using TrickBot.py script from github. Python TrickBot.py xxx.bin
Conclusion
Shout out to @OALabs (Open Analysis Live), @cybercdh, and MalwareAnalysisForHedgehogs for inspiring in this writeup.
Comments
Post a Comment