Usually, malware comes packed by some packer which obfuscates the original code and helps it to evade AV software or general human suspicion. When executed the packed binary inject actual binary in the memory and runs it from there.
What we will cover in this write-up?
- Approach for setting break-point in packed binary to stop it in midst of injecting the malicious code and executing it.
- Bypassing malware’s “debugger bypass tricks”
- Locate and dump injected code from the memory.
- Do necessary patching.
Setup Environment :
Operating_System : Windows 10, Enterprise Evaluation 180914 Software_Arsenal : x32debugger, PE bear, Hexadecimal Editor HxD Malware_Binary : Remcos
What is Remcos RAT?
Here you go, blog.malwarebytes.com
Want to follow up with the article?
Here’s your malware, handle with care and caution. Malshare RemCos Download Link
Lab setup and Initial Inspection
We will be using our Windows 10 Virtual Machine. We have set networking to “HOST ONLY” to transfer the binary to VM via Python’s SimpleHTTPServer.
Now we have our binary, before starting we will shut down network and folder sharing in VM to prevent chaos if things goes sideways.
Let’s rename our binary to RemCOS.bin and start investigation with PE Bear.
The binary seems to be a VB6 packer. Lets fire up x32debugger and load our binary in it.
Setting Break-point at CreateProcessInternalW
What’s CreateProcessInternalW
This API call allows the program to spawn a new process from itself, usually packers use this method to inject actual malware code in memory and execute them using CreateProcessInternalW.
Without more delay let’s create a breakpoint here. Type:
bp CreateProcessInternalW
In cmd. section and press enter.
Bypassing Debugger Detection
As we continue to execute the binary, we stumble upon one interesting Exception. This can be an anti-debugger tactics or just some random exception from one of VB6 APIs. Anyways this is blocking us from hitting our intended break-point.
To bypass this, do Debug > Advanced > Run (pass exceptions)
This will pass all the exceptions to program as it would do in normal execution. Now we can hit out break-point :
Finding and Dumping Injected Code
We now know that it’s trying to run something from memory, we need to find what is it.
For that goto Memory Map. As we know that most of Portable Executable File (PE File) has a DOS header which says something like “This program cannot be run in DOS mode” or something like that. We can try to search for this string in our memory map, and let’s see what we get.
After the search we found following hits:
Now we need to find our injected code, but here’s a hurdle : any file that contains our string “This program..” will be listed, including most of the microsoft’s own DLLs and support libraries.
Finding the injected executable code
Now we have to trace each of the hits to check if it’s the code we are looking for or something else.
Select one of all listed entries : Follow in Dump > Follow in Memory Map
You will know when you will find something unusual like : Unnamed section in memory with Read Write and Executable permission.
Select and “Dump Memory to File”
We named it “remcos_extracted.bin” , let’s test it with PE Bear to make sure it was injected executable :
Hmmmm… now what? but we found our DOS header and all right?
Let’s inspect the file in Hex Editor
And we have our DOS header… then? WHY PE BEAR IS NOT WORKING?
This is because the file signature or magic number is not present !! Remember PE files start with “MZ.” header?
Fixing Extracted Binary [Header Signature Fix]
Now we know what’s missing, let’s repair the binary by placing missing header in place. But where to put it?
Let’s go to check list method :
MZ header usually aligns with starting offset.
about ~60 bytes before DOS header
So let’s clean all the Zero padding before 0x000600 as this seems to be good place for our signature and fits our checklist.
Clean all the padding above and modify first 2 Bytes as 4D 5A hexadecimal for MZ.
Save the file and … Now let’s check this in PE BEAR
Cool ! everything is fine.
AND we have our memory injected malware out in open!
Now we can fire up IDA or whatever rocks your boat to further analyze the extracted malware.
But we will leave that for another article, (’cause ofcourse you can see how excited IDA is with this RAT) it will take much more space and time to clear out all those crazy Call Graphs.
Conclusion
I hope this will come in handy for someone. This was actually super cool to me.
I was playing with windows memory recently and will share more as it comes. Till then… stay caffeinated enough and keep roaming in the memory lanes(pun intended)of windows.
References
Finding injected code into memory - Count Upon Security