Unpacking fudPE – A new crypter
fudPE is not your ordinary malware packer. Unlike the malware we normally analyze on this blog, fudPE did not originate from the private criminal youtube-exploit-kit-distributing malwarehole dubbed “HackForums”. fudPE only appeared on HF after having established a presence on other underground forums such as exploit.in. Today we will analyze a payload packed with fudPE that’s found thanks to Malware Traffic Analysis.
Filetype: Portable Executable 32
VirusTotal scan: https://www.virustotal.com/en/file/261e2d1eab2af48a416252416a1a1d529fc48d939e09fd7d43609505ee1336ec/analysis/1500568298/
First we will discuss how to recognize a fudPE sample with both static and dynamic analysis. Statically, we could see that ALL fudPE crypted executables are wrapped with Nullsoft.
We then proceed to dynamic analysis and execute the file in a controlled environment (aka a sandbox or a VM). After running and immediately suspending the file, we could see that a DLL is dropped with a random name and loaded (in this case parrels.dll is the name)
The process then hollow another copy of itself to execute the payload and then exit. That is pretty much the basic way of identifying a fudPE packed payload. Let us proceed to the unpacking process. In order to unpack, we open the file up in OllyDbg.
Searching for intermodular calls, we could see a call to CreateProcessA. Keep in mind that this is a part of Nullsoft’s stub, not a part of the actual fudPE code. However we use it as a pivoting point to get to the real code.
Pressing enter after selecting the call, we get into the CreateProcessA function. Here, we set a breakpoint in order to intercept fudPE’s process creation.
We let the file run until the breakpoint is hit. As we can see from the stack, the CREATE_SUSPENDED flag is used, which pretty much indicates that this is a runPE/Process Hollowing attempt.
We step out of the call and into the real malicious code. As we can see, we are in the parrels module.
We could see from the call located at 003E250D that GetProcAddress is used in order to resolve API names. We then step into the call like we did with CreateProcessA and set a breakpoint.
We let the file run and check the stack everytime the breakpoint was hit until we see the API WriteProcessMemory or NtWriteVirtualMemory (in the case of fudPE it is the first) being resolved.
We step over until we hit the RET instruction. The address of WriteProcessMemory is now in EAX, and we can follow it in the dissasembler by right clicking the value of EAX and selecting “Follow in Dissasembler” and set a breakpoint inside the function just like we did GetProcAddress and CreateProcessA. We let the executable run until the breakpoint is hit.
According to the MSDN page for WPM, the parameters for the function call are
lpBuffer is what we are looking for and is the third parameter, so we shall take a look at the third value in stack which is 00194C40. We right click, select “Follow in Dump” and got a very nice PE header. Just what we are looking for.
Next, we open Process Hacker up and double click the main process. We could easily see that the largest value in the memory tab that is less than the address above is 0x170000 (which also happens to be the Heap).
We expand 0x170000.
As we can see, 0x1a2000 is larger than the value we are looking for (0x194c40), so we right click 0x170000 and save it. We open the saved memory file up in HxD.
We then search for the location of the payload using the search feature.
Once found, we select all the bytes before MZ and remove them. Save the file and you have your original payload with some overlay data added.
We proceed to use ExeinfoPE to remove the overlay data.
And voila, we have the payload, which in this case is the Godzilla Loader. The fact that this is a Godzilla Loader sample tells a lot about the customer base of fudPE, since Godzilla is a very pricy loader @ around $600 per build and is not sold on HF. With this information we could safely assume that HF is a secondary marketplace for fudPE only while the main marketplaces are forums like exploit.in. A very dangerous threat indeed, however now with this information reverse engineering binaries protected by fudPE will prove to be easier for our dear readers.
A small side note:
I would like to remind our readers (and Armada) that the term “unlike” when used like this shows that the later noun group (in this case “your .NET trashware”) is not what is being reverse engineered, but rather the prior noun group (in this case “some proper malware”), which renders Armada’s response invalid.
Edit: Right after the posting of this article, the cybercriminal forums HackForums went down for maintainence. Coincidence? I think not.